From 7daef1874617fe543919f2c3a9a29ff129b54ec6 Mon Sep 17 00:00:00 2001 From: Christine Dodrill Date: Fri, 13 Mar 2015 12:27:24 -0700 Subject: [PATCH] remove medium backup --- .../medium/Dependency-Hell-a8bfb5b0d001.html | 62 ------------------- ...nt-Environments-in-Docker-1821c4725dc.html | 62 ------------------- .../medium/MPD-Via-Docker-5c51a9ef2f2e.html | 62 ------------------- ...-with-Atom-as-A-Vim-User-c3246deaf39b.html | 62 ------------------- ...IRC-Network-with-Panamax-caf48be24712.html | 62 ------------------- ...n-Development-with-Beego-56ea5ffd40f9.html | 62 ------------------- 6 files changed, 372 deletions(-) delete mode 100644 static/medium/Dependency-Hell-a8bfb5b0d001.html delete mode 100644 static/medium/Instant-Development-Environments-in-Docker-1821c4725dc.html delete mode 100644 static/medium/MPD-Via-Docker-5c51a9ef2f2e.html delete mode 100644 static/medium/My-Experience-with-Atom-as-A-Vim-User-c3246deaf39b.html delete mode 100644 static/medium/One-Click-IRC-Network-with-Panamax-caf48be24712.html delete mode 100644 static/medium/Web-Application-Development-with-Beego-56ea5ffd40f9.html diff --git a/static/medium/Dependency-Hell-a8bfb5b0d001.html b/static/medium/Dependency-Hell-a8bfb5b0d001.html deleted file mode 100644 index 1beae85..0000000 --- a/static/medium/Dependency-Hell-a8bfb5b0d001.html +++ /dev/null @@ -1,62 +0,0 @@ -Dependency Hell - exported from Medium
-
-

Dependency Hell

-
-
-A lot of the problem that I have run into when doing development with nearly any stack I have used is dependency management. This… -
-
-



Dependency Hell

A lot of the problem that I have run into when doing development with nearly any stack I have used is dependency management. This relatively simple-looking problem just becomes such an evil, evil thing to tackle. There are several schools of thought to this. The first is that dependencies need to be frozen the second you ever see them and are only upgraded once in a blue moon when upstream introduces a feature you need or has a CVE released. The second is to have competent maintainers upstream that follow things like semantic versioning.

Ruby

Let’s take a look at how the Ruby community solves this problem.

One job I had made us need to install five versions of the Ruby interpreter in order to be compatible with all the different projects they wrote. To manage the five versions of the Ruby interpreter, they suggested using a widely known tool called rbenv.

I got 99 problems but several different entire versions of a programming language and its standard library is one.

This isn’t actually the full list of rubies that job required. I have decided not to reveal that out of interest of privacy as well as the fact that even Gentoo did not ship a version of gcc old enough to build the oldest ruby.

After all this, of course, all the dependencies are locked using the gem tool and another helper called bundler. It’s just a mess.

There are also language design features of ruby that really do not help with this all that just make simple things like “will this code run or not” be determined at runtime. To be fair, Python is the same way, as is nearly every other scripting language. In the case of Lua this is beyond vital because of the fact that Lua is designed to be embedded into pretty much anything, with arbitrary globals being set willy-nilly. Consequently this is why you can’t make an autocomplete for lua without executing the code in its preferred environment (unless you really just guess based on the requires and other files present in the directory).

Python

The Python community has largely copied the ruby pattern for this, but they advocate creating local, project-specific prefixes with all of the packages/eggs you installed and a list of them instead of compiling an entire Python interpreter per project. With the Python 2->3 change a lot of things did break. This is okay. There was a major version bump. Of course compiled modules would need to be redone after a change like that. I think the way that Python handles Unicode in version 3 is ideal and should be an example for other languages.

Virtualenv and pip is not as bad as using bundler and gem for Ruby. Virtualenv very clearly makes changes to your environment variables that are easy to compare and inspect. This is in contrast to the ruby tools that encourage global modifications of your shell and supercede the packaged versions of the language interpreter.

The sad part is that I see this pattern of senseless locking of versions continuing elsewhere instead of proper maintenance of libraries and projects.

Insanity

To make matters worse, people suggest you actually embed all the source code for every dependency inside the repository. Meaning your commit graphs and code line counts are skewed based on the contents of your upstream packages instead of just the code you wrote. Admittedly, locking dependencies like this does mean that fantastic language level tools such as go get work again, but overall it is just not worth the pain of having to manually merge in patches from upstream (but if you do think it is worth the pain contact me, I’m open for contract work) making sure to change the file paths to match your changes.

The Solution

I believe the solution to all this and something that needs to be a wider community effort for users of all programming languages is the use of a technique called semantic versioning. In some lanaguages like Go where the import paths are based on repository paths, this may mean that a new major version has a different repository. This is okay. Backward compatability is good. After you make a stable (1.0 or whathaveyou) release, nothing should be ever taken away or changed in the public API. If there needs to be a change in how something in the public API works, you must keep backwards compatabilty. As soon as you take away or modify something in the public API, you have just made a significant enough change worthy of a major release.

We need to make semver a de-facto standard in the community instead of freezing things and making security patches hard to distribute.

Also, use the standard library more. It’s there for a reason. It doesn’t change much so the maintainers are assumed to be sane if you trust the stability of the language.

This is just my $0.02.

-
-
- - \ No newline at end of file diff --git a/static/medium/Instant-Development-Environments-in-Docker-1821c4725dc.html b/static/medium/Instant-Development-Environments-in-Docker-1821c4725dc.html deleted file mode 100644 index 9bb09c6..0000000 --- a/static/medium/Instant-Development-Environments-in-Docker-1821c4725dc.html +++ /dev/null @@ -1,62 +0,0 @@ -Instant Development Environments in Docker - exported from Medium
-
-

Instant Development Environments in Docker

-
-
-I have been using a few shell scripts for turbocharging development using Docker and today I have released the first version of a simple… -
-
-

Instant Development Environments in Docker


I have been using a few shell scripts for turbocharging development using Docker and today I have released the first version of a simple tool I call “dev”. Usage is very very simple.

$ dev up
Starting up container for spike
spike-dev (43c5c1) running!
To use this container please attach to it with:
$ docker attach spike-dev
$ docker attach spike-dev
docker:dev:spike ~
-->

I have made a simple asciinema recording describing the process of setting up and tearing down these containers. The development environments have the code you are working on mounted to ~/dev in the container.

The containers are defined by a simple manifest file in yaml:

base:     xena/base
repopath: github.com/Xe/test
golang: false
ssh: true
user: xena
projname: test

Right now dev is a very immature tool and currently Works For Me ™. If you have any issues with it or questions about it, please open an issue on its GitHub issue tracker.

Thanks for taking a look at it and please let me know if it works for you too!

-
-
- - \ No newline at end of file diff --git a/static/medium/MPD-Via-Docker-5c51a9ef2f2e.html b/static/medium/MPD-Via-Docker-5c51a9ef2f2e.html deleted file mode 100644 index 016cc9c..0000000 --- a/static/medium/MPD-Via-Docker-5c51a9ef2f2e.html +++ /dev/null @@ -1,62 +0,0 @@ -MPD Via Docker - exported from Medium
-
-

MPD Via Docker

-
-
-Today I got mpd set up inside docker to replace running it locally. -
-
-

MPD Via Docker

Today I got mpd set up inside docker to replace running it locally.

Being the perfectionist I am, I also got a simple web UI for mpd (ympd) set up.

You can find the source repos here:

Readmes will be in each repository shortly.

-
-
- - \ No newline at end of file diff --git a/static/medium/My-Experience-with-Atom-as-A-Vim-User-c3246deaf39b.html b/static/medium/My-Experience-with-Atom-as-A-Vim-User-c3246deaf39b.html deleted file mode 100644 index 8195368..0000000 --- a/static/medium/My-Experience-with-Atom-as-A-Vim-User-c3246deaf39b.html +++ /dev/null @@ -1,62 +0,0 @@ -My Experience with Atom as A Vim User - exported from Medium
-
-

My Experience with Atom as A Vim User

-
-
-Historically, I am a Vim user. People know me as a very very heavy vim user. I have spent almost the last two years customizing my .vimrc… -
-
-

My Experience with Atom as A Vim User

Historically, I am a Vim user. People know me as a very very heavy vim user. I have spent almost the last two years customizing my .vimrc file and I have parts of it mapped to the ways I think. Recently I have acquired both a Mac Pro and a Surface Pro 3, and my vim configuration didn’t work on them. For a while I had used Docker and the image I made of my preferred dev environment to shim and hack around this.

Then I took a fresh look at Atom, Github’s text editor that claims to be a replacment for Sublime. Since then I have moved to using Atom as my main text editor for programming in OSX and Windows, but still using my fine-tuned vim setup in Linux. I like how I have Atom set up. It uses a lot of (but not all sadly) the features I have come to love in my vim setup.

I also like that I can have the same setup on both my Mac and in Windows. I have the same vim-mode bindings on both my machines (I only customize so far as to add :w and :q bindings), and easily jump from one to the other with Synergy and have little to no issues with editor differences. I typically end up taking my surface out with me to a lot of places and will code some new ideas on the bus or in the food court of the mall.

Atom gets a lot of things right with the plugins I have. I have Autocomplete+ and a plugin for it that uses GoCode for autocompletion as I type like I have with vim-go and YouCompleteMe in Vim. Its native pacakge support and extensibility is bar none the easiest way to be able to add things to the editor I have ever seen.

But there are problems with Atom that are mostly based on my usage of text editors and my understanding of programming with Javascript, Coffeescript, HTML and CSS. Atom is a mostly Coffeescript editor, it does mean that at runtime I can customize almost any aspect of the editor, but I would have to learn one if not 5 more languages to be able to describe the layouts or interfaces I would like to add to this editor. It also being a hybrid between a web application and a normal desktop application means that I am afraid to add things I normally would such as raw socket support for being able to collaborate on a single document, PiratePad style. Additionally, the Vim emulation mode in Atom doesn’t support ex-style :-commands nor <Leader>, meaning that a fair bit of my editing is toned down and done more manually to make up for this.

I wish I could just use vim natively with my preferred setup on Windows, OSX and Linux, but for now Atom is the lesser of all the evils.

I miss you

Update: I am now atom-free on my surface pro 3

So this is the power of vim? Not bad, not bad at all.
-
-
- - \ No newline at end of file diff --git a/static/medium/One-Click-IRC-Network-with-Panamax-caf48be24712.html b/static/medium/One-Click-IRC-Network-with-Panamax-caf48be24712.html deleted file mode 100644 index 832d0ef..0000000 --- a/static/medium/One-Click-IRC-Network-with-Panamax-caf48be24712.html +++ /dev/null @@ -1,62 +0,0 @@ -One-Click IRC Network with Panamax - exported from Medium
-
-

One-Click IRC Network with Panamax

-
-
-Panamax is an exciting new technology by the smart people at CenturyLink Labs. What really excites me about Panamax is how it allows for a… -
-
-

One-Click IRC Network with Panamax

Panamax is an exciting new technology by the smart people at CenturyLink Labs. What really excites me about Panamax is how it allows for a more purely Docker-native workflow than existing products such as Deis or Flynn. However, this project’s youthfulness does mean it is lacking in other key areas, but for the purposes of this example they can largely be ignored.

In my dotfiles repo I have a nice tutorial set up on using Panamax in Google Compute Engine. The provision script was the result of running into annoying undocumented systemd behavior, but is simple enough that I would suggest using it.

I created a simple proof of concept that Panamax is compatible with a Docker-native workflow by creating a simple, single click IRC test network using Panamax. This is purely ephemeral and should not be used in any serious or production network, but it does show that Panamax can do things that Flynn and Deis can’t.

Panamax running my IRC network template on Luj.

After setting this up, a useful first step is to connect to it with any standard IRC client. In my example here I am going to use Irssi.

The MOTD and services advertisment

This test network in a box uses Elemental-IRCd, Atheme services and Iris to set up a bare minimum for a usable chat network. Elemental-IRCd is a daemon I have put a lot of work into over the last year and Atheme is probably the best choice in terms of services pacakges for an IRC network of any scale (Freenode runs Atheme).

This overall does not look as exciting as it is. IRC based services traditionally have been difficult to use on Docker-centric PaaS entries. If I wanted to do something like this on Deis or Flynn I might be better off scrapping the entire ircd and writing something in Go. Panamax allows Atheme and ircd to be used in an easy fashion, even if things have to be pre-seeded due to the overall immaturity of the platform.

I’m excited for Panamax and the things it could bring with it. It’s new of course but it is incredibly functional for such an early preview release and their Ruby code is very easy to read through and maintain.

Without Panamax setting up a test network like this would have taken someone 5 hours of looking up dependencies, reading horribly written documentation and slogging through forum posts to get something set up. Panamax makes it one click.

-
-
- - \ No newline at end of file diff --git a/static/medium/Web-Application-Development-with-Beego-56ea5ffd40f9.html b/static/medium/Web-Application-Development-with-Beego-56ea5ffd40f9.html deleted file mode 100644 index acffab1..0000000 --- a/static/medium/Web-Application-Development-with-Beego-56ea5ffd40f9.html +++ /dev/null @@ -1,62 +0,0 @@ -Web Application Development with Beego - exported from Medium
-
-

Web Application Development with Beego

-
-
-Beego is a fantastic web application framework from the Go China community. It currently powers some of the biggest websites in China, and… -
-
-

Web Application Development with Beego

Beego is a fantastic web application framework from the Go China community. It currently powers some of the biggest websites in China, and thus the world.

Let’s get started. For now I am going to assume you are running OSX or Linux. Getting Beego set up on Windows with the sqlite driver is nontrivial at best due to Windows being terrible.

Installing Beego

The Beego developers have made a tool called bee for easier managing of Beego projects. To install it, run:

go get github.com/beego/bee
go get github.com/astaxie/beego

The `bee` tool will be present in $GOPATH/bin. Please make sure this folder is in your $PATH or things will not work.

Creating a Project

Navigate to a directory in your $GOPATH and run the command `bee new quickstart`:

The `bee` tool created all the scaffolding we needed for our example program. Change into that directory and run `bee run`. Your application will be served on port 8080.

Now let’s take a look at the parts of Beego that are in use. Beego is a typical MVC style framework so there are 3 basic places you may need to edit code:

The Models are Beego’s powerful database-backed models (we’ll get into those in a little bit), the Views are normal Go html/templates, and the Controllers are the Go code that controls the Views based on the Models.

New Beego projects use Beego’s default HTTP router, which is similar to Sinatra or Tornado. The default router is very simple. It will only route `/` to the MainController that was generated for you:

The main file will shadow-include the router package which will seed the Beego router with your paths and site content. The MainController will embed beego.Controller so it acquires all instance methods that a Beego controller needs. Beego’s controllers offer many methods that could be used based on different HTTP verbs, but this simple example only overrides the GET verb to serve the site. The data that will be passed to the template is a map[string]interface{} as c.Data. The last line tells Beego what template to render for the page, in this case “index.tpl”. If you don’t set the template it will default to “controller/method_name.tpl” where method_name is the method that was called on the controller. In this example it would be “maincontroller/get.tpl”

-
-
- - \ No newline at end of file