8 files changed, 561 insertions, 0 deletions
diff --git a/content/post/a-new-site.md b/content/post/a-new-site.md
new file mode 100644
index 0000000..aa2efbf
--- /dev/null
+++ b/content/post/a-new-site.md
@@ -0,0 +1,14 @@
++++
+Categories = ["Geek"]
+Description = "I made a website."
+Title = "A New Site"
+Date = 2014-06-07T20:16:16Z
++++
+
+I finally got around to making a website.  I decided to use [Hugo][] with a slightly-modified [Hyde theme][]
+
+Someday I'll make my own theme, probably using [Stylus][] for CSS processing. But for now, this will do.  The more important thing is just to create some content.
+
+[Hugo]: http://hugo.spf13.com/
+[Hyde theme]: https://github.com/spf13/hyde
+[Stylus]: http://learnboost.github.io/stylus/
diff --git a/content/post/back-again.md b/content/post/back-again.md
new file mode 100644
index 0000000..7107a56
--- /dev/null
+++ b/content/post/back-again.md
@@ -0,0 +1,14 @@
++++
+Description = "I'm back"
+Tags = ["website"]
+date = "2017-05-06T16:55:57+02:00"
+title = "Back again"
++++
+
+I've not made any posts for quite some time.  My life has changed
+quite a bit, I've emigrated from the UK and it's only now that I'm
+starting to feel more settled.
+
+I hope to start posting a bit more often.  Hopefully this post,
+despite being light on content, will help me to get back into the
+sharing mindset.
diff --git a/content/post/cedit-and-paredit.md b/content/post/cedit-and-paredit.md
new file mode 100644
index 0000000..23fb1c4
--- /dev/null
+++ b/content/post/cedit-and-paredit.md
@@ -0,0 +1,44 @@
++++
+Categories = ["Emacs"]
+Description = "Cedit and paredit for structural editing"
+Tags = ["development", "emacs"]
+title = "Cedit and Paredit"
+date = 2014-08-04T07:10:14Z
++++
+
+I recently discovered [cedit][], which provides some structural
+commands for editing c-like languages.  (See this
+[Emacs Rocks! episode][e14] if you're not familiar with the concept:
+it introduces [paredit][], a structural editing mode for lisps).
+
+So, it deals with curly braces and semicolons, keeping things balanced
+and correct as show in its [screencast][cedit-readme]. It mentions that it
+integrates with [paredit][] rather than duplicating *all* its
+functionality.  After setting up cedit, I decided to try enabling
+paredit alongside cedit and disabling autopair.  Once I did,
+however, I noticed an annoying formatting issue: If I were to type
+`foo` and then `(`, paredit would format this as `foo ()`, which makes
+sense, considering that paredit is written for lisps — s-expressions
+are usually separated by spaces — but not so much for c-like languages.
+
+I was thinking about disabling paredit and going back to autopair,
+when I decided to look through the configuration variables for
+paredit.  Turns out it provides
+`paredit-space-for-delimiter-predicates`, which is a list of functions
+that control whether a space should be inserted.  So, solving the
+formatting issue turned out to be pretty simple:
+
+```elisp
+(defun ap/cedit-space-delimiter-p (endp delimiter)
+"Don't insert a space before delimiters in c-style modes"
+(not cedit-mode))
+(add-to-list 'paredit-space-for-delimiter-predicates #'ap/cedit-space-delimiter-p)
+```
+
+Hopefully that saves someone some time if they try to use the two
+together.
+
+[cedit]: https://github.com/zk-phi/cedit
+[cedit-readme]: https://github.com/zk-phi/cedit#readme
+[e14]: http://emacsrocks.com/e14.html
+[paredit]: http://www.emacswiki.org/emacs/ParEdit
diff --git a/content/post/emacs-package-archive-statistics.md b/content/post/emacs-package-archive-statistics.md
new file mode 100644
index 0000000..2275c9a
--- /dev/null
+++ b/content/post/emacs-package-archive-statistics.md
@@ -0,0 +1,169 @@
++++
+Categories = ["Emacs"]
+Description = "Working out which package archives I'm using"
+Tags = ["emacs"]
+title = "Emacs Package Archive Statistics"
+date = 2014-07-19T13:19:54Z
++++
+
+I use [cask][] for managing the dependencies of my Emacs
+configuration.  Whenever I opened my `Cask` file, I wondered if I
+really was using all the sources I had defined:
+
+```elisp
+(source gnu)
+(source marmalade)
+(source melpa)
+(source melpa-stable)
+(source org)
+```
+
+It seemed quite strange that we have so many package repositories in
+the Emacs world and I'm not even using all of them.  I find this state
+less than ideal, much as
+[Jorgen Schäfer details][state of emacs package archives].  My ideal
+package repository would be once that works with VCS releases, mostly
+because it's a much simpler process to work with than having to sign
+up to yet another website just to upload a package, then ensure it's
+kept up-to-date on every release.
+
+As such, I prefer the concepts behing [MELPA][] and [MELPA Stable][] to
+those of [Marmalade][].  [GNU ELPA][] doesn't appear to allow any
+submissions and [org][org archive] is specific to [org-mode].  I've
+also noticed that many packages I find and use are on github and so
+work with the [MELPA][] system.  However, I don't like [MELPA's][MELPA]
+versioning: it just gets the latest code and puts the build date in
+the version, meaning that packages could break at any time.
+
+So, ideally I would use [MELPA Stable][] as much as possible and reduce my
+usage of [Marmalade][] and [MELPA][].  [GNU ELPA][] doesn't appear to have
+many packages, but I wasn't sure if I was using any.
+I couldn't see the information listed in the `*Packages*` buffer, so I
+decided to try to figure out how to generate some usage statistics.
+
+I found [how to get a list of installed packages][], but that just gives
+a list:
+
+```elisp
+(ace-jump-mode ag auto-compile auto-indent-mode autopair ...)
+```
+
+I needed to get more information about those packages.  I looked at
+where `list-packages` gets that information from.  It seems that
+`package-archive-contents` is a list of cons cells:
+
+```elisp
+(org-plus-contrib .
+				  [(20140714)
+				  nil "Outline-based notes management and organizer" tar "org"])
+```
+
+Then created a function to loop over the contents of
+`package-activated-list`, retrieving the corresponding contents of
+`package-archive-contents`:
+
+```elisp
+(defun package-list-installed ()
+  (loop for pkg in package-activated-list
+        collect (assq pkg package-archive-contents)))
+```
+
+This generates a list of arrays from `package-archive-contents`.
+There are some helper functions in package.el such as
+`package-desc-kind`.  `package-desc-archive` was exactly what I
+needed.  I happened to be using a pretest version of Emacs at the time
+and didn't know that it's not in 24.3, so I just made sure it was defined:
+
+```elisp
+(if (not (fboundp #'package-desc-archive))
+    (defsubst package-desc-archive (desc)
+      (aref desc (1- (length desc)))))
+```
+
+Weirdly, some of the arrays (seemingly the ones from the
+[org archive][]) had a different length, but the repository/archive was
+always the last element, which is why I used `(1- (length ))` and not
+a constant, like the other `package-desc-*` functions.
+
+To generate a list of statistics, I just needed to loop over the
+installed packages from `package-list-installed` and update a count
+for each archive:
+
+```elisp
+(defun package-archive-stats ()
+  (let ((archives (makehash))
+        (assoc '()))
+    (dolist (arc package-archives)
+      (puthash (car arc) 0 archives))
+    (maphash (lambda (k v)
+               (setq assoc (cons (cons k v) assoc)))
+             (dolist (pkg (-filter #'identity (package-list-installed)) archives)
+               (let ((pkg-arc (package-desc-archive (cdr pkg))))
+                 (incf (gethash pkg-arc archives)))))
+    assoc))
+```
+
+Running this gives a list of cons cells:
+
+```elisp
+(("gnu" . 0)
+ ("org" . 1)
+ ("melpa-stable" . 2)
+ ("melpa" . 106)
+ ("marmalade" . 1))
+```
+
+I wrapped it in an interactive function so that I could check the
+numbers quickly:
+
+```elisp
+(defun package-show-archive-stats ()
+  (interactive)
+  (message "%s" (package-archive-stats)))
+```
+
+With that, I removed `(source gnu)` from my `Cask` file.  Now I had
+another question.  What package was installed from [marmalade][]?  In
+the lisp fashion, I created yet another function:
+
+```elisp
+(defun package-show-installed-from-archive (archive)
+  (interactive (list (helm-comp-read "Archive: " (mapcar #'car package-archives)
+                                      :must-match t)))
+  (let ((from-arc (mapcar #'car
+                          (--filter (equalp (package-desc-archive (cdr it)) archive)
+                                    (package-list-installed)))))
+    (if (called-interactively-p)
+        (message "%s" from-arc)
+      from-arc)))
+```
+(Non-helm users can replace `helm-comp-read` with
+`ido-completing-read` or similar)
+
+Running this with the argument `"marmalade"` gives:
+
+```elisp
+(php-extras)
+```
+
+I checked on [MELPA Stable][] and [MELPA][], but it's not available
+there.  Given that I use [php-extras][] quite a bit at work, I can't remove
+[marmalade][] just yet.  However, as it's a git repository, it should be
+easy for me to create a recipe for MELPA.  Then I can remove marmalade
+from my [cask][] configuration.  Hooray for simplification!
+
+Hopefully, packaging in Emacs will become simpler in the future.
+There are some interesting things in 24.4 like pinning packages to a
+repository, which would allow [MELPA Stable][] to be used even when
+[MELPA][] defines the same package with a higher "version".
+
+[cask]: https://github.com/cask/cask/
+[state of emacs package archives]: http://blog.jorgenschaefer.de/2014/06/the-sorry-state-of-emacs-lisp-package.html
+[marmalade]: http://marmalade-repo.org/
+[GNU ELPA]: http://elpa.gnu.org/packages/
+[MELPA]: http://hiddencameras.milkbox.net/
+[MELPA Stable]: http://melpa-stable.milkbox.net/
+[org archive]: http://orgmode.org/elpa.html
+[how to get a list of installed packages]: http://stackoverflow.com/questions/13866848/how-to-save-a-list-of-all-the-installed-packages-in-emacs-24
+[php-extras]: https://github.com/arnested/php-extras
+[org-mode]: http://orgmode.org/
diff --git a/content/post/git-cloning-similar-repositories.md b/content/post/git-cloning-similar-repositories.md
new file mode 100644
index 0000000..96ea7b4
--- /dev/null
+++ b/content/post/git-cloning-similar-repositories.md
@@ -0,0 +1,19 @@
++++
+Categories = ["Development"]
+Description = "Speed up cloning of similar git repositories"
+Tags = ["git"]
+title = "Cloning Similar Git Repositories"
+date = 2014-06-22T08:35:24Z
++++
+With multiple similar git repositories, for example where a base repository contains a framework or base system installation and other repositories are created from that repository, it's possible to save some time when cloning down another repository by using the `reference` option to [git-clone][]:
+
+	git clone git@github.com/my/repo --reference another-repo
+(Where `another-repo` points to a local version of a repository.)
+
+The reference here doesn't have to be the base repository itself, it could just be another variant of it.  The speedup can be quite dramatic if the repositories have megabytes of shared history, from minutes to seconds.
+
+On a related note, I'm surprised that [GitHub][] doesn't allow for multiple renamed forks, which would be very useful in this scenario.  [BitBucket][] does support this, however.  It even has a 'sync' button for pulling updates from the base into the child repositories, which is very useful, especially for those who prefer GUIs over CLIs.
+
+[git-clone]:https://www.kernel.org/pub/software/scm/git/docs/git-clone.html
+[GitHub]:https://github.com
+[BitBucket]:https://bitbucket.org/
\ No newline at end of file
diff --git a/content/post/opening-projects-with-projectile.md b/content/post/opening-projects-with-projectile.md
new file mode 100644
index 0000000..d88d309
--- /dev/null
+++ b/content/post/opening-projects-with-projectile.md
@@ -0,0 +1,80 @@
++++
+Categories = ["Emacs"]
+Description = ""
+Tags = ["emacs", "lisp"]
+title = "Opening Projects with Projectile"
+date = 2014-07-12T09:12:34Z
++++
+
+I use [Projectile][] for working with projects in Emacs.  It's really good at finding files in projects, working with source code indexes (I use [Global][]), and with its [perspective][] support, it's also great at separating projects into workspaces.  However, I've always felt it lacking in actually opening projects.  I tend to work on different projects all the time and `projectile-switch-project` only tracks projects once they've been opened initially (despite the name, it works across Emacs sessions).
+
+With this in mind, I decided to try to add support for opening projects under a given subdirectory, e.g. `~/projects`, regardless of whether or not I've visited them before.
+
+I saw that projectile uses [Dash.el][] in some places, and after reading about [anaphoric macros], I decided that I'd try to use them to aid me.
+
+```elisp
+(defun ap/subfolder-projects (dir)
+  (--map (file-relative-name it dir)
+         (-filter (lambda (subdir)
+                    (--reduce-from (or acc (funcall it subdir)) nil
+                                   projectile-project-root-files-functions))
+                  (-filter #'file-directory-p (directory-files dir t "\\<")))))
+```
+
+First, this filters the non-special files under `dir`, filtering non-directories.  Then it runs the list of `projectile-project-root-files-functions` on it to determine if it looks like a projectile project.  To make the list more readable, it makes the filenames relative to the passed-in directory.  It runs like this:
+                  
+```elisp
+(ap/subfolder-projects "~/projects") =>
+("dotfiles" "ggtags" …)
+```
+
+So, we've got ourselves a list, but now we need to be able to open the project that's there, even though the folders are relative.
+
+```elisp
+(defun ap/open-subfolder-project (from-dir &optional arg)
+  (let ((project-dir (projectile-completing-read "Open project: "
+                                     (ap/subfolder-projects from-dir))))
+    (projectile-switch-project-by-name (expand-file-name project-dir from-dir) arg)))
+```
+
+By wrapping the call to `ap/subfolder-projects` in another function that takes the same directory argument, we can re-use the project parent directory and expand the selected project name into an absolute path before passing it to `projectile-switch-project-by-name`.
+
+We get support for multiple completion systems for free, since projectile has a wrapper function that works with the default system, ido, [grizzl][] and recently, [helm][].
+
+Then I defined some helper functions to make it easy to open work and home projects.
+
+```elisp
+(defvar work-project-directory "~/work")
+(defvar home-project-directory "~/projects")
+
+(defun ap/open-work-project (&optional arg)
+  (interactive "P")
+  (ap/open-subfolder-project work-project-directory arg))
+
+(defun ap/open-home-project (&optional arg)
+  (interactive "P")
+  (ap/open-subfolder-project home-project-directory arg))
+```
+
+I could probably simplify this with a macro, but I'm not sure that there's much advantage in it.  I only have two project types right now, after all.
+
+With this all set up, whenever I want to start working on a project I just type `M-x home RET` to call up the list.
+
+I also considered trying to add all the projects under a directory to the projectile known project list.  I didn't find it quite as easy to use, but it's available below if anyone would prefer that style.
+
+```elisp
+(defun ap/-add-known-subfolder-projects (dir)
+  (-map #'projectile-add-known-project (--map (concat (file-name-as-directory dir) it) (ap/subfolder-projects dir))))
+
+(defun ap/add-known-subfolder-projects ()
+  (interactive)
+  (ap/-add-known-subfolder-projects (ido-read-directory-name "Add projects under: ")))
+```
+
+[Projectile]: https://github.com/bbatsov/projectile
+[Dash.el]: https://github.com/magnars/dash.el
+[Helm]: https://github.com/emacs-helm/helm
+[Global]: https://www.gnu.org/software/global/
+[Anaphoric macros]: https://en.wikipedia.org/wiki/Anaphoric_macro
+[Perspective]: https://github.com/nex3/perspective-el
+[Grizzl]: https://github.com/d11wtq/grizzl
diff --git a/content/post/repository-management-with-ghq.md b/content/post/repository-management-with-ghq.md
new file mode 100644
index 0000000..d831c9e
--- /dev/null
+++ b/content/post/repository-management-with-ghq.md
@@ -0,0 +1,75 @@
++++
+Tags = ["development","git"]
+date = "2017-05-06T23:31:51+02:00"
+title = "Repository management with ghq"
++++
+
+I recently encountered [ghq][], a tool for automatically organising VCS-backed
+projects automatically.  Give it a repository URL, it will clone a project to
+your projects dir (set by `$GHQ_ROOT`) like so:
+
+```sh
+$ ghq get https://github.com/motemen/ghq
+# Runs `git clone https://github.com/motemen/ghq ~/.ghq/github.com/motemen/ghq`
+```
+
+I don't like the idea of having projects hidden away, so I set
+`$GHQ_ROOT` to `$HOME/projects`.
+
+From there, the `list` and `look` subcommands allow listing
+repositories and visiting them in the shell (actually a subshell).
+
+I wanted a nicer way to visit project directories.  Since I'm
+using [fzf][] as a fuzzy-finder, I thought it would be nice to use it
+for this.  I created a simple function, `fp` (find project) to do that:
+
+```sh
+fp () {
+  ghq look $(ghq list | fzf +m)
+}
+```
+
+I ran into some issues with the subshell of `ghq look` and wondered
+whether it might be possible to create a zsh command to remove the
+need for a subshell.
+
+I found that `fzf` includes a [cd-widget function][fzf-cd-widget] and created
+something similar that uses `ghq` instead of `find`:
+
+```sh
+cd-project-widget () {
+  local cmd="ghq list"
+  setopt localoptions pipefail 2> /dev/null
+  local dir="$(eval "$cmd" | FZF_DEFAULT_OPTS="--height ${FZF_TMUX_HEIGHT:-40%} --reverse $FZF_DEFAULT_OPTS $FZF_ALT_C_OPTS" fzf +m)"
+  if [[ -z "$dir" ]]; then
+    zle redisplay
+    return 0
+  fi
+  cd $(ghq list --full-path | grep "$dir")
+  local ret=$?
+  zle reset-prompt
+  typeset -f zle-line-init >/dev/null && zle zle-line-init
+  return $ret
+}
+zle -N cd-project-widget
+```
+
+It should be quite simple to modify it to work with other
+fuzzy-finders.  The basic idea is to show the output of `ghq list` for
+selection, and use `ghq list --full-path` with the selected candidate
+to print the correct directory for `cd`.
+
+What's really nice about this, is that I can bind it to a key
+sequence:
+
+```sh
+bindkey '\es' cd-project-widget
+```
+
+Now I can press `M-s` in a shell, start typing "dotfiles" and press enter to `cd`
+to my [dotfiles][] project. Pretty neat!
+
+[ghq]:https://github.com/motemen/ghq
+[fzf]:https://github.com/junegunn/fzf
+[fzf-cd-widget]:https://github.com/junegunn/fzf/blob/337cdbb37c1efc49b09b4cacc6e9ee1369c7d76d/shell/key-bindings.zsh#L40-L54
+[dotfiles]:https://git.alanpearce.eu/dotfiles
diff --git a/content/post/self-hosted-git.md b/content/post/self-hosted-git.md
new file mode 100644
index 0000000..b26f61b
--- /dev/null
+++ b/content/post/self-hosted-git.md
@@ -0,0 +1,146 @@
++++
+Description = "I describe my git server setup (using cgit and gitolite), and what it allows"
+Tags = ["development","git"]
+date = "2017-06-04T12:33:02+02:00"
+title = "A simple, powerful self-hosted git setup"
++++
+
+I had been using [gogs][] for about a year.  It worked reasonably
+well, as it focuses on being a lightweight self-hosted GitHub
+replacement.  However, that wasn't really what I wanted.  I just
+wanted to host my own projects, I didn't need things like issues, pull
+requests or wikis.
+
+I recently switched to [gitolite][] and [cgit][], as they were even
+lighter on resources, don't require another login and work without
+an external database.  Gitolite is unusual in its configuration: it
+creates a git repository with its configuration file.  I will describe
+how I use them, rather than how to set them up, as they both have
+enough documentation on that.
+
+My gitolite configuration file looks like this:
+
+```
+repo gitolite-admin
+    RW+     =   alan
+
+repo dotfiles
+    C   =   alan
+    RW+ =   alan
+    R   =   READERS
+    option hook.post-update   =    github-mirror
+
+repo [a-z].*
+    C   =   alan
+    RW+ =   CREATOR
+    RW  =   WRITERS
+    R   =   READERS
+```
+
+The first block just allows me to work with the configuration
+repository, as the initial setup only enables one specific public SSH
+key, whereas I have three keys that I configure gitolite with.
+
+The second configures my dotfiles specifically.  Naturally, I should
+be the only person with read/write access.  The `R = READERS` line
+allows remote configuration of read permissions via `ssh $DOMAIN
+perms` (explained further below).  The last line runs a mirror script
+(just `git push --mirror…`) so that
+my [dotfiles repository on GitHub][dotfiles-github] is updated when I
+push to my private version.
+
+## Wild (or magic) repositories
+
+The third block is where things get interesting.  gitolite has a
+feature called [wildrepos][], which allows configuring a set of
+repositories at once, using a regular expression to match the
+repository name.
+
+The really nice thing here is that the repository need not exist
+before applying the configuration.  Therefore, the line `C = alan`
+means that I can create a remote repository automatically by cloning a
+repository URL that doesn't already exist.
+I can clone and create a new repo simultaneously like so:
+
+```shell
+cd ~/projects
+git clone alanpearce.eu:some-new-repository
+```
+
+But with [ghq][], which I [blogged about before][using-ghq], I don't
+have to concern myself with where to put the repository:
+
+```shell
+$ ghq get alanpearce.eu:some-new-repository
+     clone ssh://alanpearce.eu/some-new-repository -> /Volumes/Code/projects/alanpearce.eu/some-new-repository
+       git clone ssh://alanpearce.eu/some-new-repository /Volumes/Code/projects/alanpearce.eu/some-new-repository
+Cloning into '/Volumes/Code/projects/alanpearce.eu/some-new-repository'...
+Initialized empty Git repository in /var/lib/gitolite/repositories/some-new-repository.git/
+warning: You appear to have cloned an empty repository.
+```
+
+The nice URLs come from this piece of my SSH configuration:
+
+```
+Host alanpearce.eu
+  HostName git.alanpearce.eu
+  User gitolite
+```
+
+## Configuring wild repositories
+
+This repository would be private by default, but I can change that by an
+SSH command.  Here's how I would do it:
+
+```shell
+ssh alanpearce.eu perms some-new-repository + READERS gitweb
+ssh alanpearce.eu perms some-new-repository + READERS daemon
+```
+
+The first command makes it visible in cgit, whilst the second makes it
+clonable via `git://` url.  I can make a repository
+publically-clonable, but invisible on cgit by only allowing the `daemon`
+user and not `gitweb`, if I wanted.
+
+I can also add or change the description of a repository shown on cgit like
+so:
+
+```shell
+ssh alanpearce.eu desc some-new-repository 'A new repository'
+```
+
+All the remote commands exposed by gitolite are described in the
+`help` command e.g. `ssh alanpearce.eu help`
+
+```
+hello alan, this is gitolite@oak running gitolite3 (unknown) on git 2.12.2
+
+list of remote commands available:
+
+	D
+	desc
+	help
+	info
+	motd
+	perms
+	writable
+
+```
+
+## Conclusion
+
+I much prefer creating repositories in this way.  It's much simpler
+and allows me to get on with working on the repositories rather than
+going through a multi-step process in a web browser.
+
+With cgit and gitolite, I have a minimal setup, that does exactly what
+I want, without consuming many system resources with daemons.
+
+[gogs]:https://gogs.io/ "Go Git Service"
+[gitolite]:http://gitolite.com/gitolite/
+[cgit]:https://git.zx2c4.com/cgit/
+[NixOS]:http://nixos.org
+[dotfiles-github]:https://github.com/alanpearce/dotfiles
+[wildrepos]:http://gitolite.com/gitolite/wild/
+[ghq]:https://github.com/motemen/ghq
+[using-ghq]:{{< relref "/post/repository-management-with-ghq.md" >}} "Repository management with ghq"