Code From Your Phone
I've long been a fan of mobile development workflows. I've also been interested in the convergence of .NET Core on Linux and containers as a way to enable rapid, self-contained .NET development environments. It turns out that updates to mobile tools, improved container hosting, and a little elbow grease can create a very nice mobile development setup that includes the ability to easily work with GitHub and git, edit files, and run builds and unit tests all from your phone or tablet (assuming your phone or tablet is running iOS - someone else will have to figure out how to do this on Android).
Development On The Go
Fitting your open source side hustle into a busy schedule can be really hard. It seems like every time you get started on a new feature, doing issue triage, writing documentation, or any of the other multitude of activities that keep an OSS project healthy you're pulled away by family, work, or other personal obligations. I've always had a family-first mentality, so for me creating a healthy balance means making the most of every minute. More often than not, that means doing whatever work I can wherever I happen to get a free moment to do it. Not everything requires Visual Studio and a compiler. Creating documentation, responding to issues, reviewing pull requests, and writing blog posts can all be performed from your phone. In fact, I'm writing this blog post from my phone right now. Here's the tools I use to enable this kind of mobile open source workflow. Before I begin though, it's worth noting that both my phone and tablet are iOS so that's what I'm going to be writing about. There are probably very good counterparts on Android and Windows Phone, I'm just not aware of them.
A Tale of Two APIs
When developing libraries it occasionally becomes necessary to expose a different public interface to different groups of users. The most common scenario is one in which your library needs to be accessed in one way by applications that use it, but another way by other libraries that extend it. You want extension developers to have access to all the behind-the-scenes details, but exposing those properties and methods to applications would be confusing or even damaging by promoting improper use. In other words, you want the internal properties and methods to be exposed to one set of developers but not another. In this post I'll examine a strategy for exposing different public APIs to different sets of users.
Eliminating Magic Strings in ASP.NET MVC
Except for direct screen output, I really dislike coded string literals. Using strings to refer to properties, methods, classes, etc. makes it much easier to introduce code quality problems. This includes things like mistyped identifiers, missed refactoring renames, and poor code analysis capabilities. I am constantly on the hunt for ways to remove these "magic strings" and replace them with strongly-typed counterparts. This post describes several of the tools and techniques I've found that work well. While this post addresses the elimination of magic strings from ASP.NET MVC web applications, many of the strategies are applicable to other code as well.
Open Source Obligations
With the Thanksgiving holiday just around the corner here in the US, we traditionally consider everything that we're thankful for. I have the typical list that includes my family, friends, health, etc. but I've also been thinking about how thankful I am from a professional perspective this year. From the very top on down, there has never been a better time to be a developer. With abundant conferences, meet-ups, online social networks, resources, and open code, we developers are in the midst of a global community that is larger, more active, and more heterogeneous than ever before. This is certainly true for developers on any technology stack, but recent events have made it particularly apparent to those working on the .NET platform. I am specifically thankful for the abundance of open source code and other resources made possible by the many selfless contributions of others. However, there are many different opinions with respect to the way in which we should be participating in the open source processes. These convictions are only strengthened by the fact that there are very real financial, time, and personal implications for those involved. I've seen a number of recent discussions on Twitter and elsewhere regarding the obligations of the various participants and I'd like to examine this issue in a little more detail. This post is going to be very opinionated and I invite you to disagree with me. With open source software becoming increasingly vital to commercial enterprise, it's important to have an open and civilized discussion about these topics.
A Survey of .NET Static Site Generators
There is a lot of demand and a lot of active development around static site generators. If you're not familiar with them, these tools take markup or other simplified content and turn those resources into a full static website (HTML, CSS, etc.). There are a number of great static site generators out there, and it seems like a new one is released nearly every week. However, for this survey I am going to focus on the state of static site generation in the .NET ecosystem.
Fun With Fizz Buzz
On Twitter last night I noticed someone mention that they were "having fun with #FizzBuzz". I had never heard of Fizz Buzz before, so I decided to look it up. In short, Fizz Buzz is a simple programming task that any competent programmer should be able to accomplish. The task is to print numbers from 1 to 100, delimited by a comma and space. For each number divisible by 3 you print "Fizz" instead of the number, for each number divisible by 5 you print out "Buzz", and for each number divisible by both 3 and 5 you print out "FizzBuzz". The apparent simplicity and hidden complexity of this problem also makes it popular in programming interviews. I like a good brain teaser, so down the rabbit hole I went. My only ground rule was no help from the Internet.
Brace Style Convention
Most C language descendants and variants use braces to indicate scope, and where there is a possibility for variation there will be as many opinions as programmers as to the “correct” way to do things. There has certainly been more than enough written about where to put an opening brace, but I was having a discussion on this topic recently and just couldn’t resist adding my opinion to the noise.