aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorChristine Dodrill <me@christine.website>2019-01-17 07:11:16 -0800
committerChristine Dodrill <me@christine.website>2019-01-17 07:11:24 -0800
commit830ad3a7ae1758cfc73138482364c3094066f87c (patch)
tree6bf099ca307ee2abbaf2352f054875e5b83fc7ce
parent33acf1acaeb205c7703dd6140f698553594bb6df (diff)
downloadxesite-830ad3a7ae1758cfc73138482364c3094066f87c.tar.xz
xesite-830ad3a7ae1758cfc73138482364c3094066f87c.zip
blog: add some older articles from my medium blog
-rw-r--r--blog/atom-as-vim-2014-11-18.md59
-rw-r--r--blog/beego-2014-11-28.md71
-rw-r--r--blog/dependency-hell-2014-11-20.md105
-rw-r--r--blog/dev-2014-10-24.md46
-rw-r--r--blog/mpd-docker-2014-10-20.md26
-rw-r--r--blog/old-articles-2019-01-17.md16
6 files changed, 323 insertions, 0 deletions
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 \<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.
+
+---
+
+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:
+
+- [<https://github.com/Xe/docker-ympd>\
+ The ympd web frontend]
+- [<https://github.com/Xe/docker-mpd-kabaka>\
+ A good friend's patchset to mpd in the form of a docker
+ container]
+- [<https://github.com/Xe/docker-ncmpcpp>\
+ 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.