So you've come to a point where you want to build nice CLIs. There's a few different options for building CLI's. My two favorites are oclif and commander.js. I tend toward leaning to commander, unless I know I'm building a super big app. However, I've really enjoyed building smaller CLIs with commander recently.
So I've been using monorepos for some time, and recently I've gotten a lot of questions about how to host them on Heroku. I figured I'd give you the simple guide. There are two basic scenarios. The root of your git repo has your yarn/npm workspace, or you have a folder inside of a gitrepo you wish to use.
For many of us a JS workspace is the simplest way to structure code for future growth while providing very quick iterations. Incase you are unfamiliar, several technologies exist such as
npm workspaces, etc. That can seamlessly stitch npm packages on disk as though they were published to a private NPM registry. This allows for fast iteration inside of a single git repo, while allowing a future where these dependencies could be abstracted.
I've been working at CarGurus.com for the last 2 years or so. One of the biggest journeys we've been undertaking is to take accessibility far more seriously. However with an engineering team way into the triple digits it gets harder and harder to scale accessibility knowledge.
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.
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.
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.
If you have read this blog for any length of time, you know I am a fan of Azure. I thought about using github pages with hexo, but github pages only supports 1 doman name. I could start 301 redirecting my other domains, but I really didn't want to do that.
Around a year ago I joined a new team where I work, and this team was starting to undertake a full rewrite of their code. We were going from a full c#/mvc app to a tiny c# api, and a very big SPA.
I started Bingling around and I stumbled across jsnlog. JSN log lets you quickly wire up your client side logs to your server. I have been able to get PR's into the code base and the guy behind it has been very friendly to me when I have had questions.
I have used Linode for quite a long time now. My blog was hosted on linode, as was my StarBound server. My linode was the CentOS Pet I always wanted. Full of manual Fail2Ban configs, I make sure I fed my VPS every day. I even used cowsay to give me a cool message from my pet every login.
The major reason I moved my things away from Linode, was not the devops story itself. I could have stuck with linode, and used chef or something to manage my former friend. I decided to host everything in Azure Web apps. Now before I give you my long ramblings why I like azure; I must tell you. I put everything in azure, because my MSDN gave me free credits. There was no huge scientific analysis behind this. The simple fact that I got free money in Azure was the only reason why I started using it.
Where I work .NET rules supreme. Personally I really don't care that much about the technology so long as it supports really good workflows. One of my major issues with nuget is that is very opinionated.
In the old days, when programming in .NET you were signing yourself up to a lifetime of windows server, however things have changed.
To install on CentOS follow these instructions.