Added bundle_certs post.

content/bundle_certs.rst

+bundle_certs
+############
+
+:date: 2016-03-02
+:summary: Announce a new tool, bundle_certs
+
+Like I said in a previous blog post, I rarely blog but I run :code:`git init
+project-name` like crazy. So here's a new such repo, `bundle_certs
+<https://www.shore.co.il/cgit/bundle_certs/>`_. A simple shell script for
+bundling (in correct order) SSL certificates.
+
+How I start new projects
+------------------------
+
+This little tool, along with `ssl-ca <https://www.shore.co.il/cgit/ssl-ca/>`_
+and `ssh-ca <https://www.shore.co.il/cgit/ssh-ca/>`_ have some commonality in
+how I use them and this seems like a good opportunity to share. First of all I
+keep my rc files (like :code:`.vimrc`) in the
+`rcfiles <https://www.shore.co.il/cgit/rcfiles/`>_ repo. However I don't install
+as mentioned in the documentation. Instead I add as Git submodules and now I 
+can be reasonably sure that when I clone the rcfiles repository, the aliases and
+sourced files mentioned in :code:`.bashrc` are present. Here's how:
+
+.. code:: shell
+
+    ssh cgit 'git init --bare /srv/git/REPONAME'
+    git submodule add -f https://www.shore.co.il/cgit/REPONAME
+
+First I create the remote repository (most of you would probably use Github but
+I prefer self hosting). Then I add it as a Git submodule.
+
+Repository boiler-plate
+-----------------------
+
+Truth be told, there are more line of tests, documentation, license, etc. than
+there is actual code in these repositories. It happened to a few times that I
+added something nice to a repository that I wanted to have in all (or most) of
+my other repositories and in new repositories going forward.
+
+One solution I thought of is creating a base template repository that all
+others are forked from. The upside is if I change something in the base
+repository I can fetch it in all other repositories. The downside is not all
+repositories are the same (different license, programming language, pre-commit
+and git hooks). 
+
+Another option I know of are tools that manage a specific aspect of the repo,
+for example the license, or :code:`.gitignore`. A third option is using a
+project management tool like `Cargo <http://doc.crates.io/>`_ for Rust or
+`Leiningen <http://leiningen.org/>`_ for Clojure. But not all aspects or
+languages have such tools.
+
+The fourth option I'm thinking of is using a scaffloding tool, mainly `Yeoman
+<http://yeoman.io/>`_ as it seems to the most popular one but its focus is on
+JS and webapps.
+
+As of now, my plan is to try and maintain a base repo for certain project types
+and see how it goes (Yeoman would just take more time to get started with).