This blog uses Wyam. A static site generator created by Dave Glick. !
The best way to start a blog is just open a WordPress or Medium account and start writing, but that's no fun. You could also try building a blog from scratch. This is what people did 15 years ago and is a waste of time. The middle ground is hosting an off-the-shelf cms yourself. For some time I had an Orchard 1.4 site running on this domain and after that an empty Umbraco 7 site. Both continuously deployed to an Azure website using a git repository in a Team Foundation Service account. I spent a good time setting all this stuff up, but the results felt bloated for a basic html site. It's needless to have a dependency on a database service for a site that only serves read-only content. Especially since the only content editor is the developer itself. Being locked into a cms system with its endless new version update hassle makes you feel claustrophobic.
In the end of 2013 I read the blog post by Phil Haack about how he moved his blog to Github pages. The simple approach of storing plain Markdown sourcecontrolled text files on disk is great. The data isn't tied to any database or web application and this method has proven to work well for all kinds of documentation. I was convinced.
Github pages runs on the Jekyll static site generator, which again runs on the Ruby runtime. Jekyll isn't very well supported on windows since all rubyists use OSX. After some time I got it working on my local machine by copying this setup.
Jekyll on Github pages has a dependency on the Pygments syntax highlighter which only works when python 2 is installed. This bothered me. Installing one server-side runtime for a blog should be more than enough. A client-side JavaScript syntax highlighter will do just fine. I'm not much into Ruby and I didn't like customizing the Jekyll output.
After this endeavor I started investigating more static site generators. I tried Hexo, which is the most popular Node variant, after which I was compelled to try the less known .Net generators. I looked at Sandra.Snow, which works fine, but isn't used much, active development has stopped and feels a bit immature.
The most promising one by far is Wyam, which has generated this content. The project is very well led by Dave Glick and is in active development. I cloned the source of Dave's blog, removed his content and got it to work and was generally happy. The filewatcher --watch switch in Wyam.exe works great for authoring your content locally. I could have just pushed the output folder from my local machine to Github pages, but that's cheating and I definitely needed a proper build pipeline in a hosted build service.
A good solution is to let AppVeyor push the Wyam output back into a Github orphaned gh-pages branch, explained in the Wyam docs. Github pages are nice, but I liked the way I was hosting the previous sites in a standard Azure AppService plan, paid for by my MSDN subscription benefits. The Azure App Service runs on the Kudu engine and has the concept of site extensions. I thought about letting Kudu do the site generation by creating a Wyam site extension or just a custom .deployment file. Eventually I decided that this responsibility would better fit in a more flexible separate continuous integration service witch can push the output folder to Kudu.
The solution I went for is the new Visual Studio Team Services build system. I was already using the unlimited free private git repositories and had experience implementing the build system at work. Team Foundation Server has finally switched to a simple task based browser managed workflow build system, which TeamCity and others had forever. The new build and release agent works great and is easy to install on a local machine if you burned through the free hosted build minutes. For Wyam I've created a custom build Task, which I will try to document in a future post.
The plan is to stick to this setup for a while and actually try to write some content.