At present we are using a UUID in our Append-only Log see: dwyl/alog#15
This is a good "stop gap" to get the alog project to "alpha" so it could be used in the Client Project. 
But I feel that we should carefully consider the use of UUIDs as IDs in the "long term".
If an ID is meant to be "machine readable" and "guaranteed" unique, then UUIDs are perfect.
If there are additional requirements then we need to capture them.
For example: are we going to display the UUID in the URL for a given content type e.g:
location-app.com/venues/123e4567-e89b-12d3-a456-426655440000
Is this the most user-friendly ID we could display? (is it distinctive or memorable ...?)
Could we instantly improve UX by shortening the URL and making it Base64 instead of Base16? e.g:
Where the app would automatically 301 re-direct the request to:
location-app.com/venues/the-islington-roof-garden-sw1x
Can we "re-think" content/record IDs for both Uniqueness and Usability?
Basic Example: Address Book
The append-only log example: https://github.com/dwyl/phoenix-ecto-append-only-log-example
demonstrated the benefits of using an append-only log for an address book.
But we also explained that any app can benefit from having an immutable log as its' data store!
see: https://github.com/dwyl/phoenix-ecto-append-only-log-example#examples-where-an-append-only-log-is-useful
What the example did not cover is how to mitigate against saving the same data multiple times.
For example, consider the form:
| Field |
Value |
| Name |
Bruce Wane |
| Address |
1007 Mountain Drive, Gotham |
if Bruce clicks/taps to edit his address,
and we have an auto-save function to prevent loss of changes.
We need a way of checking on the client that the address has not changed
while he is viewing the edit screen.
Yes, this function should only be triggered by the "onChange" DOM event, but for argument's sake, we assume that Bruce clicks the "save" button (which we have discovered through UX-testing people still expect to have despite the "autosave"),
should the server attempt to "re-save" the data that has not changed?
I suggest that by using a hash of the content as the Primary Key, Ecto (or PostgreSQL) would "reject" the insert request as a "duplicate" and we would not waste space in the database/table with dupe data.
If the data has not changed then the ContentID (cid) would be the same so no data insert.
Use Case: Distributed Learning Platform
Learning systems universally have "vendor" or "platform" Lock-in.
Do a lesson on
Ask a question on StackOverflow? If your account gets banned for any reason, you lose "ownership" of any questions you had asked.
Want to export your data and take it with you? Tough!
In our "product roadmap" we have begun to detail the creation of an Open Source Distributed Collaborative Learning platform:
https://github.com/dwyl/product-roadmap/blob/master/collaborative-learning-community.md
By using a cid where each item of learning has a unique "fingerprint",
_everyone learning on the platform can clearly see what each of their fellow learners has "covered".
If anyone wants to either import or export their learning, they can do it easily.
This is game-changing for making your "learning log" portable from kindergarten to the grave!
No longer will your new school, university or employer/team have to rely on a "report card" or (incomplete) "transcript", everyone will be able to see that Alex
- "learned quadratic equations on 2017-01-14 10:09 at Hyde Park Middle School."
cid: sha2-256-6e6ff7950a36187a801613426e858dce686cd7d7e3c0fc42ee0330072d245c95
When Alex moves from Middle School to High School, all his teachers and classmates can easily see exactly what he has learned.
The teacher can be far more effective because they know what each student has already covered vs. what they still don't grasp. And instead of teaching more advanced topics that half the class will be confused by, they can attempt to cover the areas that still require work.
This is highly relevant in the workplace too!
As a "hiring manager" or "team lead", I want to know exactly what my (potential) team members already know and what they are still trying to learn. I will delegate tasks to them that stretch their current abilities enough to encourage learning but not too much that would "overwhelm" them!
Closing the Gender/Class/Minority Divide in STEM/Tech
I feel that having a complete "learning log" will help to eliminate the gulf that exists in STEM/Tech because it will always be immediately obvious who has the knowledge/skill and it wont be a matter of which person has the loudest voice and most over-confidence.
At present we are using a UUID in our Append-only Log see: dwyl/alog#15
This is a good "stop gap" to get the
alogproject to "alpha" so it could be used in the Client Project.But I feel that we should carefully consider the use of UUIDs as IDs in the "long term".
If an ID is meant to be "machine readable" and "guaranteed" unique, then UUIDs are perfect.
If there are additional requirements then we need to capture them.
For example: are we going to display the UUID in the URL for a given content type e.g:
Is this the most user-friendly ID we could display? (is it distinctive or memorable ...?)
Could we instantly improve UX by shortening the URL and making it Base64 instead of Base16? e.g:
Where the app would automatically
301re-direct the request to:Can we "re-think" content/record IDs for both Uniqueness and Usability?
Basic Example: Address Book
The append-only log example: https://github.com/dwyl/phoenix-ecto-append-only-log-example
demonstrated the benefits of using an append-only log for an address book.
But we also explained that any app can benefit from having an immutable log as its' data store!
see: https://github.com/dwyl/phoenix-ecto-append-only-log-example#examples-where-an-append-only-log-is-useful
What the example did not cover is how to mitigate against saving the same data multiple times.
For example, consider the form:
if Bruce clicks/taps to
edithis address,and we have an auto-save function to prevent loss of changes.
We need a way of checking on the client that the address has not changed
whilehe is viewing the edit screen.Yes, this function should only be triggered by the "onChange" DOM event, but for argument's sake, we assume that Bruce clicks the "save" button (which we have discovered through UX-testing people still expect to have despite the "autosave"),
should the server attempt to "re-save" the data that has not changed?
I suggest that by using a hash of the content as the Primary Key, Ecto (or PostgreSQL) would "reject" the insert request as a "duplicate" and we would not waste space in the database/table with dupe data.
If the data has not changed then the ContentID (
cid) would be the same so no data insert.Use Case: Distributed Learning Platform
Learning systems universally have "vendor" or "platform" Lock-in.
Do a lesson on
Ask a question on StackOverflow? If your account gets banned for any reason, you lose "ownership" of any questions you had asked.
Want to export your data and take it with you? Tough!
In our "product roadmap" we have begun to detail the creation of an Open Source Distributed Collaborative Learning platform:
https://github.com/dwyl/product-roadmap/blob/master/collaborative-learning-community.md
By using a
cidwhere each item of learning has a unique "fingerprint",_everyone learning on the platform can clearly see what each of their fellow learners has "covered".
If anyone wants to either import or export their learning, they can do it easily.
This is game-changing for making your "learning log" portable from kindergarten to the grave!
No longer will your new school, university or employer/team have to rely on a "report card" or (incomplete) "transcript", everyone will be able to see that Alex
cid: sha2-256-6e6ff7950a36187a801613426e858dce686cd7d7e3c0fc42ee0330072d245c95
When Alex moves from Middle School to High School, all his teachers and classmates can easily see exactly what he has learned.
The teacher can be far more effective because they know what each student has already covered vs. what they still don't grasp. And instead of teaching more advanced topics that half the class will be confused by, they can attempt to cover the areas that still require work.
This is highly relevant in the workplace too!
As a "hiring manager" or "team lead", I want to know exactly what my (potential) team members already know and what they are still trying to learn. I will delegate tasks to them that stretch their current abilities enough to encourage learning but not too much that would "overwhelm" them!
Closing the Gender/Class/Minority Divide in STEM/Tech
I feel that having a complete "learning log" will help to eliminate the gulf that exists in STEM/Tech because it will always be immediately obvious who has the knowledge/skill and it wont be a matter of which person has the loudest voice and most over-confidence.