• User management
• Authentication with OpenID or some other external service
• A way of "subscribing" to an object or facility
• Adjust privacy policy

This has following implications:

• initial request takes 12 seconds
• subsequent requests take 200 ms
• requests after some events take 2 seconds

Needs to be strictly evaluated in order to be fast.

Would probably be nice to take the current disruption map and transform it into a heat map.

https://github.com/jwiegley/logging

The Elescore client must be re-designed to reflect the recent developments in the backend.

• The shift away from stations to objects must bring new ways of searching for elevators

• Login + Profile pages

• Faving of facilities/objects

• Removal of the disruption map

• Facility details

• Object details

• Disruption details

• Statistics page (maybe even by source)

• Theme will be Vuetify.

• Must have support for multiple languages.

This should be done in 1 second. Something isn't performing as it should.

"API" is there: https://www.bogestra.de/aufzuginfos/aufzuginfos-ueberblick.html

http://hackage.haskell.org/package/retry-0.7.7.0/docs/Control-Retry.html#t:RetryStatus

Basically, the DB integration does something like this:

• report everything is broken
• report nothing is broken

This can be fixed by chunking up the stream by seconds and processing each chunk comparing it to the chunk before that. If the difference is too high, the chunk can be ignored all together.

For this to work, the replaying and persistence of events must move into the source such that this becomes possible:

  P.each disruptionEvents >-> chunkP >
                                      |
clientP >-> monitorP >-> storeEventP >+> monitorP' >-> P.concat

This also enables the usage of appendMany, which I assume is faster.

As a follow up, the Source m a can then become a Functor and Monoid with which the handling later on is simplified.

At some point calculating every projection from scratch will not be possible anymore. Either because it takes a long time or the memory footprint will be too high.

A good first candidate is the list of all projections. It already takes very long to project. Once the UI catches up, there will also be filtering by facility or object as well as pagination.

To be able to support persisted projections there needs to be:

1. Some kind of projection state in the sense of "what was the last event processed"
2. Access to the sequence number of a persisted event
3. Database table creation based on the projection must occur

Orange thingie in the upper right corner…

is in the wrong formatting because the number is a child of the fa-warning icon which is not correct.
Wrong, current code:

<li class="dropdown dropdown-dark">
<i class="fa fa-warning fa-2x" style="padding: 20px; margin-right: 65px; color: orange;">&nbsp;169</i>
</li>

Correction proposal:

<li class="dropdown dropdown-dark" style="color: orange;">
  <i class="fa fa-warning fa-2x"></i>
  <span style="font-size: 2em;">169</span>
</li>

(tested in DOM)

Apparently they're quite slow. Writing to it after each event just makes this worse.

The reason "monitoring not available" indicates that no monitoring is available. We hence cannot assume it is out of order. Facilities in that state should not be graded.

I noticed a major outage of monitoring where around 3k facilities were reported out of order with reason "monitoring disrupted". To fix this, we need to intelligently filter out disruptions:

1. Facilities that were previously disrupted should still be assumed disrupted even though monitoring is not available at the moment
2. Facilities that have been active prior to the monitoring outage should be assumed operational

As for calculating the grade and total downtime, there are basically a few cases of which only 2 are relevant:

|-------------------------|
|------------------------>| Case 1: Monitoring dis. only
|------------<----------->| Case 2: Disruption before, resolved after
|-----<------>------------| Case 3: Disruption before and after
|------------>------------| Case 4: Disrupted after

-> monitoring dis only = ignore
-> Case 2 -> we don't know when it really ended; have to include