Git Product home page Git Product logo

aprsweather's Introduction

AprsWeather

Weather maps backed by data from the Automatic Position Reporting System (APRS).

Deployed at: hamwx.bielstein.dev

Running Locally

Before running, you'll have to set a value for the APRS_IS_CALLSIGN environment variable. This value will be used for APRS-IS login.

Docker Compose

The full application can be run locally using docker compose up -d --build. Once that is complete, load http://localhost:80 in your browser or use http://localhost:5148/WeatherReports to test the backend.

Once finished, it can be shut down with docker compose down.

Note: If running the client docker container directly, please add --build-arg ENVIRONMENT=Development to avoid including page view analytics code.

Local/Debug

To run without docker containers, which is helpful for debugging or quickly iterating on UI changes, run the following steps:

  1. Find and replace %ENVIRONMENT% with Development in src/AprsWeatherClient/wwwroot/index.html. This uses the development appsettings file when running the client. Careful not to commit this change in git.
  2. Launch the frontend and backend by opening a terminal for each the server and client, changing to each directory (i.e. src/AprsWeatherClient and src/AprsWeatherServer), and executing dotnet run or dotnet watch, as desired.
  3. Point your browser to http://localhost:5184/

Deploying

This application deploys with DigitalOcean App Platform. It has full continuous deployment for any code pushed/merged to main.

To bootstrap the deployment, use the doctl command line to deploy the application. Once deployed, take the application ID and save it as a GitHub Actions secret so it can be used for future updates and deployments.

APRS Reports and Gridsquare Locations

Good resources for finding and viewing APRS reports and gridsquare locations (good for debugging):

Analytics Reporting

Visitor analytics reporting is handled by Plausible.io. A script is added during deployment to report analytics data to them. When forking this repository, please remove or update src/AprsWeatherClient/deploy/analytics.sh.

aprsweather's People

Contributors

cbielstein avatar mirlahiji avatar

Stargazers

 avatar

Watchers

 avatar  avatar

Forkers

itsvvill jlee1414

aprsweather's Issues

AprsWeather Server Appears to Stop Receiving Messages After 2 Days

AprsWeatherServer logs indicated stopped receiving APRS packets from the server after almost exactly 2 days. This implies a timeout is being enforced.

Code needs to be written to either:

  • Periodically re-auth with the server (in case this helps keep alive)
  • Retry (or at least fail and restart the container) when connection is lost

The latter needs to be written either way for resilience as timeout isn't the only reason a connection could drop. The former could be nice to prevent docker container restart every few days.

Some investigation needs to be done to see if timeout can even be prevented by periodically sending a response message.

Consider moving `DateTimeOffsetExtension.MinutesSince()` logic to shared project

The DateTimeOffsetExtension.MinutesSince() method is used on the frontend to display how many minutes have passed since a packet was received. Similar logic is run on the backend to double check expiry. Consider either simply moving this extension to the shared project and reusing on the backend or adding it to the WeatherReport<T> class as a method.

Update logic to clear example location menu if a manual or automatic location is input

Currently, the dropdown of example locations will stay on the previous selection, even if a user types in a new value or uses their location.

Instead, when a user types in a location and clicks get weather OR if they use their location, the menu should reset to the hidden placeholder value to avoid confusion.

A stackoverflow discussion seems to imply this is possible using js interop OR potentially with blazor controls like InputSelect.

Add unit tests for logic in client

There are several existing methods in the client project that could and probably should be united tested.

  • DateTimeExtensions.cs
  • DateTimeOffsetExtensions.cs
  • PositionExtensions.cs

Potentially more. These don't have tests yet, but they should be added to find any bugs and protect against regressions.

Move doctl app spec validation to a different GitHub Actions workflow file

Description

As discovered in #42, the build action workflow is failing from forked repos because forked repos do not have access to secrets, but the doctl setup action requires a token (which is a secret). This causes the whole build workflow to fail.

I've opened digitalocean/action-doctl#67 to propose an enhancement on the action-doctl action to make the token optional for things like this that don't actually require authorization, but in the meantime, we/I should consider workarounds to unblock potential contributors.

Although I could simply remove that validation and rely on the post-merge deployment validation to catch bad changes to the app spec, I think the better option is to break out the app spec validation in to a new file that runs only when the app spec has changed. The result will run validation correctly when this repo has a change on the spec and will only run (and thus only fail) if forked PRs have a change to the app spec. The failure there would at least act as a flag to my review to check the app spec changes and run validation manually.

So the change here would be to move the doctl setup and validation lines from the build job in .github/workflows/build.yml in to a new file such as .github/workflows/validate_app.yml that only triggers on PR with changes to the workflow itself (e.g. .github/workflows/validate_app.yml) or the app spec (.do/app.yml).

For other settings of the action, we can follow similar settings to what's currently in build.yml (ubuntu, etc.)

Acceptance Criteria

  • doctl setup and validation code removed from the .github/workflows/build.yml build job
  • New .github/workflows/validate_app.yml (or similarly named) workflow created to validate DigitalOcean app spec only when that app spec has changed

Pull request template file is in wrong directory

Description

The pull request template file is currently at path .github/workflows/pull_request_template.md. According to the GitHub documentation it should be directly under .github/.

This is why the pull request template is not being applied.

Acceptance Criteria

  • .github/workflows/pull_request_template.md file moves to .github/pull_request_template.md
  • After merge, validate that the pull request template is applied when drafting a new PR

Update GitHub Actions to not use node:12

The following actions are triggering warnings on node version support ending soon: actions/checkout@v2, actions/setup-dotnet@v1

Update those to higher versions to get away from the warnings.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.