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).