briggysmalls / flipdot Goto Github PK

It would be nice to display a bell icon when new messages are available

There have already been problems with using a version of gomock that has a bug, because we are currently checking out the master branch with go get.

go modules would solve this, by listing dependencies using a known version.

#5 implemented a status icon to indicate new messages.

However the image file is called bell.png, when in reality the image is of an envelope symbol.

The image should be renamed to status.png

To ensure the gRPC service is always available, we need to renew LetsEncrypt certificates.

This should be set up as a cron job

Currently the clock displays something like:

Tue 1 Mar

When it might be nicer to use Ordinals from go-humanize to display:

Tue 1st Mar

The project is light on documentation.

If you ever want to show this off you should get to work.

• description of what the signs do / feature list / gif
• architecture diagram
• mock app for standalone app development
• development app/proxy dockercompose and yarn serve for web development
• dev. ops. deployment: certbot, noip, and netlify
• testing with gRPC cli docker image

When an expired token is provided, the returned message is instead:

Could not parse token: <token>

Confusingly sometimes the signs display top/bottom correctly, then other times they reverse (bottom/top).

The signs never appear 'flipped' upside-down, it is just the sequence that GetInfo returns signs can sometimes be the wrong way round. i.e.:

signs {
  name: "bottom"
  width: 84
  height: 7
}
signs {
  name: "top"
  width: 84
  height: 7
}

Having tried to run the python tests on the circleci, I have noticed tests sometimes failing. Suspicions are on the toml library parsing unreliably. Although I suppose I'm being reckless by relying on order.

It might be nice to be able to deploy updates to the sign remotely.

I've seen https://www.balena.io/, but that would probably be using a sledgehammer to crack a nut. What with a strapline of:

The infrastructure you need to develop, deploy, and manage fleets of connected devices at scale.

SSH access would do fine.

Currently it takes a clock tick for the first clock time to be drawn.

Instead the clock should be drawn at the beginning of the application loop.

The web app can be deployed crudely and then iteratively improved after the signs are installed.

So deploying the existing code would be good

For some reason, when the web deploy is performed by circleci the page becomes unreachable.

When the same commands are executed manually the deploy seems to succeed.

What is now driver is still called flipdot_controller throughout the codebase. The old name is pretty confusing: 'controller' is a matter of perspective, and now we are in the monorepo it is the wrong 'layer' to be considered a 'controller'.

Futhermore, in the app we have 'flipapps' and 'flipdot' modules. I dislike both names.

The time-dependent test TestActive expects a rough number of Toggle calls to occur during a time window.

This test is brittle and sometimes fails.

The noip2 tool is used to update noip with the latest IP address of the pi.

This should start on startup.

At the moment a huge amount of config is defined in cmd.go.

So much of it is boilerplate, redefining flags in viper and copying into a struct.

There must be a better way!

Currently expired JWT tokens are not detected correctly, instead being considered as a parse error.

The correct method of parsing is probably more like the Parse example.

Currently showing a message is initiated within the app by pressing the button.

However it might be easier for grandpa to visit a site on his iPad rather than get up and press the physical button.

If the app was restructured to have a UI service that had a ShowMessage rpc, this could be triggered by either the button press or some simple website.

The Nintendo font was fun for the clock. There might be justification for using a different font for this, where space is less of a concern?

When two messages are sent within a short space of time (<~2seconds?), the second message is lost.

There is currently no protection against this, meaning that if a message happens to arrive immediately after the time was updated then the message might be lost.

Commit 4dde421 introduced the behaviour that sendImages waits the frameDuration duration even if there is only one frame to send.

This is appropriate behaviour for the messages, but not for the clock.

The effect is that button presses are blocked for the frameDuration period after updating the time. Current settings put that as 10s in every 30s, which is causing the unresponsive button presses being observed currently.

Running docker-compose up often results in the app crashing because the driver hasn't come online by the time it starts.

I'm unsure whether the fix should be at the docker level or the app level.

It might make sense for the app to retry a few times.

But ultimately I think fixing it at the docker level is more appropriate. This might potentially utilise the "health checks" feature.

See https://stackoverflow.com/questions/31746182/docker-compose-wait-for-container-x-before-starting-y

The current font is quite difficult to read.

This font uses lowercase, which is a nice touch, but it is definitely more difficult to read compared with uppercase.

If a font that only uses uppcase glyphs was selected then, with fewer decenders, we'd be able to make use of the full height of the signs.

Currently the clock is not displayed until the next tick event.

Therefore the last frame of a message can be displayed for up to one whole minute. Instead the clock should be displayed after a frame tick elapses.

Currently the typescript and commonjs+dts plugins are still experimental at grpc/grpc-web.

Attempting to use either for source generation caused problems due to the fact that one protobuf file imports another in this repo. Issue tracked at grpc/grpc-web#523.

As a result this repo currently uses improbable-eng/grpc-web for both source generation from protobufs, and the accopanying library.

When the issue is resolved and/or typescript becomes officially supported, this repo should switch to using the official library.

Currently the app doesn't utilise the fact that it could turn the lights on/off when displaying a message.

Generated content (protobufs & mocks) seems to often be separated from hand-written code in go. One reason I've stumbled across is the difficulty of excluding individual files from coverage reports. The language doesn't really support this, as packages are really the most granular level, and there is not really a concept of a file.

Generated content should therefore be separated.