senorpez / glowing-potato Goto Github PK

Version numbers should comply with Semantic Versioning (https://semver.org/spec/v2.0.0.html).

Currently, if something goes wrong in the planetary calendar calculation, a sentinel value of -1 is returned. This should instead throw an appropriate error for proper handling.

Add API calls for web-based clock.

Add an Alarm function to the application.

Should be able to:

• Set the alarm based on Standard Time
• Set the alarm based on Local Time

Add a feature to use something other than the current time in the application:

Should be able to:

• Set the Standard Time and see the corresponding Local Time.
• Set the Local Time and see the corresponding Standard Time.

Sending "Accept: application/vnd.senorpez.trident.v1+json;charset=INVALID" produces a 406 error, but no JSON error representation.

Add API call for Clock application for epoch offset. Have local storage for network-down fallback.

Error page for 500 is still the Spring Whitelabel page.

Upgrade to Spring Boot 2 and other updated modules.

When the Android app (by observation) clicks to a new tithe, the API CurrentTime endpoint is still .0007 tithes behind.

http://trident.senorpez.com/systems/1817514095/stars/1905216634/planets/-455609026/calendars/-1010689347/currentTime

For example, when the Android clock had gone to 1.75, the currentTime endpoint said 1.7493389919618494.

Add coverage calculations for android application.

At the very least, there seems to be support for Android ARM images, at least in a limited fashion, and Travis seems to be getting more and more fragile.

Investigate and test ability to move CI to Github Actions.

Create tests to prevent issues such as #9 from occurring.

The 406, Not Acceptable error still shows the wrong version of the required accept header.

{
  "code": 406,
  "message": "Not Acceptable",
  "detail": "Accept header must be \"vnd.senorpez.trident.v0+json"
}

Should be vnd.senorpez.trident.v1+json.

Consider deriving this message from the types supported by the API instead, so that it's automatically updated.

Add the ability to zoom (with a button and with gestures) on the Clock application, showing progressively more and more subtithes as you zoom in.

The lack of unit testing on the Python files is giving me heartburn.

Confirm that the calculations for local time are based on standard time (UTC) rather than a local timezone.

Sending "Accept: application/vnd.senorpez.trident.v1+json;charset=UTF-32" returns "Content-Type: application/vnd.senorpez.trident.v1+json;charset=UTF-32". As long as it's a valid charset, this is true.

I'm not sure if the content is actually UTF-32 encoded. I don't think it is, but the API should force UTF-8 headers and responses.

Curie links are currently not correct.

Differentiate "Not Found" errors between an object that doesn't exist and an object that is improperly requested from a parent.

As an example:

• Star System 1 contains Stars 1 and 2. Star 3 doesn't exist. Error should be "Star 3 does not exist."
• Star System 1 contains Stars 1 and 2. Star 3 is contained by a different Star System. Error should be "Star 3 is not part of this Star System" or something similar.

2 Eta Veneris currently doesn't have any planets, however, there is still a /planets link for 2 Eta Veneris.

Navigating to that link (http://trident.senorpez.com/systems/1817514095/stars/-1385166447/planets) produces a 500 Error.

Need to determine what the expected behavior should be.

API Artifact is still publishing as 0.1-SNAPSHOT

Secondary and other Stars in a Solar System will have dynamic parameters describing their motion around another object. (Primary stars are considered motionless to the frame of reference.) Add fields and API outputs.

Star resources not appearing after deployment.

We should probably have some tests for this type of thing?

The current implementation of #11 is a naive implementation that only allows for "Festival Years" to be templated out, a specific characteristic of the only currently-defined calendar.

Mature the implementation to allow flexibility between various calendar types.

For #12 API version needs to be updated to V1.

V0 calls need to error out.

Due to the fact that unit testing is non-existent (see #7), the following time is displayed:

47 FY 4 Caste 6 Day 5.00 Shift
Tue Feb 19 2019 11:33:05 GMT-0600 (Central Standard Time)
4635.999814020784

That's not right. There's no 5th Shift.

README needs to be filled out.

Add error page for 404 errors.

Add support for local calendar calculations:

• Time Adjust: The time difference between the start of the epoch (0 MJD2000) and the start of the local calendar.
• Standard Time to Local Time Conversions: Needed now would be standard hours per local day.
• Local Time to Local Time Conversions: Needed now would be local days per local year.
• Leap Year Information: Good luck!