It changes your deployment "atom" so instead of deploying compressed artefacts, you deploy containers. This has some advantages in itself (eg. it makes it easier to do gradual upgrades of your full stack, and you can run containers side by side on the same host), but is especially nice in combination with Mesos and Marathon which enables you to scale out horizontally across your cluster.

For Puppet you can use a validation script and a git commit hook to shorten the feedback loop on syntax errors: http://spoop.net/devops/2013/11/12/validate-puppet.html

Hey! I'm the writer of these tools and was kind of surprised to run into it here, since I have not posted about this before — the submitter must have been an adventurous PyPI visitor ;)

This particular tool was mostly written to replace all the ad-hoc aliases and symlinks with something that could be easily maintained and brought to other commands (eg. cdbm, lsbm, mvbm, cpbm, etc.). To speed things up some more there's also tab completion and prefix matching, which is pretty convenient IMO.

Well, actually I was using cdbm and thought it might be nice to mention it on HN. Then I noticed you added some other interesting stuff as well, so even more reason to submit it to HN :)

So not an adventerous PyPi visitor, just someone who was looking throught his bookmarks ;)

Oh and thanks a lot for creating and sharing it. It's a great tool which IMHO should become part of the 'default' cd, mv and cp.

It's different in that it's less cumbersome to maintain and that you can do more with the bookmarks than just 'cd' to it. For example, some other commands that are included are lsbm, mvbm and cpbm, which allows you to resp. list the files in a bookmark, and move or copy files to a bookmark. It's overall a lot more flexible and easier to extend common commands.

Is forking lots of common commands really less cumbersome to maintain than just using shell aliases or `expansion`?

EDIT: By forking, I mean "having to maintain separate frontends to", not the process startup overhead. (That's obviously inconsequential.) E.g. if I want to use a shortcut for a default path to clone a git repository from, then I would need gitbm. Etc.

The forking is not noticeable on today's machines; especially on this rather small scale. And yes, I would say that typing "cd `bm log`" is more cumbersome than typing "cdbm l". cdbm does pretty much the same behind the scenes anyway (with some error and argument checking), so why worry about that one extra mini process?

As noted above, I meant forking in the "fork a project" sense, not the fork(2) call.

I'm being a bit nitpicky, though, so I'm going to let it go.