Archive

gpdmp-to-slack

September 14, 2017 » Geek

When Rdio shut down, I tried a few services before landing on Google Play. It’s not perfect, but it’s good enough and it’s better than Spotify. One thing that seemed lacking was a desktop application, but that need was neatly filled by the excellent GPDMP.

One lesser known feature of GPDMP is the JSON API, which manifests as a simple JSON file that the application updates with information about the playback. When Slack announced custom statuses, I though back to the days of instant messaging and the integrations that set your status to the song you were playing.

Demo

Implementing the link from GPDMP to Slack was, in all, a fairly simple matter. First, I looked at the JSON file to get a feel for the structure.

Short and sweet! Now to represent that in Go for decoding.

I didn’t need to represent all the elements, but it’s a small structure so I went ahead with it. I didn’t embed Song because I wanted to write an equality test for that struct on it’s own. That will get used later on.

Next, I needed a way to monitor that file for updates, which GPDMP does fairly often. fsnotify was the obvious choice, and an easy drop in.
I added a time based debounce so that we don’t read the file on every update, which would be excessive. This will delay updates by up to whatever debounce is set to, but I’m okay with that trade off.

Inside that debounce (at line 16) we open the file, decode it to a new struct and, if it’s playing, pass it off to a channel.

So, that’s it for getting updates from GPDMP! Less than 100 lines, formatted. Now I needed to watch that update channel and post changes in status to Slack.

I found an excellent Slack API client on a different project, so I grabbed that. I started by building a little struct to hold my client and state.

Then, during client initialization, we get the current custom status for the user and save it. This way, when you pause your music, it will revert to whatever you had set before.

Once it is initialized, we just need to range over our updates channel and post them to Slack when it changes. We set a timeout, because the GPDMP client won’t send updates when the song is paused, or if the app quits updating the file (i.e. you quit GPDMP). By putting the logic for the timeout on this side, we have less to pass over the channel, and we can revert properly if something goes awry in the api reading goroutine.

A little bit of glue in main and it’s ready!

You can browse the source and grab your copy at github.com/jmhobbs/gpdmp-to-slack

MAC Randomizer Alfred Script

December 19, 2016 » Geek

A recent conversation I had dealt with free wifi that limited the amount of time you could use it before it kicked you off. Now, while I support the right of wifi providers to do as they please, it’s an interesting question. AFAIK most tracking of that sort is done based on MAC addresses, which you can easily spoof if you want.

I wrote up a quick Alfred workflow that shells out from Python to do the real work. Note that if your wifi interface isn’t called en0 this won’t work for you.

Workflow Overview

The first script shells out to ifconfig to get the current address. Which gives output like the following. We are interested in that ether f4:5c:89:b3:37:e1 line. The first three octets are of a MAC are the Organizationally Unique Identifier (OUI) and we don’t need to change those, what we have is valid already.

Our script captures the OUI, then generates three more octets for the rest of the address, and prints it out.

Next we need to actually set this new random MAC. This is a privileged operation, so it we passed it directly to ifconfig it would error out. Long story short, if we want a nice authorization dialog we have to pass through applescript, russian nesting doll style.

I also added a way to reset it to the hardware value. The networksetup command handily has that for the taking. We just shell out, capture it and pass it through to ifconfig again.

You can download this workflow, comments and improvements appreciated.

Anonymous Code of Conduct Reporting With Twilio

August 29, 2016 » Geek

I’m lucky to be one of the organizers of NEJS Conf, a great little JavaScript & frontend conference here in Omaha, NE.

One of the core values we’ve held since the beginning of our conference was for it to be diverse, respectful and safe. To that end we adopted a Code of Conduct from the very beginning, based on the excellent JSConf example.

Our first year, we identified specific volunteers as our CoC points of contact. It seemed like a good plan, but our only report that year came via a circuitous route, which may have been a result of the face-to-face reporting we had defaulted to.

This spring I got to attend Twilio’s SIGNAL conference, and one neat thing they had in their Code of Conduct was an anonymous reporting phone line. Sounds like a good idea, and something fun to build!

The plan is simple: add a Twilio backed phone number which anonymizes incoming SMS and calls, then forwards them to the code of conduct reporting volunteer. Twilio makes this easy. At it’s core it’s just two TwiML files, one for SMS and one for Voice.

The SMS response contains the original message, a destination number to send it to (i.e. the CoC volunteer), a unique ID per reporter, and a link to the web interface. Behind the scenes we are doing a little but of work to assign the ID, match up numbers to destinations, etc, but not a lot of work total.

Voice is even simpler. Here we just connect the call to the CoC volunteer, and spoof the caller ID with the hotline’s number.

That’s the core of it, only took an evening to get things running. As I hinted above, I added a web interface for replying to reporters, as well as seeing the entire interaction in one place.

SMS Reporting Web Interface Voice Reporting

If you’d like to run this for your event, the source is all on github. https://github.com/jmhobbs/simple-coc

Tags: , , ,

Using Let’s Encrypt With Dreamhost

December 8, 2015 » Geek

2016-01-28

As pointed out in the comments, Dreamhost now supports Let’s Encrypt in the panel. No more workaround needed!

Let’s Encrypt has entered public beta, which means I should probably play with it!

This website is hosted on Dreamhost, which has a round about way of installing SSL certs, but it’s not too bad.

First, you have to go to your Dreamhost panel, then “Secure Hosting” and select “Add Secure Hosting”

Add Secure Hosting

From here, you pick your domain you want to secure. It’s a little bit wonky, in that it doesn’t show www. domains as subdomains in this list, so if you use that, you’ll need to just select the parent domain.

Doing this will issue you a self-signed certificate which will throw up scary browser warnings. We will fix that next.

I chose to run Let’s Encrypt on my laptop, so I followed the user guide to get things installed. Basically just a git clone.

Next you have to begin the request process.

  • certonly states that we only want a certificate generated, not installed.
  • --manual means that we are going to manually authenticate it.
  • --debug is used with the OS X version because it is experimental.

This will probably download some junk with homebrew, then it’s going to ask you some questions, the greatest of which is what domain you want to use.

With this in hand, it will generate an authentication string that you need to put into a file on the server.

Once you do that, it spits out your certificate into /etc/letsencrypt/live/[domain]

Back on the Dreamhost panel, you’ll want to click on “Edit” for the domain we are securing, then select “Manual Configuration”.

Edit Secure Hosting

You can clear the CSR field and then into the “Certificate” field, enter the content from cert.pem.

Into “Intermediate Certificate” I placed the contents of chain.pem

Lastly, we have to change the format of the private key file to one Dreamhost understands.

Then we paste privkey.key into the Dreamhost interface for “Private Key”, save and wait for our new certificate to get installed.

Editing Certificates

It’s magic!

Add Secure Hosting

Now I just have to fix all my asset URLs too…

Tags: , , ,

ChatOps: Snack Preview Script

November 15, 2015 » Geek

One of the things we’ve built at Pack is Snack, an iOS app which shows users five great dog photos every day.

Ideally, each Snack would be thematic, and curated. However, curation doesn’t always get done. Either no theme is apparent, or we just don’t get to it in time.

When there is no curated snack, we draw from our Editors Picks, a collection of the best dog photos available. This gives us quality content, even when we don’t have the chance to pick all five by hand.

There is a downside to this though. Some of our editors picks are specific to an event or time period. Like Christmas or Halloween photos. These wouldn’t be very good in a Snack in the middle of May.

So how do we balance the light editorial touch while making sure the random snacks are cohesive?

My solution was a preview injected into our chat. Every day a script grabs tomorrows Snack, makes a composite, and sends it into Slack for us to review. If we see something is off, we jump into the admin and fix it.

It’s fairly brute force, but a good example of centralizing tools around chat, which is something we try to do. First we get the photo information, then we download each photo. We take those and use ImageMagick to create a captioned composite. Finally, we upload that to S3 and send the link to Slack.

This first listing is pretty simple. We just send a request for tomorrows Snack JSON from the public API. You might wonder why we don’t just set day_requested to tomorrow, but the API doesn’t support that, and neither does the logic of the app. This runs on a cron job which mails failed runs to us using cronic, so we call raise_for_status() to explicitly fail on bad HTTP requests.

This next section shells out to download each image into a temporary file. Order matters in a Snack, so we use a counter instead of taking random filenames.

ImageMagick is a powerful suite of tools, and in the next block we use the montage command to stitch our photos together.

-title, as you might imagine, lets us write some title text onto the composite. -geometry specifies the size and spacing of each image, 300px square, with 20px of vertical offset from the title. Lastly, -tile lays out the images in a 5 by 1 grid instead of stacking them in the default method.

tinys3 is an awesomely light API to S3 uploads, and then we use the Slack Incoming Webhook integration to send the message to chat.

All in all a simple, effective piece code that drops needed information into our chat every morning. Here’s the whole listing for a complete picture.

And here is an example of a random Snack that needed correction. Problem solved!

Many thanks to tinys3 and requests.