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` pretty regularly. So here's a new such repo, `bundle_certs
<https://git.shore.co.il/nimrod/bundle_certs.git>`_. A simple shell script for
bundling (in the correct order) SSL certificates.

How I start new projects
------------------------

This little tool, along with `ssl-ca
<https://git.shore.co.il/nimrod/ssl-ca.git>`_ and `ssh-ca
<https://git.shore.co.il/nimrod/ssh-ca.git>`_ have some commonality in how I use
them and this seems like a good opportunity to share. I keep my rc files (like
:code:`.vimrc`) in the `rcfiles repo
<https://git.shore.co.il/nimrod/rcfiles.git`>_.  However I don't install them as
mentioned in the documentation. Instead I add them as Git sub modules 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 -b master -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 scaffolding 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).