Update posts

posts/a-very-important-blog-post.org

@@ -1,4 +1,5 @@
 #+TITLE: A very important blog post
+#+SUBTITLE: Reading time: 0 minutes
 #+ID: a-very-important-blog-post
 #+PUBDATE: <2020-02-23 Sun 18:28>
 

posts/my-new-emacs-configuration.org

@@ -1,6 +1,10 @@
 #+TITLE: My new Emacs configuration
+#+SUBTITLE: Reading time: 0 minutes
 #+ID: my-new-emacs-configuration
 #+PUBDATE: <2019-10-06 Sun 18:18>
 #+TAGS: draft
 
 I'm still working on this one.
+
+foo bar baz
+ soo

posts/new-blog.org

@@ -1,7 +1,7 @@
 #+TITLE: New Blog
+#+SUBTITLE: Reading time: 4 minutes
 #+ID: new-blog
 #+PUBDATE: <2019-10-06 Sun 12:55>
-#+READING_TIME: 6s
 
 It's that time again... I've started a new project to build and maintain my site
 and of course it has to come with a new blog post. I'm trying to have it

posts/wdocker-compose.org

@@ -0,0 +1,162 @@
+#+TITLE: Making docker-compose easier with wdocker
+#+SUBTITLE: Reading time: 3 minutes
+#+PUBDATE: <2016-02-21>
+#+FILE_TAGS: wdocker docker docker-compose
+#+OPTIONS: num:nil toc:nil
+#+ID: wdocker-compose
+
+[[https://github.com/babab/wdocker][wdocker]] is a little utility written by a [[https://benjamin.althu.es][friend]] and former colleague
+of mine. It allows you to define commands for it in a
+~Dockerfile~. He wrote it because he used a lot of composite
+commands when writing docker images like:
+
+#+BEGIN_SRC sh
+  docker stop CONTAINER && docker rm CONTAINER && docker rmi IMAGE && \
+      docker build -t IMAGE && docker run --name CONTAINER IMAGE
+#+END_SRC
+
+By using wdocker to define a command he can greatly simplify his own
+workflow. Let's call it rebuild:
+
+#+BEGIN_SRC dockerfile
+  #wd# container = CONTAINER
+  #wd# image = IMAGE
+  #wd# stop = docker stop {container}
+  #wd# rm = docker rm {container}
+  #wd# rmi = docker rmi {container}
+  #wd# build = docker build -t {image}
+  #wd# run = docker run --name {container} {image}
+
+  #wd# rebuild: {stop} && {rm} && {rmi} && {build} && {run}
+
+  FROM ubuntu
+
+  # ...
+#+END_SRC
+
+Now he can use the following command instead of the list presented
+before:
+
+: wdocker rebuild
+
+* Syntax
+
+  wdocker has very simple syntax. You can define variables and
+  commands:
+
+  : #wd# variable = value
+  : #wd# command: program
+
+  Variables can be used by putting them in braces, including in other
+  variables, as you've seen in the first example.
+
+  : #wd# variable = -l
+  : #wd# list: ls {variable}
+
+  This would run =ls -l= when the command =wdocker list= is called.
+
+  As you can see you're not limited to using docker in your wdocker
+  commands. This property is what allows me to use wdocker in my
+  workflow.
+
+* Combining with docker-compose
+
+  I started using docker not too long ago at work to develop our
+  projects in. This is nice because it allows me to completely isolate
+  my development environments. Since we have a few processes running
+  together a single docker image isn't a great option, so I use
+  docker-compose to define and combine the containers I need.
+
+  As a side-effect this requires me to write long commands to do
+  something like run rspec tests:
+
+  : docker-compose run --rm -e RACK_ENV=test -e RAILS_ENV=test \
+  :     container bundle exec rspec
+
+  The alternative is defining a specialized test container with a
+  bogus entry command (such as ~true~) and use that, which would still
+  make the command:
+
+  : docker-compose run --rm test-container bundle exec rspec
+
+  Instead I can define a wdocker command in the ~Dockerfile~ used to
+  build the containers used:
+
+  #+BEGIN_SRC dockerfile
+    #wd# rspec: docker-compose run --rm -e RACK_ENV=test -e RAILS_ENV=test container bundle exec rspec
+
+    FROM ruby
+
+    #...
+  #+END_SRC
+
+  Now I can run the following, much shorter, command to run the rspec
+  tests:
+
+  : wdocker rspec
+
+  We also use cucumber for some other tests, which is even longer to
+  type in, adding the ~cucumber~ command is easy:
+
+  #+BEGIN_SRC dockerfile
+    #wd# rspec: docker-compose run --rm -e RACK_ENV=test -e RAILS_ENV=test container bundle exec rspec
+    #wd# cucumber: docker-compose run --rm -e RACK_ENV=test -e RAILS_ENV=test container bundle exec cucumber
+
+    FROM ruby
+
+    # ...
+  #+END_SRC
+
+  Now I can run =wdocker cucumber= as well.
+
+  The latest git version of wdocker passes any arguments after the
+  command name directly to the command to be executed. So if I need to
+  run tests in a single spec file I can just do:
+
+  : wdocker rspec spec/models/mymodel_spec.rb
+
+  We have two commands defined now that are 90% the same. I always use
+  the ~--rm~ switch to remove the started container after it's done, I
+  don't want a lot of containers piling up. I also always have to use
+  ~bundle exec~ to run commands, since the containers don't use rvm or
+  add the script directories to ~$PATH~. We can extract them to some
+  variables:
+
+  #+BEGIN_SRC dockerfile
+    #wd# run = docker-compose run --rm
+    #wd# exec = bundle exec
+    #wd# test = -e RACK_ENV=test -e RAILS_ENV=test
+
+    #wd# rspec: {run} {test} container {exec} rspec
+    #wd# cucumber: {run} {test} container {exec} cucumber
+
+    FROM ruby
+
+    # ...
+  #+END_SRC
+
+  Right now these commands always use the ~container~ service defined
+  in ~docker-compose.yml~. I could add it to the ~run~ command, but I
+  might need to run some commands on another container, but I can
+  define another variable:
+
+  #+BEGIN_SRC dockerfile
+    #wd# run = docker-compose run --rm
+    #wd# test = -e RACK_ENV=test -e RAILS_ENV=test
+    #wd# run-test-container = {run} {test} container
+    #wd# exec = bundle exec
+
+    #wd# rspec: {run-test-container} {exec} rspec
+    #wd# cucumber: {run-test-container} {exec} cucumber
+
+    FROM ruby
+
+    # ...
+  #+END_SRC
+
+  Now you also see that variables can be nested in other variables.
+
+  If you ever forget what you defined or if the mix of commands and
+  variables becomes too much for you, you can call the wdocker command
+  without arguments to see the commands you defined and the shell
+  commands they'll run.

project-config.el

@@ -67,7 +67,7 @@
 
 (defun project-config-reading-time (file)
   (with-current-buffer (find-file file)
-    (max 1 (/ (count-words (point-min) (point-max)) 225))))
+    (max 1 (/ (count-words (point-min) (point-max)) 228))))
 
 (defun project-config-print-file (file)
   (project-config-print-element