Engineering teams practicing DevOps strive to improve the way they build, ship and operate their software while avoiding customer impacting outages. Parts of this problem can be solved through automation that reviews and monitors your codebase before and after release, taking action before a human operator even investigates an event. One of the hardest parts of reducing system outages completely is that software still involves human, and human involvement always brings its own set of challenges.

Recently I’ve been updating the configuration of a bunch of personal servers to match the 2016 PCI requirements. One of the 2016 PCI requirements requires you to disable TLS 1.0 as it is now considered insecure. One of the problems with doing this of course is the fact that WebDeploy uses SSL and by default won’t allow connections and deployments to occur with TLS disabled. Luckily the fix is rather simple.

A few years ago the Gmail team began experimenting with the concept of interactive extensions to email messages, with the release of Gmail Actions (now called Gmail Email Markup). These simple additions to your HTML email allow developers to add call-to-action type links to your emails, without customers even needing to open your email.

In web and software development we all know what it’s like to finish a project and have it leave a bad taste with either your team or your stakeholders. Often left with thoughts of “if we’d just had time to slip that last feature in”, “I wish we’d understood that requirement earlier. or even worse “I wish we’d given that more testing time”. The problem is that as humans we’re incredibly good at this kind of thinking, but by using Agile processes to change this thinking both your development team and stakeholders alike will be a much happier bunch.

Constantly over the past few years I’ve thanked my lucky stars that I’ve had continuous integration and deployment setup for the web sites I’ve been working on. It is one of the few development opinions where I break the “religion and politics” laws of social etiquette. I feel incredibly strongly about the benefits that having a good Continuous Integration and Deployment story can bring to a project and it’s team. Sadly, not everyone has been able to experience the awesome sauce of CI/CD. I’ve been working hard to change that.

You’re close to shipping and you receive a shopping list of bugs and changes. Some are tiny and un-eventful, some are show stoppers, some let the bad guys in, and some are simply scope creep trying to sneak through the door. It’s hard to know where to start without reclassifying them because the majority of them are all labelled Critical. It’s time to sit down with whoever documented your bugs and do some talking…

Nuget has become such a valuable part of the .Net ecosystem it's any wonder how we got the job done with 3rd party packages without it. When working on projects in a team many developers turn on Nuget Package Restore to save them having to check their packages into Source Control. This allows them to have their packages download whenever a new developer goes to build. It’s also quite popular with project teams that have Continuous Integration setup. I recommend against Nuget Package Restore, as I’m simply not a fan.

Migrating to a Code-First or Model-First approach to database development can be very liberating. At the end of the day your database is just a way of storing state, so getting away from the implementation details can really help speed up development and allow you to focus your efforts. Code First’s awesomeness aside, when you try and implement this kind of paradigm shift within a team you unlock a different set of problems. Here are two potential ways to alleviate some of the headaches.

So you’ve started sending email from your site/application, your application is doing well and you are now sending more e-mail daily. With this comes the fun of finding out that most of the email you now send ends up stuck in your customers spam filters – how did this happen? You aren’t a Nigerian scammer, and people opted-in to hear from you! At this point signing your mail may be the next step.

Nearly all websites these days send email and because of this the majority of developers assume that they “know how to send email from a website”. They continue under this assumption until they have a site or server of their get black listed by a Spam blacklist. Then they are forced to scratch their heads to try and figure out why this happened. Before you hit send on that email requesting to be removed from that Spam blacklist, let’s recap what you should be doing to make sure it doesn’t happen again.

One of the most common configurations people use when setting up ELMAH is email exception logging so that you get notified whenever “shit’s goin’ down” on your site. This leads to a follow on issue that stems from this in that you end up receiving 100’s of emails a couple of times a week as your website gets scanned by evil doers looking for vulnerabilities – but there is a simple and elegant solution.

Adding Accessibility to a website for access by sight or hearing impaired users is a thought that many developers have post build. Along with this, when you’re tasked with the job of building an accessible website, Visual Studio probably wouldn’t initially be a tool that comes to mind, but Visual Studio has everyone fooled on this topic as it has this functionality covered, you just need to look a little below the surface.