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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
In C# there are two kinds of types...Value and reference...
What are Reference Types?
Reference types in C# are mostly objects and strings. These are types when placed on a stack refer to a memory address in the heap.
What are Value Types?
Value types make up the bulk of types in c#. These include int, float, double, long, bool, etc. These types values are only stored in the stack.
Stack? Heap? What's the difference?
To put it short, the stack is a series of memory blocks (like a scratch pad) that is used for the current thread. The stack is used for basic property data access. Accessing the stack is very rapid, as its only used for trivial data. The heap is an area of memory for dynamic memory allocation. The heap is used to store things in data that are not value types, usually objects and strings. The heap is slower to access, but larger in size.
Reference type tripping points
Reference types are basically pointers. These pointers can trip you up in interesting ways. For example suppose you have an object called MyObjectName:
var MyObjectName = new SomeClass();
and you decide to make someone else's object name the same as you're name
var OtherObjectName = MyName;
When you change MyName to be something else, you will also change OtherName.
This is because objects are a reference type. On the stack the object is a pointer reference to the heap. When you make OtherName equal you are pointing it to the same memory address as MyName. You can see this in action here
var MyName = new SomeClass(); var OtherName = MyName; MyName = MyName.Name = "Joe"; //OtherName will now equal Joe
This is also the same for array's if you make 1 array equal another, you will not have 2 array's with the same value. You will have 2 variables that point to the same array.
So the same must work for value types right?
If you have 2 ints and assign one int to equal the other. The value on the stack will be copied to that int, and since the stack value is the actual value they will be independent of each other.
Boxing and Un-Boxing
When you have a value type and you want it on the heap you must convert it to an object. This is called boxing
var val = 3; var x = (object)val;
However once you do this, the two variables will be independent from each other. So if you change x you won't change val and vice-versa.
To get the object back on the stack you must cast it back into an int. This is called un-boxing
var y = (int)x;