MyFlightBook playgrounds

[KayRJay]

Consider creating "playgrounds" so users and prospective users (and you) can experiment with MyFlightBook and new features. There could be a number of playgrounds that might ...

• have a pre-populated database of dummy data for flights, aircraft, images, etc.
• correspond to an artificial "user" with a dummy profile and other user-specific info
• exclude certain features (obviously no sharing and perhaps others)
• come in a variety of typical pilot types (student, CFI etc) or aircraft types or other varieties
• be available to "check out" for a period of time, for the exclusive use of a user
• have their data reset when the checkout period is done, minimizing total data storage needs

This would be useful for you as you develop new features for testing functionality, performance and usability. (Of course you probably already have your own private playground(s)!). It would be educational for users. They could:

• learn how to use the features of MyFlightBook
• test what's it like to fly a specific type of aircraft or be a certain kind of pilot
• create a simulated a path to certification (e.g., goal setting)

These playgrounds would allow users to play with the features of MyFlightBook without damaging their own, real data. Most users simply don't have the full richness of data that it is possible to represent in MyFlightbook.

Probably the way to create the set of relevant data is to make copies of existing data and anonymize them. No doubt there is a lot of work involved in all this, creating these different data sets and the "infrastructure" around playgrounds themselves. I'm sure the idea is a very low priority. It's just worth thinking about (someday).

[KayRJay]

Just to elaborate on one point ...

Instead of having a second (or third) full instance of the server and database, I’m thinking you could create a number of special-purpose playground users in the production database. Each user would have a manufactured list of flights, aircraft, profile settings etc. You’d copy data from other users to create data for these users, obscuring identifying details. It would of course take some effort to massage the data to create playground users with different characteristics as mentioned above, but that’s a one-time thing.

A user who wanted to play around would be assigned the name and password of a playground user. That password would expire in, say, a week. The data of playground users would be exported each night as usual, and then each week would be restored from an unmodified dataset and the password changed, so the playground user would be available for someone else to use.

[ericberman]

Dangerous to do because so much data is shared with other users. If they muck with aircraft, or models, or aircraft images, or clubs - it would muck with other users.

[KayRJay]

Sure, the playground would have to "exclude certain features (obviously no sharing and perhaps others)". Not sure how how much data is really shared and hard it would be to identify the things that shouldn't be permitted by a playground user. Here's a start:

• sharing (of any kind: flights, templates, ...)
• deleting (only?) images
• adding modifying aircraft, models, airports (or are those private?)
• publishing a club
• public information about pilots (if/when social features are added)

Are there many other data elements that would be "dangerous" in this environment? You'd of course need to check the user profile to disallow those features when a "player" attempts to use them.

If data pollution protection was added (per #488), it would perhaps be an easier way to prevent problems of the sort described above, and be a good feature anyway.

[ericberman]

See my comment on #490; I can't "disable" or "exclude" the sharing features - they are intrinsic to the very design and purpose of the system.

The definition of a playground is that it's a safe place to play -you can't hurt yourself or others. So I think a discrete instance disconnected from the live site is the only way to guarantee that.

[KayRJay]

As I commented in #490, if you record the creator and creation date for bad entities, you could easily identify the shared items that should be deleted when a particular playground closed. Unfortunate users who referenced no-longer-existing entities created by a "player" would have to see some sort of error. That's one approach, and possibly a lot of work.

Another approach is to prevent only playground users from creating shared entities. That doesn't sound too hard, as there is a discrete number of places where they can do so.

But perhaps either way, it's just too much work.

[ericberman]

I could lock them down so that they can't create or edit shared entities, but it would cripple the experience. No creating models. No adding pictures. No editing incorrect aircraft data or incorrect model data. I suppose they could create aircraft (I handle orphaned aircraft periodically).

But again, it's a crazy amount of work to support a playground. A separate instance is really by far the easiest way to have a safe place to play.

[KayRJay]

A separate instance is fine, of course. I just thought you didn’t want to incur the cost of the third instance. Whatever you want is of course fine with me!

However the list of things “players” might not be able to is a small part of the overall functionality of the app.

No big deal ether way.

On Feb 8, 2020, at 2:11 PM, Eric Berman notifications@github.com wrote:

I could lock them down so that they can't create or edit shared entities, but it would cripple the experience. No creating models. No adding pictures. No editing incorrect aircraft data or incorrect model data. I suppose they could create aircraft (I handle orphaned aircraft periodically).

But again, it's a crazy amount of work to support a playground. A separate instance is really by far the easiest way to have a safe place to play.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/ericberman/MyFlightbookWeb/issues/488?email_source=notifications&email_token=AEBRDEE24BZNLMPOH3IIU6TRB4NWZA5CNFSM4KRXBCM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELF3YAI#issuecomment-583777281, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEBRDEB3YB457GXCV3IDWL3RB4NWZANCNFSM4KRXBCMQ.

[ericberman]

It may be a small part of the overall functionality however one measures big or small, but it's a huge deal to contain because it's spread throughout just about everything.

I can easily set up staging.myflightbook.com to point to my development server. The main piece is that images are not branded, which is a separate issue I need to do anyhow. "Branded" meaning that images need to go into a distinct AWS bucket from the "MyFlightbook" brand in order to keep things separate. That's useful functionality to add anyhow, I can get that coded in a day or two.

[ericberman]

https://staging.myflightbook.com/logbook should work for this now. This is an alias for my development server, but it is its own "brand", so there are a few quirks (all quite deliberate!) to be aware of:

• I refresh the database and images from the live site every few days.
• Images that are already there are thumbnail-only. If you click them, they will not resolve, because they are referencing live-site images. Images that you add, however, will work. Thanks to the check-ins above, if you delete an existing image it shouldn't affect the live site.
• I currently have this set up so that videos don't automatically get added. Videos get uploaded for transcoding to AWS. On the live site, when AWS is finished transcoding, it calls the live site and passes the information about the completed video so that the site can process the video. On staging, it sends me an email and nothing else happens unless/until I manually process that email. I pay for video storage and transcoding, please don't abuse it.
• "staging" is also a distinct brand (an old feature), so it has a different name ("MFBStaging" instead of "MyFlightbook"), different stylesheet for a decidedly different look/feel (so that you know you're not on the main site), and a few other things appropriate for a different brand (no link to videos, facebook, or twitter, since those are tied to the MyFlightbook brand).

But otherwise, safe to play around.

note: I make ZERO warranties about up-time on this site. If it goes down, so be it. I will not entertain complaints about the state of the site, nor about bugs, quirks, idiosyncracies, lost data, etc. Level of support is NONE, ZILCH, NADA. I will freely destroy data. This server is in my home, so if the power goes out, or Comcast has its usual level of service, it may be unreachable. So feel free to play, but all at your own risk.

[ericberman]

Oh, and I may periodically even point "staging" to a new candidate host for the live site. See above under warranties.