Show which git branches have been merged and can be deleted

At work, we generate quite a few feature branches, which get tested, and then merge into “develop”. The feature branches don’t get cleaned up frequently. Here’s a series of shell commands I cobbled together to show the most recent person to commit to the branch, and which branches have been merged into develop.

git checkout develop
git pull -r
(for branch in $(git branch -r --merged | grep -vP "release|develop|master") ; do git log -1 --pretty=format:'%an' $branch | cat ; echo " $branch" ; done) | sort | sed -e 's#origin/##'

The output looks something like this:

Jane Doe feature/something
Jane Doe feature/another-thing
Jane Doe feature/yet-another-something
Zane Ears feature/howdy

And they can be deleted as follows:

git push origin --delete feature/something

Add a camera via WPS to a LEDE/OpenWRT router

I have some WiFi cameras that can be added to a router via WPS. Here’s how I got it to work with one of my LEDE routers. On the other one, somehow, I broke its ability to do WiFi completely, so this can be dangerous — I had to re-install LEDE. YMMV.

OpenWRT/LEDE Instructions:

First, backup the router config — always a good idea!


opkg update
opkg remove wpad-mini
opkg install wpad hostapd-utils
opkg upgrade dnsmasq
cp /etc/config/wireless /etc/config/wireless.orig
vi /etc/config/wireless and change wps_pushbutton to '1' -- but only for one interface.

Check to see if WiFi is working. If not, use the ethernet port connected to a laptop to log back in, and update the firmware that isn’t broken. There may be a better way, but that’s worked for me.

Put the router into WPS mode (note: this times out after a while):

hostapd_cli wps_pbc

Other instructions say to run this (YMMV):

hostapd_cli -i wlan1 wps_pbc

Within a minute or so, push the WPS mode button on the camera.

Notes about OKRs, goals and pitfalls

At work, I’ve been asked to know our team OKRs and set some of my own. I’m new to this, and so I decide to google for information about them. OKR stands for Objectives and Key Results, and the idea is to:

  • make aspirational, easy-to-remember goals (objectives) that stretch the company, the team, and optionally, the individual, then write them down.
    • I.e. we’re trying to answer the question, “what strategic (big) things should we do next?”
  • determine key results — notice the plural — a set of actions and measurements that will indicate how close we came to meeting the big goal
    • indicated in numeric form. This is said to be the “secret sauce” that makes OKRs better than other forms of strategic goal setting. We aren’t aiming for a perfect score. In fact, a perfect score is indicative of problems.
  • share the goals and key results widely within a company and team because it helps get people aligned (unified) and makes them accountable.

OKRs are a tool meant to help us, and as with any process, we aren’t meant to become a slave of the tool. Adapt it to make it work, or find a better tool when it doesn’t work.

Setting objectives and defining key results takes time and thought. Otherwise, it may not yield value.

OKRs remind me of S.M.A.R.T. goal setting. So why do we need OKRs? Again, I googled for an answer, and it’s approximately this: With SMART goal setting, organizations and teams tend to forget to…

  • stretch — make aspirational, strategic goals
  • act and pursue their goal — accountability is important
  • align teams and individuals with the aspirational goals

Among the many helpful things I read, I found this from

Why should I split my goals into Objectives and Key Results?

…it helps to increase company-wide transparency as everyone should be able to understand the Objective. Key Results are often more technical and don’t appeal to, or aren’t understood by, everyone.

Objectives also represent key focus points for an organization or team. They should, therefore, be inspiring and easy to remember.

The same article linked to a Harvard Business School article titled “Goals Gone Wild”, which warn of the dangers of goal setting. OKRs are supposed to have safeguards against these pitfalls. Standard pitfalls of goals include:

  • focusing too narrowly or specifically — lose sight of other valuable things such as emergent opportunities and ethical behavior
  • not enough time given to achieve the goal, or a reporting period that is too long
    • yearly measuring is too long, that’s why the key results in OKRs are measured quarterly or more frequently.
  • overly challenging goals may encourage
    • lying about performance
    • cheating to attain the goal
    • taking unacceptable risks
  • creating a culture of competition rather than cooperation
  • the goals themselves killing motivation
    • I.e. a goal (a key result) for a CEO doesn’t necessarily make sense for an engineer

Ten years ago, my wife and I bought a Hyundai Sonata. Upon completing the purchase, the salesman asked us to give him a perfect score on Hyundai’s evaluation of the sales experience. He said anything besides a perfect score was unacceptable. My wife and I raised our eyebrows, knowing that he was gaming the system. I went along with it, knowing that Hyundai wasn’t getting an accurate measurement. I regret my decision, and I hope that Hyundai realized that perfect scores were indicative of problems in their measuring.



Windows: The OS you can’t rely on when you need to get important things done

It’s Christmas day, and we have my wife’s siblings and their children at our house. We’re doing a Google Hangouts call with their parents, who are on an LDS mission in Vanuatu.

Microsoft Windows asks when to schedule an update. I try to select 2 am, but whoever designed the software decided, in their wisdom, that I shouldn’t have that kind of control. Let’s see what else I can do.

It’s 1 pm, so I select 4 pm, and Windows seems to accept that choice. I go back to the Google Hangouts conversation.

And then Windows decides to update immediately, against my wishes. It’d be fine if it only took 5 minutes, but it goes on for hours. I am angry. I feel like purging Windows from our lives.

Microsoft, I hate the poor timing that you force on me. I hate not being in control of updates. This sucks. It stinks. You should do better.

So I grab our older, slower Windows computer, and power it up. Guess what? It’s completing an update as well. Inconvenient!

Fortunately, I have a Ubuntu Linux laptop that I use for work. I load Google Chrome, and thanks to WebRTC standards and Google Hangouts, I am able to get the video chat going again.

Ubuntu Linux and web standards save the day.

Windows: The OS you can’t rely on when you need to get important things done.

Linux: The OS that I can rely on when I need to get important things done.

Disclaimer: Your mileage may vary. I write software, with Linux as my desktop environment. I’m used to it, and it doesn’t do stupid things to me like Microsoft does… it just does different stupid things.

Thanks: I wish to express thanks to those individuals and organizations who gave us open standards including WebRTC, and those who gave us cross platform software, especially browsers like Chrome and Firefox.

Coming changes in Internet Protocols

Here’s what I think is a fascinating read. I’m excited about QUIC, and less excited that well-intentioned (sometimes draconian) protocol enforcement encourages software engineers to move nearly all protocols to run on top of HTTP or HTTPS — as a way to bypass the enforcement.

Internet protocols are changing

When a protocol can’t evolve because deployments ‘freeze’ its extensibility points, we say it has ossified. TCP itself is a severe example of ossification; so many middleboxes do so many things to TCP — whether it’s blocking packets with TCP options that aren’t recognized, or ‘optimizing’ congestion control.

It’s necessary to prevent ossification, to ensure that protocols can evolve to meet the needs of the Internet in the future; otherwise, it would be a ‘tragedy of the commons’ where the actions of some individual networks — although well-intended — would affect the health of the Internet overall.

Yubikey 4 GPG key generation (Ubuntu)

Install supporting software

sudo apt-add-repository ppa:yubico/stable
sudo apt-get update
sudo apt-get install scdaemon -y
sudo apt-get install python-setuptools python-crypto python-pyscard python-pyside pyside-tools libykpers-1-1 pcscd -y
sudo apt-get install yubioath-desktop yubikey-personalization yubikey-personalization-gui yubikey-manager  -y

Insert Yubikey and Generate key

gpg --card-edit
gpg/card> admin
gpg/card> generate
gpg/card> quit

export and backup the public keys, because the Yubikey only stores the private portion of the key

gpg --armor --export $KEYID >

Require touching the Yubikey button to authenticate, sign, or encrypt:

ykman openpgp touch aut on 
ykman openpgp touch sig on 
ykman openpgp touch enc on 

Change the pin

gpg --card-edit
gpg/card> admin
gpg/card> passwd
gpg/card> quit

Change yubikey information

gpg --card-edit
gpg/card> name
gpg/card> lang
gpg/card> quit


Blind adherence to process

Blind adherence to process also drives out creative people and rewards nonproductive bean counters.

From The Responsive Enterprise: Embracing the Hacker Way

To paraphrase something else the article said: Organizational memory needs to be periodically “reset” to keep up with operating in a changing world, else it can become an impediment to growth.

Another comment about process:

Being agile is about communication. The process needs to change with the situation. — Erik Meijer

Expect-CT Extension for HTTP

I recently learned of Chrome’s intent to remove public key pinning, and replace it with the new, draft, Expect-CT HTTP header. Ultimately, it should give us a safer web.

Chris Palmer explains:

To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function.

Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs. Site operators can generally deploy Expect-CT on a domain without needing to take any additional steps when obtaining certificates for the domain. Even if the CT log ecosystem substantially changes during the validity period of the certificate, site operators can provide updated SCTs in the form of OCSP responses (if their CA supports it) or via a TLS extension (if they wish for greater control). The combination of these mitigations substantially reduces the risk of DoS (either accidental or hostile) via Expect-CT deployment. By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning.