Ermish

Deploying Dotnet Core to Google Cloud

Tue, 08 Aug 2017 00:00:00 -0700

If you’re trying to setup .NET Core / ASP.NET 5 on Google Cloud, then this is the article for you! As a disclaimer, I’m building everything based on using a mac development environment.

Free Money!!!

As the time of writing this article, google is giving $300 to play around in the cloud and try out all the toys. Just go here!

Installing the Google cloud CLI

Now, we just need to setup the google cloud CLI. This is actually pretty nice and will be how you deploy your app.

You can try to install the CLI here:

https://cloud.google.com/sdk/downloads

I, personally, was getting an error when trying to install gcloud CLI and ran this instead and it worked:

curl https://dl.google.com/dl/cloudsdk/release/install_google_cloud_sdk.bash | bash

Setup your dotnetcore app

Assuming you have a basic dotnet core setup you can skip this step. If you don’t here’s a barebones setup.

1) Install the dotnet core CLI

https://www.microsoft.com/net/core/preview#macos

2) Run these to create new kestrel web server

dotnet new web
dotnet restore
dotnet publish -c Release

This will output a bin folder which will be what is on the server.

Create a docker file

You don’t need docker installed or anything for this. If you aren’t familiar, a dockerfile is essentially a server installation script. Just create a file named dockerfile (no extension) and paste this in:

#FROM ermish/gcloud_dotnet_core
FROM gcr.io/google-appengine/aspnetcore
ADD ./yourpathtothebinfolder/bin/Release/netcoreapp2.0/publish/ /app
ENV ASPNETCORE_URLS=http://*:${PORT}                     
WORKDIR /app    
ENTRYPOINT [ "dotnet", "api.dll" ]

Update yourpathtothebinfolder with the appropriate path to the publish in the previous step. The path in this file means you don’t need to keep the dockerfile in the same publish folder.

NOTE: Here’s where Google’s basic tutorial went wrong. The docker image they have is old and didn’t support the latest dotnet core version. So I went ahead and built out a new docker image and threw it out there for everyone to use! If you deploy your app and are getting errors, just uncomment the line that points to the image I created (the line starting with #) and remove the other FROM line pointing to gcr.io.

Create a google app engine server config

This is a basic script that creates a google app engine based on a dockerfile. Just create a file name app.yaml and paste this in:

service: my-demo-app
env: flex
runtime: custom

Deploy the app!

Just run this to deploy the app to google cloud!

gcloud app deploy --version v1

You can rerun this and change the version each time. It will version the app and shift traffic to the new deployment.

That’s it!

Hope you enjoyed the tutorial, and feel free to reach out with any questions!

.NET Core Kestrel with SSL

Sun, 23 Jul 2017 00:00:00 -0700

This is a quick tutorial for setting up your local .NET Core / Kestrel development environment to use SSL.

Machine setup

This article is based on .NET Core 2.0 using VS Code on a mac. No need for the full version of Visual Studio on Windows only!

Setting up Kestrel

In your Startup.cs class, you should be importing an appsettings.json file and a appsettings.Development.json file. The development version is run when you set the environment variable ASPNETCORE_ENVIRONMENT to Development. This is usually set by default in VS Code and Visaul Studio. For this example, we will setup an ssl cert for localhost, so we will update the appsettings.Development.json file.

Setting up the URL

We can setup Kestrel to listen on any address/port by adding this section to the file:

 "Kestrel": {
    "Endpoints": {
      "localhostHttps": {
        "Address": "127.0.0.1",
        "Port": "9001",
        "Certificate": "HTTPS"
      }
    }
  }

This will use a certificate “HTTPS” which we will setup next.

Pointing to a cert

{
  "Certificates": {
    "HTTPS": {
      "Source": "Store",
      "StoreLocation": "CurrentUser",
      "StoreName": "My",
      "Subject": "CN=localhost",
      "AllowInvalid": true
    }
  }
}

Creating the SSL Certificate

Next, we create a self-signed certificate for HTTPS using OpenSSL. You want to run these commands in same folder as your code. This will create the certs in the current directory.

Run this:

openssl req -new -x509 -newkey rsa:2048 -keyout localhost.key -out localhost.cer -days 365 -subj /CN=localhost

Then this:

openssl pkcs12 -export -out certificate.pfx -inkey localhost.key -in localhost.cer

Add the cert to the macOS keychain

security import certificate.pfx -k ~/Library/Keychains/login.keychain-db

Now trust the cert:

security add-trusted-cert localhost.cer

That’s it!

Hope you enjoyed the tutorial, and feel free to reach out with any questions!

Docker Example

Sat, 23 Jul 2016 00:00:00 -0700

In my last post, I talked about going with Docker hosted by DigitalOcean. This post will walk through the setup and initial design of my Docker app. I wanted to go with something that would support future growth and scalability as I play around with multiple languages and technologies. I’ll be building this from the perspective of working on a Mac, but it should be almost the same for Windows/Linux. Also, I’ll be using VS Code as my IDE, because IT’S AWESOME.

Design

I’ll be using Docker Compose for setting up the whole environment. This makes it really easy to setup all each application and keep track of everything running in your environment. Docker Compose is like a checklist of your environment!

Each app will be setup via a Dockerfile and added to Docker Compose.

I’ll add a diagram here, soon.

Nginx

I’ll be using Nginx (Pronounced “Engine-X”) as a Static Web Server, Reverse Proxy, Load Balancer, and for some basic security. If you’re not familiar, a reverse proxy is often used like a routing table. In this example, any /api/ requests will be sent to the Node servers; all other requests will be sent to the static content directories. This makes it easy to add any other fun stuff like .Net Core, Ruby, or Python servers with some simple routing! The load balancing support is pretty amazing as well. You can set different weights for each , priortizing basic on load, connections, etc. all in Nginx. Piece of cake!

NodeJs

Up next is NodeJs! Why?

In this example, I’ll be setting up three different server nodes to distribute the load. (Note: this is just on one VPS, so the nodes will be sharing server resources. I may put up an example of how to setup multiple servers/droplets and load balance them. Also, for anyone curious, from some benchmarking, it does offer better performance with multiple nodes even though they are on the same VPS.)

MongoDB and Redis

MongoDb will be the database of choice. NoSQL, baby! Personally, I come from a strong SQL background. If you’re also coming from a relational data background and grumble at these new ‘fads’, you should give it a chance. It’s not the perfect solution to every problem, but it’s definitely eye opening! There’s several other NoSQL options, but this one is pretty easy to use and will get the job done for this app.

Redis will be used for some basic caching. It’s really easy to use and ties in nicely with NodeJs. As a side note, for .NET apps, it even has full Linq-to-SQL support!

Jekyll

I’ll be building the static content/blog using Jekyll. It’s based on Ruby, extremely fast, and very lightweight! There’s no database needed or dynamic content rendering.

I’ve been playing around with some Node based blogs such as Ghost and Hexo. Even though I’m more familiar with Javascript over Ruby, Jekyll seemed easier vs. Ghost which had a database backend and Hexo which is still growing.

Let’s get started. Docker up!

If you don’t have Docker setup yet, just go download the lovely client for your system. This will give you support for the docker commands and will startup your local environment. Next, let’s create a new app directory. On the mac, you can navigate to where you want to create the directory. Personally, I’m going to create mine under ~/code/. Just pop open terminal and type:

mkdir dockerdemo

Now, let’s start up a basic Compose file. To create a new docker compose file, type:

touch docker-compose.yml

Ok, let’s run it! Type:

docker-compose up --build

Congratulations! You build a docker app that does absolutely nothing! For future reference, this is the only command really needed to startup our whole environment.

Developers, start your Nginx’s!

For starters, let’s put all of the apps in a new sub-folder called:

mkdir docker-images
cd docker-images

This is the point where I open the folder with VS Code and create any new folder/files in the IDE (I’m personally too lazy to use the Terminal), but I’ll type out the commands so you can be lazy too. Now create another folder under docker-images called nginx.

mkdir nginx
cd nginx

At this point, we will create a Dockerfile. This is essentially a script with commands to build and setup a docker image. Important! there’s no extension. It’s just a file named Dockerfile.

touch Dockerfile

Now, let’s build out the Dockerfile! Just paste this into the file:

# Set nginx base image
FROM nginx:latest

# File Author / Maintainer
MAINTAINER Ermish

# Delete the default configuration
RUN rm -v /etc/nginx/nginx.conf

# Copy custom configuration file from the current directory
COPY nginx.conf /etc/nginx/nginx.conf

You can change the maintainer to your name, username, or your favorite superhero. Alright, let’s break this down. The FROM command will pull from Docker Hub by default which is where most public images are located. These images are pre-setup on a Linux distro and often configured as good as you could do or better. The :latest tag makes it easy to control the version of the image you want to use and makes it super easy to update your app since someone else did the configuration and compatibility work for you! Thanks, bro!

The RUN Command is used to remove the default Nginx configuration file. Finally, the COPY command is used to copy over our server configuration (hang on, it’s next…). If you’re curious why the config settings aren’t in the Dockerfile, this is how we can separate different environment configurations without having to change our docker image.

Here’s the config file for nginx:

worker_processes 4;

events { worker_connections 1024; }

http {
        include  /etc/nginx/mime.types;

         upstream nodeapp {
               least_conn;
               server node1:8080 weight=10 max_fails=3 fail_timeout=5s;
               server node2:8080 weight=10 max_fails=3 fail_timeout=5s;
               server node3:8080 weight=10 max_fails=3 fail_timeout=5s;
         }
         
        server {
              listen 80;

              #root /src/static;
              root /data/jekyll_demo;

              location = /favicon.ico { access_log off; log_not_found off; }
              location = /robots.txt  { access_log off; log_not_found off; }
              location = /sitemap.xml { access_log off; log_not_found off; }

             # location ~* \.(png|jpg|jpeg|gif|ico|woff|ttf|svg|eot|otf)$ {
             #     add_header "Access-Control-Allow-Origin" "*";
             #     expires 1M;
             #     access_log off;
             #     add_header Cache-Control "public";
             # }

              location ~* /assets/ {
                  add_header "Access-Control-Allow-Origin" "*";
                  expires 1M;
                  access_log off;
                  add_header Cache-Control "public";
              }

               location /api/ {
                 proxy_pass http://nodedemo;
                 proxy_http_version 1.1;
                 proxy_set_header Upgrade $http_upgrade;
                 proxy_set_header Connection 'upgrade';
                 proxy_set_header Host $host;
                 proxy_cache_bypass $http_upgrade;
               }

              location ~* / {
                    try_files $uri $uri.html $uri/ =404;
              }
        }
}

This file allows us to do some serious magic! This will allow us to load balance between the three node servers which we will spin up later. All requests will point to the static files unless the url contains /api/ in which case will be redirected to the node servers. At this point there’s no security and everything is public for the static jekyll content. For the api/data requests, additional security can be placed within the nodejs api.

Mongo and Redis, you’re up!

It’s time to make some more folders and Dockerfiles!

Let’s start with Redis and make another folder and Dockerfile under the docker-images folder:

cd ..
mkdir redis
cd redis
touch Dockerfile

Now, let’s build out this Dockerfile:

# Set the base image to Ubuntu
FROM        ubuntu

# File Author / Maintainer
MAINTAINER Ermish

# Update the repository and install Redis Server
RUN         apt-get update && apt-get install -y redis-server

# Expose Redis port 6379
EXPOSE      6379

# Run Redis Server
ENTRYPOINT  ["/usr/bin/redis-server"]

Hokay so, this is about as default as you can get. We’ll run Redis under the default port 6379 and use the default config. If you need to make custom settings, just copy over a redis.conf into /usr/bin/redis-server.

Alright, so thing for MongoDB:

cd ..
mkdir mongodb
cd mongodb
touch Dockerfile

Here’s the Dockerfile:

# Set the base image to Ubuntu
FROM        ubuntu

# File Author / Maintainer
MAINTAINER Ermish

# Update the repository and install Redis Server
RUN         apt-get update && apt-get install -y redis-server

# Expose Redis port 6379
EXPOSE      6379

# Run Redis Server
ENTRYPOINT  ["/usr/bin/redis-server"]

talk about configuration here

Node Nodes! Time to setup a NodeJs cluster.

Same old, same old:

cd ..
mkdir node
cd node
touch Dockerfile

Here’s the Dockerfile:

# latest official node image
FROM node:latest

MAINTAINER Ermish

# Install nodemon
RUN npm install -g nodemon 

# Expose port
EXPOSE  8080

WORKDIR /data/app_node/

# Run app using nodemon
CMD ["nodemon", "server.js"]

So let’s break this dockerfile down:

Pull the latest Node image. This essentially installs npm.
Expose our node server port.
Point to our code and spin up our Nodemon server! (If you’re wondering what to do with your source code, don’t worry, it’s coming up.)

Wait a minute…what’s Nodemon?

Nodemon is a node wrapper that is similar to, but can also compliment forever. They both essentially serve the purpose of keeping your node server alive. The main differences I’ve seen are that Nodemon can watch your files and rebuild the server when you make any changes. This is top-notch when you’re doing development! It will also ensure your app doesn’t spin down for any reason, including exceptions getting thrown. If the app crashes for any reason, it will retry starting it up to a certain fail count.

Forever, on the other hand, I think is closer to a production node server wrapper. It does almost everything the same minus the file watching/rebuilding.

Let’s make a data container together, baby!

Data containers can be used several different ways. Deciding how to setup and use data containers has probably been the toughest decision throughout this setup. In this example, I’m using them as containers that hold source code that is compiled outside of the container and checked into souce control already compiled. This is the way I can ensure I have the same consistent compiled code base throughout all environments. Environment variables, such as connections strings, can be passed into the container without having to change any code.

Another common data container design is to have the data container be the actual build server. It can have a Github hook and compile the code each time a checkin is made. Having a build server container is awesome, but I think the actual files should still be in a separate container from the build server and rebuilt each time. I’ll skip the build server in this example.

There are two common ways to build the data container. One is to create a dockerfile that simply copies the files and creates a docker volume from them. The other option is to create them directly in the docker compose file which is the method I will be going with. Some people say that the dockerfile is a good separation of concerns, but since these data containers are only built for this app, I think skipping the dockerfile simplifies things.

Let’s do some composing

Remember that command that we ran in the beginning? It looked like this:

touch docker-compose.yml

Well, it’s time to make that file actually do something! Here’s the file completely built out:

version: "2"

services:
  node_demo:
    image: busybox:latest
    command: ["true"]
    volumes:
        - ../node_demo/dist:/data/node_demo #for node

  jekyll_demo:
    image: busybox:latest
    command: ["true"]
    volumes:
        - ../jekyll_demo/dist:/data/jekyll_demo #for jekyll

  nginx:
    build: ./images/nginx
    image: dockerdemo_nginx
    env_file: docker_env.env
    ports:
        - 5000:80
    links:
        - node:node1
        - node2:node2
        - node3:node3
    volumes_from:
        - node_demo
        - jekyll_demo

  mongodb:
    build: ./images/mongodb
    image: dockerdemo_mongodb
    env_file: docker_env.env
    ports:
        - 27017:27017
    volumes_from:
        - node_demo
        - jekyll_demo

  redis:
    build: ./images/redis
    image: dockerdemo_redis
    env_file: docker_env.env
    ports:
        - 6379:6379
    volumes_from:
        - node_demo
        - jekyll_demo

  node:
    build: ./images/node
    image: dockerdemo_node
    env_file: docker_env.env
    # ports:
    #      - 5060:8080
    links:
        - mongodb
        - redis
    volumes_from:
        - node_demo
        - jekyll_demo
  node2:
    build: ./images/node
    env_file: docker_env.env
    # ports:
    #      - 5061:8080
    links:
        - mongodb
        - redis
    volumes_from:
        - node_demo
        - jekyll_demo
  node3:
    build: ./images/node
    env_file: docker_env.env
    # ports:
    #      - 5062:8080
    links:
        - mongodb
        - redis
    volumes_from:
        - node_demo
        - jekyll_demo

So let’s break this compose file down:

Each of the dockerfiles that we have setup will now be built into an Image and hosted in a Service.
Let’s talk about those data containers some more. node_demo and jekyll_demo do not have dockerfiles, so essentially we use the same commands here to build an Image.
- First we build from an image.
- Docker requires us to run either a Run command or have an ENTRYPOINT. So here, we just pass in true for it to do nothing.
- Then we will create a docker Volume. I think the easiest way to explain this is to image a volume being a “network drive” for the services. All of the other services can read/write data from this volume. The way volumes handle data can be tricky and is better explained here.
Up next, are the rest of the services. These will use the dockerfiles that we built out earlier. I’ll explain these commands:
- Build builds the dockerfiles we’ve been setting up.
- env_file passes in any environmental variables you have. (connection strings, localization, etc.)
- ports allows you to forward a port to listen on. Important! In this example port 5062:8080, the right variable points inside the dockerfile. the left variable is the new value in the compose file.
- links allows one app/dockerfile to be aware of the other. In this example, we want the node servers to have access to the redis server
- volumes_from allows access to volumes created by other services/dockerfiles.

Ermergerd, it works!

That will achieve the same thing as using the docker cli to individually build and setup each service manually/one at a time. Instead, the docker compose file allows us to “script” out all of these steps in one easy to read file.

To actually run the compose file do this:

docker-compose up --build

This will run the services, but soon you will run into issues with cached images and volumes being invalid. As a result, I have a few small shell scripts I run instead that will delete an containers, images, and volumes that exist. Be careful as this essentially wipes anything docker related running on the server! However, this is my favorite part of docker! I treat the docker compose file as the exact image of what will be on the server. If I want to spin up any additional servers, I can just run the same compose file again and KNOW it will be identical.

Here’s the scripts:

docker-rebuild.sh

This script essentially deletes everything, but does not start the server.

# # Delete all containers
docker rm $(docker ps -a -q) --force
# Delete all images
docker rmi $(docker images -q) --force

# #Remove images not in compose file
docker rmi $(docker images -f "dangling=true" -q) 

docker-compose pull
docker-compose build

docker-start.sh

This script just starts the server and builds any images.

docker-compose build
docker-compose up

docker-stop.sh

This script stops the server.

#stop containers
docker stop $(docker ps -a -q)

Awesome! What about CI? (continuous integration)

There are so many ways to achieve CI with docker. The way I ended up going was to use Docker Hub. They give you a free private repository! Since I had several different containers I wanted to use, I ended up using tags as a way to store different images in the same repository. Essentially, my CI ended up looking like this:

Run the docker-rebuild.sh script
Tag the images
Push these images into my docker hub repository
Have docker hub run a script on my server to:
- stop the containers
- pull down the newly tagged images in my repository
- rebuild the server
- start the services again

Here’s the file for pushing the images to docker hub:

docker tag mydemoapp_node_demo ermish/mydemoapp:mydemoapp_node_demo
docker tag mydemoapp_jekyll_demo ermish/mydemoapp:mydemoapp_jekyll_demo
docker tag mydemoapp_redis ermish/mydemoapp:mydemoapp_redis
docker tag mydemoapp_node ermish/mydemoapp:mydemoapp_node
docker tag mydemoapp_nginx ermish/mydemoapp:mydemoapp_nginx

docker push ermish/mydemoapp

That’s all folks!

Hope you enjoyed the tutorial, and feel free to reach out with any questions!

Why I went with Docker

Tue, 19 Jul 2016 00:00:00 -0700

I’m a windows guy. Why do I need a Linux server?

I love to Windows! I can navigate around pretty well and love having the convenience of a GUI as you’ve probably read in my last post. Somewhere along the way, I purchased up a Mac and have been stuck in a world between macOs and Windows running in Parallels and on my desktop. Okay, I think I’m getting the hang of this.

Recently, I’ve been playing a lot with NodeJs and .NET Core. I decided it’s time to change up my hosted web technologies. Previously, I was using HostGator for PHP websites (I built my own MVC framework) and it was great for what I was doing at the time. So taking a look at what would support some of these new toys that I wanted to play with, I’ve realized a VPS sounds like what I wanted but they’re typically expensive. I stumbled across this place called DigitalOcean! They can give you an SSD based VPS for $5/month! Ok, this sounds great, but there’s a catch. All you start with is a Linux box with a bash terminal. That’s it. No CPanel. No GUI. Nuthin.

I’ve decided it’s time to learn how to setup a Linux server!

Honestly, I’m not completely new to the Linux game. I’ve been playing with Raspberry Pi’s since they came out, but most of the time it’s just been downloading an image or copy/pasting commands without completely knowing what they’re doing. I’ve decided to look into how to setup a Linux server. I’m used to Windows servers, so how hard can it be?

At first, I had to refresh on some Linux magix. If you’re starting from scratch with Linux, here’s some things I found useful to learn:

Terminal on Mac.
- I was coming from Windows and CommandPrompt, okay?
Linux distros.
- (Ubuntu, FreeBSD, Fedore, Debian, CoreOS, CentOS, etc.) I personally like Ubuntu for a full environment and CoreOs for more minimalistic setups.
Curl.
- Basically used for HTTP requests. Personally, I find it useful for pinging sites. (Like ping on Windows)
apt.
- (Similary to NPM, NuGet, Bower, etc, but for linux apps.

There’s a whole lot of other things to learn, but these are just some of the basics.

Why I went with Docker!

, I did some research to see how I should setup my server. My options as I saw them were:

Setup everything from scratch on a new Linux distro and install all my apps on a single image.
Use virtual machines for managing/distributing each of my different apps to run.
Use Docker.

Long story short, I went with Docker! My thinking was that, since I don’t know how to perfectly setup everything in Linux, I’m going to make mistakes. If it’s all on the same image, I might break something adding each new service and have to start all over. I’m quite familiar with VM’s, and I know the performance cost and complexity it brings with it. This is where Docker seemed to fit the bill!

If I setup each app in a different container, I can get each app working without affecting the others. Also, I found some good articles on the performance of Docker vs. VM’s. Also, if you’re using DigitalOcean, it integrates nicely with Docker and even has an image pre-built for it! Nice! Sounded good enough for me to try, so I went for it! Let me know what experience you’ve had and your thoughts on Docker vs. Virtual Machines. If you’re interested in trying out Digital Ocean or you want to support me, click this link, sign up, and you’ll get $10! That’s two free months!

Who Am I?

Tue, 19 Jul 2016 00:00:00 -0700

Hey, Internet!

My name is Philip Ermish. I earn my keep by making some pretty cool apps and software. I’m fortunate that I have a job I absolutely love, and am passionate about. Outside of work, I’m a man of adventure! While some weekends I enjoy a healthy dose of gaming, others, I’m planning my next trip to travel the world. The world is full of adventure and someone (me) needs to explore it!

If you haven’t notice yet, I’m a pretty positive person! The world is often a rough place and many days are difficult, but I believe positivity is a choice. It’s all about perspective. I try to find the positive things in whatever situation I encounter. You can’t always change your situation, but you can change how you respond to it.

If I sound like your new best friend, then hit me up on some social media! (Links below) If you’re not a fan, click here.

Specifically software

As far as software goes, I’m a full stack developer and love working with C# and all things Javascript. If you love open source software, then we’ve got something in common!

On the front end, I enjoy building a solid UI and the user experience is extremely important to me. This is where there’s power in simplicity! On the flip side of the coin, architecting and building out solid APIs/Services bring a satisfaction in their own way. Code maintainability and performance are critical points in my book.

Command Line Needs Intellisense

Tue, 12 Jul 2016 20:21:22 -0700

I’ll be one of the first people to say I’d rather click pretty GUI buttons to configure things instead of using a command line such as Command Prompt, Terminal, Bash, etc. I get that it’s powerful and a lot easier to manage, but there’s still something to be said about the convenience of clicking with a mouse vs typing a bunch of stuff. Have you ever found yourself forgetting a command? What about remembering all the different flags? I know I do. I You can easily look them up, but it’s so much easier to find a checkbox.

But it does….right?

Sure, most command lines have tab + tab functionality to complete stuff. You can also usually type -help or -h for some hints as well. This is cool but not exactly what I’m talking about. I’m thinking of something similar to your IDE where you get a dropdown with options and a short helpful description of the option and parameters.

Intellisense to the rescue!

How many times have you copied a command from an online source vs. remembering it all and power typing it out? Commands like sed '/./=' myFile.txt | sed 'N; s/\n/ /', and find . -type f -name "*.gz" -exec zgrep 'GET /foo' {} \; make my eyes water. Imagine popping up terminal and hitting Ctrl + Space, and window pops up with sed or find as options in it. Then when you type find, the next set of options and would show up. Perhaps, typing - would show all the flags available. All of this might be the perfect middle ground between the command line and nice GUIs!

Cool concept, but how would you develop against it?

Easy! Let’s pretend like we just invented Docker. There would be some .json or .yml configs that the command line would read from. When someone install Docker, it would add a set of command options to this config. So something like,

{
    'docker':{
       'ps':{
        'flags':{
            `a`: {
                description: 'This does stuff'
            }
        }
       },
       'run':{
       },
       'build':{

       }
    }
}

It’s probably already out there!

If this exists, or it’s being developed, shout it out in the comments below! I’ve looked at iTerm and something other options, but nothing looks exactly like this concept.

Hello World

Sun, 10 Jul 2016 20:21:22 -0700

In honor of the classic developer tradition, this seemed to be appropriate for the first post!