You have known about Test-driven Development (TDD) for years. You’re aware that modern application frameworks were designed with testability as a primary concern, and unit testing and continuous integration have become an industry standard. You have a hunch that TDD will benefit your teams, yet you haven’t embraced the practice! You are out of excuses and you may even feel behind the curve. No worries—let’s get you going with TDD.
Serverless is the next evolution of cloud computing. You good? Seriously, I’m sure you’re busy, but let’s see if we can get you up to speed and talking about Serverless in your next meeting. Fair warning—"Serverless” is a catchy and clever term that comes with hype and some confusion. Let’s take the next 10 minutes to clear a few things up and get you rolling with Serverless.
In the series opener, I wrote about “optional” software development practices like Test-Driven Development (TDD), Continuous Integration (CI), data migrations, one-click deployment and code review which are fundamental to how we build software at Fairway, but are often touted as optional and embraced by a small percentage of development shops.
In this post, let’s dig into one of the “optional” heavy-hitters, code review.
There is any number of reasons why code isn’t reviewed at all shops – every reason from the presumed time/cost commitment being too high, to just not understanding the true benefit or how to get started, to a general aversion to change. My two favorite reasons include protecting developer morale (i.e. developers can’t handle having their work critiqued) and naively thinking there’s no need/value since developers are producing a good product already. Oh brother. Perhaps worse than avoidance, though, are the truly unfortunate cases where the fears of the skeptics are the reality, where teams preform code reviews poorly. Here, a lively roomful of peers nitpick and bash away on Johnny’s code or, quite the opposite, the review becomes a total snooze session. In either case, the review is probably scheduled too late in the project lifecycle so there’s no time for anything constructive to be done in response. There’s absolutely no value – just wasted time.
SubText is the engine behind our company blog. With the goal of ensuring a smooth transition between the main website and the blogs, I spent some time tightening up the styles for the aggregate and individual blogs last week. This required a custom SubText skin and lot of css tweaking.
Though I've previously had the SubText source running on my machine, there was no need to update or rebuild the solution in my current case so just went ahead with a local installation using the Microsoft Web Platform Installer (Web PI).
I just wrote about how I like to present on unfamiliar topics. With this said, Domain-Driven Design (DDD) is no exception. This is yet another area I knew enough about to be dangerous but I certainly was no expert. As it turns out, researching this topic wasn't easy. I could be wrong, but it is as if DDD is a secret to which few are privy. If you search the Interwebs, you will likely find little information about DDD until you start rolling over rocks to find that one great write-up, a handful of podcasts and videos and the Readers' Digest version of the Blue Book which apparently you must read if you really want to get the complete, unabridged skinny on DDD. Even Wikipedia's write-up is skimpy which I didn't know was possible…
In this presentation, I provided a brief introduction into TDD and talked about the confusion and misconceptions around the discipline. I, of course, shared a bit about Dan North, the father of BDD and touched upon some crazy hypothesis dreamed up by Sapir and Whorf. I then gave a Behavior Driven Development overview (my impressions of the implementation and lifecycle) and then touched upon available tools, how to get started and I threw in a number of reference and reading materials which you will find below.
I mentioned in a previous post that we've started a languages club at the office. In an effort to decide which language we will first concentrate on, I volunteered to give the rundown on F#. Rather than providing a summary here, I've provided my slide deck for your viewing enjoyment. There's nothing special here outside of a some pretty cool characters from The 56 Geeks Project by Scott Johnson and collection of information from my prior functional programming presentations.
The folks at the Open Web Application Security Project publish a list of the top 10 vulnerabilities. In a recent CodeBrew I provided a quick overview of them all and spent a good amount of time focusing on the most prevalent vulnerability, Cross Site Scripting (XSS).
We started a work language club at work this week. Thus far, we have a collective interest in a number of languages: Python, Ruby, F#, Erlang, Objective-C, Scala, Clojure, Haskell and Go. There are more but these 9 received the most votes.
During the first few meetings we are going to determine which language we should tackle first. To help make our selection, each member will provide a quick overview of their favored language by answering the following set of questions: