forked from cadey/xesite
blog: add some older articles from my medium blog
This commit is contained in:
parent
33acf1acae
commit
830ad3a7ae
|
|
@ -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
|
||||||
|
|
@ -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`:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
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/template](https://godoc.org/html/template)s, 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"
|
||||||
|
|
@ -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.
|
||||||
|
|
@ -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!
|
||||||
|
|
@ -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.
|
||||||
|
|
@ -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.
|
||||||
Loading…
Reference in New Issue