I made a thing!
It takes your promises on commits.to and turns them into dots on this graph
You need to modify the source code if you want to use this for yourself… making this post satisfies this promise for me:
http://kb.commits.to/write-a-forum-post-about-this-commitbee-robot
Request For Comment
Cheers!
Kingdon
I would love to have the commits.to capabilities integrated into Beeminder. I don’t have any tech skills to set this up myself. I often tell my wife that “I will do xyz…” and then don’t follow through. To get stung when I don’t follow through, and change my habits, would improve my life and make my wife happier!
So, what I built here is actually a lot simpler than that.
This tool isn’t meant to sting, it’s only meant to coax you to use commits-to even more. I was talking with @dreev a couple of months ago about how I can do something for Commits.To, and one of the ideas he had was for a simplest possible integration, sort of what’s described in https://github.com/commitsto/commits.to/wiki#simple-beeminder-integration
It’s not strictly that. How this tool behaves, you get a point each time you make a commitment, and you get another point each time you complete one. (On-time, late, doesn’t matter. Everything is a point, so for each promise you commit and finish, two points.)
It runs on Kubernetes (or Heroku, but I’m using Kubernetes). So it’s very easy to game your beeminder goal, if you are running out of time and none of your open Commits are able to be completed before time runs out: just make another promise.
The goal for me here wasn’t really to make a seriously useful integration, I just wanted something that would put my Commits on a graph. Mostly this is how I always use Beeminder. “Just put it on a graph, and good things will happen after that.”
One way this could definitely be improved is by making a better guide for how to install it for yourself.
Another caveat is that this is developed against commits.to:master branch, which means that it’s scraping HTML. It could be improved by rebuilding it against the 2.0/develop branch, which has a real full-featured API, and it would no longer require scraping. Again I just wanted to get my commits on a graph, and practice some of my OO design skills a bit, so I haven’t done that yet. But it’s coming soon.
(And it’ll have to come sooner if 2.0 goes live in the near future, since scraping HTML with nokogiri definitely won’t work with the next version, from what I can tell.)
Slightly unrelated: Last time I checked Heroku didn’t not offer SSL in their free plan, unfortunately. Are you using a Kubernetes host with a free plan? Do they offer SSL?
I’m using Kubernetes on Digital Ocean. It does not bundle SSL certificate capability as I understand it. I have Open Source credits in excess of what’s needed (like $40/mo for 2x 8GB droplets, the cluster is only the cost of the droplets.) I got the credits because I applied for them, with my Open Source project.
On top of Kubernetes, I am using some tools which I have installed myself in order to make this very easy and repeatable. Deis Workflow (Hephy Workflow) behaves like a Heroku host environment, to make deployment easier. I started with Buildpacks and eventually built a simple Dockerfile that I’m using instead, which was easier to customize and fully understand.
Kubernetes + Workflow + nginx-ingress + cert-manager handles SSL certs, renewal and generation, using LetsEncrypt. The only part which I have manually configured is DNS, which DigitalOcean also offers for free I guess.
My environment on Digital Ocean, provides a managed Kubernetes on par with Azure and Google offerings: AKS and GKE. It is very easy to maintain, I’ve been using it since it was in closed beta with never hardly any issues!
I feel like there’s a blog post in here about this setup, I haven’t written one yet but I’m happy to share.
Edit: But to be honest after thinking about it, there is no HTTP interface to this that would need SSL. It’s just a simple cron job or CLI interface. There is a little {status: “ok”} which you can hit through the “web” Procfile process type, if you deployed it on Heroku. It does not do anything other than make the health checks pass. You can disable it and just use the “cron” process.
Interesting! No kill like overkill 
I on the other hand have my little Beeminder thing sit on my mail server hosted by Vultr (Custom ISOs <3) for $5 a month. So not technically free but I’m already paying for it and the VPS is sitting idle most of the time so whatevs.
And I integrated it like so:
let
domain = "doerfler.io";
in
{
services.nginx = {
virtualHosts."${domain}".enableACME = true;
appendHttpConfig = ''
server {
listen 8042 ssl;
ssl_certificate /var/lib/acme/${domain}/full.pem;
ssl_certificate_key /var/lib/acme/${domain}/key.pem;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://localhost:8040/;
}
}
'';
};
networking.firewall.allowedTCPPorts = [
8042
];
}
{ config, pkgs, lib, ... }: let beegment = import ./beegment; in { systemd.services.beegment = { description = "Beegment Daemon"; serviceConfig = { ExecStart = "${beegment.out}/bin/beegment"; Restart = "on-failure"; SuccessExitStatus = "130 143"; }; path = with pkgs; [ jdk.home which ]; wantedBy = [ "multi-user.target" ]; after = [ "network.target" ]; }; systemd.services.beegment.enable = true; }
with import <nixpkgs> {}; stdenv.mkDerivation rec { name = "begment-${version}"; version = "1"; buildInputs = [ sbt ]; # Use nix-prefetch-git https://github.com/phdoerfler/beegment to obtain these # install nix-prefetch-scripts to get all prefetch utilities src = pkgs.fetchFromGitHub { owner = "phdoerfler"; repo = "beegment"; rev = "e6238fa09709a1a851d3ed491c3a08dc4b469d95"; sha256 = "0f8wy2r666ir7incnlcl6cwd677nj4wp1jpx1663dhl3aizdc8f5"; }; buildPhase = let userHome = "/tmp/`whoami`"; sbtOpts = "-Duser.home=${userHome}"; in '' mkdir -p ${userHome} sbt ${sbtOpts} pack ''; installPhase = '' mkdir -p $out cp -ra ./target/pack/* $out ''; }
And this all looks so funny because NixOS.
No kill like overkill
I get this a lot at work too, and I have to periodically remind people “you know we’re not just doing this one thing, right?”
It may be over-engineered if you just take this one thing in a vacuum, but the point of doing it this way is more to drive down the unique, special-snowflakeness of the deployment. I also have these great workflow tools for Kubernetes that make things much simpler (git remote is your main CD interface, and the CLI works exactly like Heroku did in 2013) … that I’m spending time on maintaining separately, so if I don’t use them what is it for 
To be totally fair, I think my Kubernetes deployment is about 8x larger than it needs to be, if I wanted to spend less, but it’s free money and will expire soon.