Dribdat has had many contributions from the IoT community, where often the initial goal for a hackathon project is to get an initial sensor reading. When cloud-enabled, this can be translated to a ping of a web service. In the open data community, we try to monitor the availability of public data endpoints and APIs with services like the Dribdat status page. Which leads me to the following idea:
- Create a background monitoring service which makes pings or RPC calls to the link that project teams enter as their "Demo link".
- The #anchor of the link could be used to indicate a text phrase, or perhaps even
{timestamp} which is typical for IoT APIs.
- Note the first time that the ping resolves in the project log. This could be used as a condition to promote the project to a particular stage.
- Note when the ping stops resolving. This might be of interest during the hackathon, but potentially even more so after the hackathon (as a form of lightweight impact monitoring).
- Color the hexagons (or just the interior bubbles) according to the status of the ping.
Technically, this would require a background job service like Celery, or integration with a third party proxy. We should research Python-based open source status monitoring and ping libraries.
Dribdat has had many contributions from the IoT community, where often the initial goal for a hackathon project is to get an initial sensor reading. When cloud-enabled, this can be translated to a ping of a web service. In the open data community, we try to monitor the availability of public data endpoints and APIs with services like the Dribdat status page. Which leads me to the following idea:
{timestamp}which is typical for IoT APIs.Technically, this would require a background job service like Celery, or integration with a third party proxy. We should research Python-based open source status monitoring and ping libraries.