Clubhouse is a great tool for software teams to manage their work. It includes a Slack integration that can pick up ticket URLs in chats and expand them with details, and can also generate a message feed of activity on those tickets.

What it can't do however, is narrow down that firehose to just a few types of activity that are of interest. This post shows how to use Microsoft Flow (similar to IFTTT or Zapier) and Clubhouse's webhooks to build it yourself.

In the gallery below, you can see the gist of the flow:
1) The flow's trigger is receipt of a JSON payload into a webhook destination. This webhook URL is added to  Clubhouse's webhook integration in the Clubhouse settings.
2) The schema of that JSON is automatically created by posting in a sample payload from Clubhouse's webhooks API documentation (or just copy the code sample shown below)
3) A few conditions are checked - `actions` is present and set to `update`, `changes` exists under that and is set to `completed`, etc - and finally the inner block of JSON under `changes` is parsed to expose the fields of interest.
4) Finally, a message is posted to Slack that reports the activity type we're interested in.

Ultimately, the output ends up as a nicely formatted Slack message with a direct link back to the original ticket. The flow itself runs once per activity on any Clubhouse ticket, but only posts to Slack for those activities that we actually care about.

It would be great if Clubhouse would update their Slack integration to allow us to use multiple of them per workspace, and filter the output directly - but until that's possible, this hack has helped us raise the signal to noise ratio!

It's also possible to query the Clubhouse API directly from a flow (or an IFTTT, or a Zap). For example, I could have updated this to query the ticket details and pull out the owner's names, or the date it was started, etc. I'll leave that as an exercise for the reader...

There's a great question on Quora that asks people to explain their theses in layman's terms. (Every Ph.D. should be expressible in a single sentence, and some of the answers here have this down to a fine art!) It certainly isn't simple to explain where I blew three and a half years of my life, but here's my attempt.

My research answered the question of how you solve problems when the problem itself is changing while you try to solve it. Imagine you're trying to work out the fastest route from one side of your city to the other, but while you're working it out people keep having car accidents that block roads, tow trucks keep clearing previously blocked roads, and the local council is constantly building new roads (really really quickly!) Adding to that, even when you've worked out what you think is a good route, while you're driving it the roads are still changing constantly.

My work showed that in most interesting applications of this problem (not just roads and driving, it applies in lots of other contexts as well), the time you spent working out a solution is quite large. If you want the 'perfect' solution, it could be so large that you would have been better off to drive a slower route but not spend so much time thinking about it in the first place.

I found a way to quantify all these factors, and a way to solve what you really want; not "find me the fastest route across the city", but rather "get me to the other side of my city as fast as possible". I was also able to prove that my method was guaranteed to be at least as fast as any other method, and most of the time was much faster.

Oh yeah, and I built a robot to do the driving... :-)

In a lot more detail, here's how the technique actually works. (And I'm not just being self-indulgent here - somebody actually asked for this...) Everything comes down to time. If we stick with the driving example that'll help. What you really want is to get to the other side of the city in the shortest amount of timing, starting RIGHT NOW!

Let's focus on just the one decision point right at the start - whether to set off instantly on a beeline for your destination, or to sit and plan a better path for a few minutes and then set off. Let's use some easy numbers and say it's 100 minutes drive across the city via the best route, and 200 minutes via the worst route (the one you can calculate instantly.) Let's also say it takes 20 minutes to calculate that best route.

Your two options are:
a) Planning time of zero, plus driving time of 200 minutes = 200 minutes.
b) Planning time of 20 minutes, plus driving time of 100 minutes = 120 minutes.

Obviously, b) is the better option. But actually, this isn't just a binary decision. There are many other options in the middle ground. (Straying away from common parlance, there's a class of algorithms called anytime planners that help find these middle points.) Often, problems turn out to have a solution that takes perhaps 1 minute of calculation time, but results in a driving time of 101 minutes. So, it's not the best route, but the total time is 102 minutes which is better than the total time for the best route. (In technical language, this is the Pareto optimal decision.)

The key point is that the "best" route is not the best route when you take the planning time into account. (Except when it is. But that doesn't happen much in practice!)

Ok, let's step it up a notch. There's actually a catch here too - assessing all the possible points on the spectrum between the worst and best routes also takes time. Let's call that the Decision Making time. Since that counts for the total time too, you'll need to minimise it as well, which might mean that it's better to only think about perhaps 5 options, rather than 50.

Perhaps...

Alternatively if the right option was one of the 45 you didn't consider, then maybe it would have been better to spend the Decision Making time to find that option, and then ... ARRRGGGHHH!!!

If you're thinking this is all getting a bit meta, you're exactly right. This class of problems is called Meta-computing.

Ok, let's step it up yet another notch! In the driving example I discussed in my answer, the roads keep changing while you're driving. Ignoring a few of the less interesting considerations, this effectively means that you have to go through the same decision making process all the bloody time!

So the best you can do is to start moving (as long as it's in roughly the right direction) and keep adjusting your route while you're driving. Whenever you settle upon a new choice of route, start driving it, and simultaneously start thinking about what you might want to do next. Do that until you reach your destination, at which point you can collapse in an exhausted heap, completely unable to think of anything else. Why did you need to drive there again?

In terms of what you actually need to do with all the choices you make, it comes down to the problem at hand. First you guess how much Decision Making time to spend, then you spend it evaluating the options - which involves guessing how much Planning and Driving time each option will require. Then, you pick the option you've guessed is the best, and you start planning it. Finally, you take the plan and start driving it. Then you repeat.

It's at this point that you re-read that last paragraph and ask "so what's with all the guessing?" Well, unfortunately, reasoning about time is reasoning about the future. You don't know how long something is going to take until you've actually done it, by which point it's too late to use that information because you've just done the thing you had to do to get the time it was going to take to do the thing you were just having about to had been done. I think... 

The only solution to this is to guess. Much of the contribution of my thesis was designing and testing a whole bunch of different ways of doing these guesses.

In the end, what you can say about this technique is that it is guaranteed to be no worse than any other technique that has access to the same information. I proved that. It probably doesn't sound like much, but it's actually very important because a lot of the time you're actually much better than other techniques if you use my technique. And since you're not going to be worse, you might as well use mine, just in case it's better!

So that's the common parlance explanation. In mathematical terms it's:




where y* is the optimal set of parameters to apply to the system out of the set Y of all possible sets of parameters, and the 't's are the Decision Making, Planning, and Driving times respectively, summed over all future time until the destination is reached.

I've had a vague plan to augment my coffee table with some media centre controls for a while now, but when my brother's partner bought two MakeyMakeys for my son I uh... "borrowed" one for myself. Today I finally kicked off this project by re-mapping the inputs to keys I wanted it to trigger, but hit a difficulty with non-standard media keys for volume control.

Essentially, the MakeyMakey presents itself as a USB HID device - like a keyboard/mouse combo - and you then hook up anything conductive to an input, and use that to complete a circuit through to ground which then triggers a key or mouse movement. My plan is to have some coins or brass discs embossed into the surface of the table, and use these as attractive (and toddler-proof, since there will be no moving parts) keys.

Unfortunately, under the hood the MakeyMakey is essentially an Arduino board, and the HID implementation is designed to help Arduino's target market - not embedded software engineers. One irritating feature is that they want users to be able to easily say something like sendKey( 'a' ) rather than sendKey( 0x61 ), and in their infinite wisdom they've managed to implement this in such a way that you actually cannot send anything other than an ASCII character or modifier key. Great, we can signal to our typewriters to reset their carriage feed, but not send a volume up command because typewriters only have two volume settings anyway; 'loud' and 'obsolete'. I swear that joke was more funny before I wrote it down.

At any rate, for my first ever Arduino program, I've gone in and edited the core library to workaround this. This commit shows the necessary changes to the MakeyMakey code, but the additions may well be helpful for any other Arduino based projects that require HID device work.

I wrote my first open source ruby gem today. It's a pretty simple idea - supply a Gemfile or Gemspec and the gem tries to determine which license each included library falls under, and thus whether you have any requirements you must abide by with your own project. Here's an example output:

>> deriving_license ~/Code/rails_sample_app/Gemfile
Determining license for rails:
Trying from_gem_specification strategy...FAILED
Trying from_scraping_homepage strategy...SUCCESS
Determining license for adt:
Trying from_gem_specification strategy...FAILED
Trying from_scraping_homepage strategy...FAILED
Trying from_license_file strategy...CUSTOM
Determining license for app_constants:
Trying from_gem_specification strategy...FAILED
Trying from_scraping_homepage strategy...SUCCESS
Determining license for bcrypt-ruby:
Trying from_gem_specification strategy...FAILED
Trying from_scraping_homepage strategy...FAILED
Trying from_license_file strategy...CUSTOM

...
    
Detected 4 known licenses:
MIT: Expat License (14 instances)[http://directory.fsf.org/wiki/License:Expat]
Ruby: Ruby License (6 instances)[http://www.ruby-lang.org/en/about/license.txt]
BSD: FreeBSD Copyright (2 instances)[http://www.freebsd.org/copyright/freebsd-license.html]
GPL: GNU General Public License (2 instances)[http://en.wikipedia.org/wiki/GNU_General_Public_License]
The following dependencies have custom licenses: adt, bcrypt-ruby, bootstrap-sass, rack-protection, sqlite3

You can grab it from https://rubygems.org/gems/deriving_license or just by running 'gem install deriving_license'. Let me know if it's useful to you, and feel free to fix it up and submit a pull-request!

When I was 12 and professed an interest in computers and programming, this was the advice my friendly neighbour offerred. Being 12, I can't remember if I had a clever retort to this line, but it certainly struck with me.

The neighbour in question was an engineering manager, running a large enterprise team delivering various aspects of online voting systems for government (amongst other things.) That Australia still does not have online voting available to most of the population probably goes some way to explain his view. (For what it's worth, it's now available in NSW to disabled voters who can't reach a poling booth as a trial run of the service, which has been in development for over a decade. It is a complicated system due to all the negatives ramifications of stuffing it up, but this is still a stupidly long time!)

As I grew up, studied engineering, then physics, then robotics, and then ultimately ended up working as a software engineer (not a programmer? Here's why...), I've thought back to this line more often than you'd expect for such a throwaway remark. But the question that really bugs me is; was the remark engendered by his management of a large team of varying talents on a long, complicated, and tedious project? Or is there actually some truth to it?