milesbxf

###################################################
##
## Alertmanager YAML configuration for routing.
##
## Will route alerts with a code_owner label to the slack-code-owners receiver 
## configured above, but will continue processing them to send to both a
## central Slack channel (slack-monitoring) and PagerDuty receivers
## (pd-warning and pd-critical)
##

davecoutts

# This gist gives instructions to build a basic deb package of netatalk-3.1.11 using checkinstall on Ubuntu 18.04.
# With the idea being that you build the deb on your build server and install from the resulting deb in production.
# Given that the deb is packaged using checkinstall with basic options, think home use, not real production.

# Note that this build does not provide the spotlight feature.
# The tracker packages have been left out as the intent was to provide TimeMachine functionality only.


#------------------------------------------------------------
# STEP ONE - Make the Netatalk deb on a build machine

pfrazee

Communicating with Workers using HTTP

A design rationale.

See first: In-Application Sandboxing with Web Workers.

Web Workers interact with their Host Pages using a messaging channel (the postMessage API). Crucially for their programming model, the messages are asyncronous. This introduces a significant challenge for implementing Page APIs within a Worker – for instance, how do you port a GUI widget from the Page (where it can access the DOM) to a Worker, where it can only send async messages?

In my experience, two categories of solutions are suggested: use code-transformations to recreate Page-native APIs in the Worker, or introduce a new interface around messaging. In this gist, I'll explain why code transformations don't address the problem fully, and present a complete messaging solution based on HTTP.