Cli on Isaac Levin

Building My Blog with GitHub Actions

isaac@isaaclevin.com (Isaac Levin) — Wed, 08 Jan 2020 08:25:05 -0400

So I Changed My DevOps

As some may know, I already had a fully working CI/CD process for my blog and it was running on Azure Pipelines. As someone that is always learning and wanting to play with a new tool, I was pretty intrigued when GitHub Actions was formally announced at GitHub Universe. I wanted to see how challenging it would be to move my DevOps process from Azure Pipelines to GitHub Actions and it was not hard at all.

How I Built A Blog

isaac@isaaclevin.com (Isaac Levin) — Thu, 25 Apr 2019 08:25:05 -0400

I have updated my blog to use GitHub Actions for Ci/CD, check out this post to learn more!

Why a Post on This?

I have been asked a few times why I decided to build a blog and more importantly, what I did to build a blog that was lightweight, easy to modify (i.e. add posts) and most importantly, is cheap. This is how I approached it, and I understand that some people have more criteria when they look to create a blog, but I am a simple man with simple needs. Remembering the previous version of this blog was an Server-Side rendered Angular 6 application with an ASP.NET Core backend with Azure SQL holding all the data, there was tons of code to write and maintain, and when things did not work (a gist not loading properly for example), I had to debug the issue, which at times took away from building content. So with this criteria, I decided to adopt the following implementation for my blog:

Blog will be a Static Website (plain HTML, CSS, JS)
Blog will be deployed to Azure Blog Storage for hosting
Site will utilize a domain purchased through Azure DNS
Azure CDN will be configured to serve site as efficiently as possible
CloudFlare will direct traffic to site in certain scenarios
CI/CD will be configured using Azure DevOps to push commits to Blob Storage

Using Azure CloudShell as a Dev Sandbox

isaac@isaaclevin.com (Isaac Levin) — Sun, 03 Feb 2019 11:25:05 -0400

Have You Heard of CloudShell?

Back in around the Build 2017 timeframe, the first implementation of [Azure CloudShell](https://docs.microsoft.com/azure/cloud-shell/overview) was rolled out, bringing the ability to run Azure CLI commands from the context of a logged in Azure session, from anywhere the Azure Portal could be loaded (i.e. a browser). This allowed you to do many things via the command line in the Azure world without having to use the GUI or have the tooling installed on your machine. Since that time, there have been a ton of features rolled out to CloudShell, and it can be accessed via it's own url [https://shell.azure.com/](https://shell.azure.com/), though you can still access it via the portal like so.
[

](/images/cloud-shell/get-started.png)

After initiating CloudShell if you haven’t before, it will ask you a few things, like what Resource Group you want to install CloudShell in (CloudShell is temporary but needs Azure Files to persist your files). You are also given the option to default what terminal interface you want (PowerShell of Linux Bash). The experience you see when opening CloudShell is a terminal view that is connected to your chosen Azure Directory.

Six Opinionated Tips to be a Better .NET Developer

isaac@isaaclevin.com (Isaac Levin) — Thu, 06 Dec 2018 08:25:05 -0400

Tis the Season

I am humble to be a part of the [2nd Annual C# Advent Calendar](https://crosscuttingconcerns.com/The-Second-Annual-C-Advent ). Thank you to everyone who helped put it together and contributed. My blog post is hopefully a fun one not to be taken too seriously. I have been a developer for over 10 years, and I am always looking at new ways to be more productive. May I present you with 6 tips that I have started to adopt that I think have increased my developer skills 1000% (YMMV).

1. Make the CLI your Best Friend

I will shout it from the rooftops, **I LOVE CLIs!!!** I just find the process of working in the command line a far more efficient experience than the IDE in certain scenarios. Being a .NET developer, it is obvious I would gravitate towards the [.NET CLI](https://docs.microsoft.com/dotnet/core/tools/) to kickstart my development experience.

The main benefit to using .NET CLI is getting started with writing .NET Core applications, with a few commands, you can have a template app created and running locally.

```csharp dotnet new webapi -o TestApi dotnet run ```
Running that serves up a kestrel instance of the default WebApi template, with no IDE required. Extending this further, we can `watch` on the same command and it will re-run the `run` command whenever a file changes in the project.

That is pretty cool! There are some really cool things you can do with the CLI, but there are also some very important things you can do as part of SDLC with CLI tools. Using the .NET CLI to build, test, and publish your applications is super easy, especially if you use an ALM tool where you can control the configuration of your build environment.

One amazing additional thing to consider with the CLI is the extension capabilities. [Global Tools](https://docs.microsoft.com/dotnet/core/tools/global-tools) are custom developments that can be downloaded via nuget and are executed via the command line. You can use global tools to build custom demands for functions that as a developer we tend to do repetitively. How about being able to get a random blog post in infamous [cowsay](https://www.nuget.org/packages/dotnet-cowsay/) format. (**Full disclosure, I wrote this, disregard the shameless self-promotion**).

There are tons of useful global tools available developed by Microsoft or the community, take a look at some of them [here](https://github.com/natemcmaster/dotnet-tools). I highly encourage folks to use the CLI as much as they can, who knows you might become someone who never opens Visual Studio again! (not advocating that, VS is awesome)

## 2. Use Application Insights for Local Development
Application Insights might be my favorite tool of all time. Any opportunity I have to bang the drum and promote it I am there. I talk to my customers about it, and I speak about it at community events and conferences. The number one misconception people have about Application Insights is that you can only use it if your app is in Azure. That is simply not true! Sure, Application Insights is a first-class citizen in Azure, but you can host your apps in other Cloud Providers or even On-Premises and still get the benefit. Actually, you don't even have to deploy your app to see the capabilities of Application Insights.

Application Insights is simply a REST service with a SDK that batches telemetry and pushes it to the Api, so you can leverage the full power of App Insights while working locally. The easiest way to get Application Insights is within Visual Studio by adding a Connected Service. Do this by Right-clicking on your project and select Add > Application Insights Telemetry

From there, you will be prompted with a wizard to walk-through setup of the Application Insights resource. From here, you can elect to just install the SDK on your app, which does nothing in Azure, but allows you to see what kind of data will be sent to the Api if you decide to use it.

Once you complete the wizard, you will have the SDK from nuget installed into your app, and the necessary changes added to your app to utilize the SDK. If you start your application, you will see a new Application Insights button appear in Visual Studio when you are in debug mode.

This is a built in Application Insights viewer that allows us to see what kind of telemetry our application tracks, with filtering and other features included. This is a powerful experience that is great for getting a first taste of Application Insights. If you like what you see, I highly recommend using Application Insights for your applications, as it a great experience at a very good price point.

Azure CLIs Are Awesome

isaac@isaaclevin.com (Isaac Levin) — Sun, 01 Jul 2018 11:25:05 -0400

Did you know the Azure CLI was Extendable?

I did not know this. I was minding my business, when I decided to catch up on some Azure Friday videos, and found this beauty from June 23rd 2018 regarding extending the Azure CLI and how it was completely in the open. In the video one of the extensions was showcased, alias, which allows a developer to create quick commands for Azure CLI commands. So often when working with the Azure CLI, I write these long, impossible to remember commands where only one or two things change. For instance

Resetting Git Working Directory Commands

isaac@isaaclevin.com (Isaac Levin) — Mon, 21 Aug 2017 11:15:58 -0400

I prefer CLI to visual tools for Git

In doing my day-to-day development, I prefer to do most tasks Git related in a CLI. There are great tools available in Visual Studio 2017, Code, and 3rd party software like Source Tree, but for I like what I like, and the CLI does it for me. One thing that it is super easy to do in the CLI is “resetting” or clearing a working directory and starting fresh. We all make random changes, whether it be add/remove files and make changes that we decide are not ideal for commiting. There are a few ways/options to clean up your directory, and in this post I will show the ones I use often with their caveats.