I, too, would like to know the answer to this. If this solution scales, I have a wonderful idea for a service that can store arbitrary data using 8 boolean values per byte.
Imagine all the power that this booleans service has brought to the boolean data type being available for arbitrary data types as well!
Using an additional byte for the size of the address and the specified number of bytes for the address itself. Then you will only need a few identifiers stored locally to access all the bits.
What are your gross margins? What is the monthly churn rate for active users (active to inactive)? How much revenue (in USD) have you have booked each month for the last 6 months?
Uhoh, that means somebody is MITM-ing you. They've observed your qubits in transit and broken quantum entanglement. Now the BaaS server can't store them.
Ironically, the idea is more useful than intended. One could, for example, store on/off user's preferences in the cloud without the hassle of local storage, survey responses, or even control IoT devices remotely with just the switch of a boolean.
Would also be a cool way to arrange clandestine meetings (similar to the x in the window, only with as many windows as there are atoms in the universe)
And where would you suggest backing up the UUID for that bool?
It only makes sense to back bools up this way if len(n) > backup key.
If you could backup 129 bools it would make sense because you'd only have to remember the key, 128 bit, to access the backup. If there are equal or less, just remember the bools directly.
Good practice would recommend adding /v1/ to your API url. The state of the boolean ecosystem is moving so fast that we have no idea what booleans will look like in 5 years!
I would like to see the API extended to support DELETE requests, and 404 not found when not existing. Additionally, I've been led to believe that some truths are truer than others, hence some method of ranking this truthiness is a must.
> Good practice would recommend adding /v1/ to your API url. The state of the boolean ecosystem is moving so fast that we have no idea what booleans will look like in 5 years!
Not necessarily. He should be using the HTTP Accepts header to negotiate content type including version. Using the version in the URL is considered an anti-pattern by a good many API evangelists.
I'm concerned about the lack of authentication on this API.
What's to prevent an attacker from modifying my booleans? just his ability to guess the guid?
131 comments
[ 4.9 ms ] story [ 211 ms ] threadImagine all the power that this booleans service has brought to the boolean data type being available for arbitrary data types as well!
Probably someone changed?
https://en.wikipedia.org/wiki/Rule_of_three_(writing)
The left-pad debacle was ages ago in Internet time. Comedy is partially rule of three, part timing.
I am clearly hoping for DRAM and BaaS
Let's Encrypt, everyone!
A boolean might indicate if it's snowing in NY, for example (Read-Only for most people)
Now seriously how is this any good since you can only save one bit. MongoDB as a service is probably what you're looking for...
It only makes sense to back bools up this way if len(n) > backup key.
If you could backup 129 bools it would make sense because you'd only have to remember the key, 128 bit, to access the backup. If there are equal or less, just remember the bools directly.
This is useless for anything serious.
Nah; need to move fast and break things.
<value>True</value> should be acceptable