In C# there are two kinds of types...Value and reference...

Over the last 8 years the demand to scale has ever increased.

We have gone from curating machines like your favorite pets, and started spinning up, and destroying VM's at an ever increasing pace.

As engineers the Unix like platforms, have always been easier to work with. Personally I enjoy linux, I love package managers, I love ssh, and configurations are much easier. That being said, lately I have been interacting a lot with Windows servers.

Around 6 months ago I started a project, and part of that project was to move us away from an old search tool to use elasticsearch.

So recently I have thought about build tools. We have many tools including cake, sake, albacore, and even MSBUILD. Most of these tools work well, infact they work flawlessly. I am a web developer, and I work on a team of web developers. Most of our work is in JavaScript land, with tools like React, backbone, etc. We love ES6, and we want to use things like babel. This ultimately causes us to have 2 build engines. The first being a proprietary version of albacore, and the second being gulp.

dotnet CLI is currently in RC2, and while the train is fast approaching RTM, most tools are still catching up. dotnet seems to have a documented cli based install for every platform except the good ol windows. That being said getting a windows based install/build is possible.

So now that Windows server 2016 is generally avalible for the first time ever windows users can now use containers. Ok, so what exactly are containers? Well more or less they are virtual operating systems that share the same kernel as the host OS. In regular VM's the hardware is shared between machines, but containers go a step further and share the kernel of the OS. Why does this matter? Well because you are sharing an existing kernel that is already running, your startup times are instantanious. To put this in perspective, this is virtualization at the OS level.

On Linux, containers have been a thing for a long time. This technology is called LXC. Docker itself is a layer ontop of various container platforms embedded in operating systems.

tl;dr view this gist

So its 2016, and we are still making console apps/cli's. In fact I would say there has been a surge in popularity of these types of tools. I think we have come to the realization that buttons on forms are not automatable, and that the command line doesn't have to be scary.

I recently started writing an app in dotnet core, which is the new runtime for dotnet. In the past I have often used command line parser, but as of this writing it does not support core.

I was really lost trying to find an arguments parsing library when I realized the dotnet cli was open sourced.

After much struggle, failing to bingle. I started ripping through the Entity Framework, and dotnet cli's code hoping to find a gem. Thats when I stumbled across a diamond. You see many dotnet projects use Microsft.Extension.CommandLineUtils to do cli parsing.

tl;dr click here

When we talk about capturing metrics in applications. One server/service that constantly is in all conversations monitoring, is statsd. Incase you have never heard of it, statsd is a udp/tcp server that you send your in-code metrics to. These metrics get aggregated by statsd, and are forwarded to various backends. Some backends are services like librato or sumologic. Other times you are sending metrics to time series databases such as graphite or god forbid influxdb.

This boils down to in code you can say "log whenever this block of code is hit" or say "measure how long this function takes to execute". These stories come together to form pretty graphs, and rich alerts. All of this enabled by statsd.

Today marks the release of Visual Studio 2017, and with it the final release of the tools for dotnet core. This means as of today you can build, test, and deploy an application completely supported by microsoft. Not just the runtimes, but the tooling as well. The CLI for dotnet core has been finalized, and its awesome. The csproj system has been revitalized. New csproj's can be created, and are fully compatible with the old. Visual studio 2017 has finally released. This is probably the greatest version of visual studio ever created. Finally VS has gone from a slow, archaic editor, to a fast moving IDE. An IDE with a DevOps-First Cloud-First mentality. An IDE ready to tackle today's modern challenges.

Now that dotnet core tools have been released I thought it would be good to look into the dotnet cli. This is a new command line interface to build, manage, compile and run dotnet core based applications

Ok so I've been in the alexa skills market recently, and obviously amazon wants you to use AWS Lambda for your skills. If you are like me, you have a ton of stuff in azure app service (the PaaS of azure). Azure app service supports nodejs, java, python, and of course .net. The two sdk's amazon ships (node, java) do not tie in with a web stack, and are obviously thought of as being used with Lambda.

When Visual studio 2015 launched, I wrote a blog post titled Resharper without Resharper. This was clearly aimed at giving people the ability in 2015 to divorce themselves from the very expensive product. In writing the post however, I didn't realize people would just want a low down on cool vs2015 extensions.

Here we are, its 2017 dotnet core is out, and finally dotnet has a proper cli. In a previous post we explored the new cli. In short you can use the dotnet cli to build, test, package, and publish projects. However sometimes just using the cli is not enough. Sometimes, you land in a place where you have many projects to compile, test, and package.

So many people know me as a very performance focused engineer, and as someone that cares about perf I've always been a bit embarrassed about this blog. In actual fact this blog as it sits now is fast by most people's standards. I got a new job in July, and well I work with an absolute mad lad that is making me feel pretty embarrassed with his 900ms page load times. So I've decided to build my own blog engine, and compete against him.

I remember when (Accelerated Mobile Pages) first came out, and it was very restrictive and weird. I think this ultimately hurt the AMP Brand Beyond this, several companies have built AMP experiences which haven't always been the best experience. I do however think AMP pages always load extremely fast. A lot of that is just the constraints of AMP. Last night I put my blog posts on AMP for a laugh, and it was much easier than I thought it would be.