From 830ad3a7ae1758cfc73138482364c3094066f87c Mon Sep 17 00:00:00 2001 From: Christine Dodrill Date: Thu, 17 Jan 2019 07:11:16 -0800 Subject: [PATCH] blog: add some older articles from my medium blog --- blog/atom-as-vim-2014-11-18.md | 59 ++++++++++++++++ blog/beego-2014-11-28.md | 71 +++++++++++++++++++ blog/dependency-hell-2014-11-20.md | 105 +++++++++++++++++++++++++++++ blog/dev-2014-10-24.md | 46 +++++++++++++ blog/mpd-docker-2014-10-20.md | 26 +++++++ blog/old-articles-2019-01-17.md | 16 +++++ 6 files changed, 323 insertions(+) create mode 100644 blog/atom-as-vim-2014-11-18.md create mode 100644 blog/beego-2014-11-28.md create mode 100644 blog/dependency-hell-2014-11-20.md create mode 100644 blog/dev-2014-10-24.md create mode 100644 blog/mpd-docker-2014-10-20.md create mode 100644 blog/old-articles-2019-01-17.md diff --git a/blog/atom-as-vim-2014-11-18.md b/blog/atom-as-vim-2014-11-18.md new file mode 100644 index 0000000..87749ad --- /dev/null +++ b/blog/atom-as-vim-2014-11-18.md @@ -0,0 +1,59 @@ +--- +title: My Experience with Atom as A Vim User +date: 2014-11-18 +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 +file](https://github.com/Xe/dotfiles/blob/master/.vimrc) 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](https://atom.io/){.markup--anchor +.markup--p-anchor}, 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](https://github.com/atom/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 \, 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. + +--- + +Update: I am now atom-free on my surface pro 3 diff --git a/blog/beego-2014-11-28.md b/blog/beego-2014-11-28.md new file mode 100644 index 0000000..4e950c0 --- /dev/null +++ b/blog/beego-2014-11-28.md @@ -0,0 +1,71 @@ +--- +title: Web Application Development with Beego +date: 2014-11-28 +--- + +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`: + +![](https://d262ilb51hltx0.cloudfront.net/max/800/1*ATTbb_23WVmxgoFweXSXQg.png) + +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. + +![](https://d262ilb51hltx0.cloudfront.net/max/800/1*DG8Tl71KXYdiddV1x6m0GQ.png) + +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/template](https://godoc.org/html/template)s, and +the Controllers are the Go code that controls the Views based on the Models. + +![](https://d262ilb51hltx0.cloudfront.net/max/600/1*EZ1qIqeXNW_NfKuLbudogA.png) + +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: + +![](https://d262ilb51hltx0.cloudfront.net/max/800/1*t_oEyk6kSa1Y940m2fnwmg.png) + +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" diff --git a/blog/dependency-hell-2014-11-20.md b/blog/dependency-hell-2014-11-20.md new file mode 100644 index 0000000..f9eab55 --- /dev/null +++ b/blog/dependency-hell-2014-11-20.md @@ -0,0 +1,105 @@ +--- +title: Dependency Hell +date: 2014-11-20 +--- + +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](https://github.com/sstephenson/rbenv). + +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](https://github.com/tools/godep) 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](https://golang.org/cmd/go/#hdr-Download_and_install_packages_and_dependencies) +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](http://semver.org/). In +some lanaguages like Go where the [import paths are based on repository +paths](https://golang.org/doc/code.html#PackagePaths), 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. diff --git a/blog/dev-2014-10-24.md b/blog/dev-2014-10-24.md new file mode 100644 index 0000000..26232f6 --- /dev/null +++ b/blog/dev-2014-10-24.md @@ -0,0 +1,46 @@ +--- +title: Instant Development Environments in Docker +date: 2014-10-24 +--- + +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](https://github.com/Xe/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](https://asciinema.org/a/13158) 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](https://github.com/Xe/dev/issues/new). + +Thanks for taking a look at it and please let me know if it works for +you too! diff --git a/blog/mpd-docker-2014-10-20.md b/blog/mpd-docker-2014-10-20.md new file mode 100644 index 0000000..d74b4e3 --- /dev/null +++ b/blog/mpd-docker-2014-10-20.md @@ -0,0 +1,26 @@ +--- +title: MPD Via Docker +date: 2014-10-20 +--- + + +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](http://www.ympd.org/)) set up. + +You can find the source repos here: + +- [\ + The ympd web frontend] +- [\ + A good friend's patchset to mpd in the form of a docker + container] +- [\ + ncmpcpp for controlling mpd from the command line] + +Readmes will be in each repository shortly. diff --git a/blog/old-articles-2019-01-17.md b/blog/old-articles-2019-01-17.md new file mode 100644 index 0000000..3d6546a --- /dev/null +++ b/blog/old-articles-2019-01-17.md @@ -0,0 +1,16 @@ +--- +title: Old Articles Recovered +date: 2019-01-17 +--- + +# Old Articles Recovered + +I found an old backup that contained a few articles from my old [Medium](https://medium.com/@theprincessxena) blog. I have converted them to markdown and added them to the blog archives: + +- 2014-11-28 - [Web Application Development with Beego](https://christine.website/blog/beego-2014-11-28) +- 2014-11-20 - [Dependency Hell](https://christine.website/blog/dependency-hell-2014-11-20) +- 2014-11-18 - [My Experience with Atom as A Vim User](https://christine.website/blog/atom-as-vim-2014-11-18) +- 2014-10-24 - [Instant Development Environments in Docker](https://christine.website/blog/dev-2014-10-24) +- 2014-10-20 - [MPD Via Docker](https://christine.website/blog/mpd-docker-2014-10-20) + +I hope these are at all useful.