pvh

Databases should add support for lenses and also support type conversations, column relocations, new default values, and everything else a user might need.

Close! In math lingo, you can only have a bijective function for domains with equal cardinality.

In other words, you couldn't have a bijective function between an integer and a boolean, because there are fewer possible boolean values than integer values.

Demanding bijective functions is probably more restrictive than you want to be for building real-world systems. We discuss this a bit in the paper -- I think look for "convert".

YAML is a convenient stand-in for a better syntax and was chosen for being less tedious to type than JSON itself, while still supporting JSON Schema to make our editor integration work.

Long run, I expect neither JSON nor YAML are really the best solutions.

Muse is our first commercial spin-out from the lab, a spatial canvas to collect your thoughts: https://museapp.com/

For those interested, the code for the library behind the project is available at https://github.com/inkandswitch/cambria

I'm not an expert on Haskell, but as I understand it, Haskell lenses are a distinct and independent derivation of the same research work by Pierce et al at UPenn: https://www.cis.upenn.edu/~bcpierce/papers/index.shtml#Lense...

I love the analogy, but no! First, XSLT is unidirectional and although I have built some tree-like XSLT processing systems, Cambria is explicitly graph-based and bidirectional.

In other words, with Cambria you can build a graph of lenses that describe various data schemas and then translate from or to any of them.

That said, XSLT has different strengths (syntax-aside) in that it is a general purpose templating language with strong functional programming underpinnings.

Hello, we've published some more work in this space -- no HTML version yet, but here's a more recent paper on our PushPin project.

https://martin.kleppmann.com/papers/pushpin-papoc20.pdf

You can also try PushPin for yourself: https://github.com/automerge/pushpin/

likely outdated binaries are available here: https://automerge.github.io/pushpin/

Also, we're currently in the midst of a new project called Cambria, exploring some of the consequences and data demands for a new Cambrian-era of software here: https://inkandswitch.github.io/cambria/

Counterargument: China

Just for kicks, I tried using internet explorer for a few weeks a while back. It seemed like every Google property was constantly prompting me to switch to Chrome. I mention this not to defend Microsoft, whose behavior here it intolerable, but to point out that this kind of thing is unfortunately common.

The new terminal is pretty good, but what's more impressive to me about this is how bad it is.

It's so clearly incomplete that opening the preferences launched a JSON editor window in Visual Studio (not VSCode).

The level of openness it takes to open such a central utility built by what would historically be a low-profile team is quite remarkable, and I am convinced will result in an excellent product ... in time.

For now? It's almost good enough to be my daily driver but not quite.

Good luck to the development team! I'll be watching.

The character who speaks that line (Polonius) says so in the midst of a rambling and contradictory monologue, though we can certainly give Shakespeare credit for coining it.

Worth noting that Electron and native apps both only need to run at the frame rate of your monitor, and do the actual work within your users' expected response times.

The quality of your applications is primarily determined by what you care about, not by what tools you build them with.

I'm told OT gets very complicated, and I hoped a good CRDT would be general-purpose enough to cover a variety of applications and domains. Also, I like not needing a central server to coordinate action. Would love to compare notes -- feel free to reach out to me on twitter at the same nick.

In fact, one of the purposes of this project was to test exactly what it was like to use a Trello-like tool implemented this way.

What happens is that humans have intuitive coordination systems and tend to fix the same problems.

In other words, if the card title is "rename auotmerge" then both of us are likely to change it the same way, or at least either resolution is fine. In the event of a conflict we flag the multi-value in the UI so that a human user can decide if they care.

Where this approach shines is in domains where it helps avoid conflicts rather than resolving them. Naively adding replies to a comment thread might result in collisions or misordered comments across nodes of a distributed team. Automerge captures enough metadata from the operations created by users that changes "tend" to merge well.

I realize this is an argument not from first principles but from experience. We weren't able to find examples of other people building web applications with quite this approach (though we would love to hear from them if they are out there) and so the question was "will this feel alright?"

Apparently it does.

If you find this result provocative, I would encourage you to challenge it by attempting to build something with automerge and letting us know how it goes. I believe it will work well in applications where all user operations can always commute to produce a subjectively reasonable result. To make that concrete, a bank account is a poor domain to model with a tool like this, but a shared drawing is much better.

Automerge uses vector clocks internally to track visibility and minimize conflict and retains all alternative values in the _conflicts list for that value.

Automerge must select one result to be the default consistently across all uncoordinated peers. If you don't do this, different nodes may see different documents during a conflict state, which is undesirable.

CRDTs generally benefit from "intent preservation" in their design. In automerge's case, this would mean that instead of storing a "set" value, you'd store either an "increment" value or a "set" value to support cases like the one you describe.

Automerge has fairly robust support for these kinds of use-cases around lists, which we use quite a lot, but we haven't actually needed them for numbers (though I expect we may want them eventually.)

Conflicts are surprisingly rare, and when they are detected they show up in the _conflicts list for resolution per your needs. What automerge guarantees is that unless you care about the conflict you don't need to take any action.

ShareDB looks quite interesting. We wanted similar capabilities but without a central authority, thus automerge was born.

Ink and Switch | P2P Research (Electron, React/Redux, IPFS/Dat, CRDTs) | Freelance Contract (6wks) | Remote (working with PST)

Ink & Switch is an industrial research lab focused on improving creative productivity through better tools. Our past work has included exploring improvements to tools for data journalists, note-taking software designed for minimal engagement, distributed whiteboards, cryptographic identity protocols, and zero-infrastructure web applications.

Our next project is an experiment with a P2P Electron application.

Feel free to email me at pvh@inkandswitch.com and/or apply via this Workable link (https://inkandswitch.workable.com/j/0DE157996E) which includes a lot more detail.

Postgres doesn't have anything built in today, though a single node will comfortably scale to ... let's say somewhere between 100GB and 10TB depending on your use-case. Beyond that you can do read scaling with replicas, implement something with Foreign Data Wrappers, or hand-roll a sharding solution and stay on vanilla.

Alternatives to the DIY approach include open-source things like Postgres-BDR, CitusData, TimeScaleDB or closed-source single-vendor things Amazon Aurora, and RedShift.

I see in the FAQ that Tapoueh promises to refund anyone who isn't satisfied for any reason.

Oh, hey, these are my slides. Let me know if you have questions and I'll do my best to help out.

This is why Facebook recently added a variety of new ways to illustrate your disappointment on posts.

Hi there - can you email me at pvh (at) heroku with a link to the ticket where you had a bad experience? This sounds like a bad UX bug that we need to fix, and I will make sure any unintended charges are taken care of.

I've also asked the PM for this project to look into what happened here and alerted the head of our support team. I hope you'll consider giving us a chance to make this right for you and a chance to re-earn your trust.

Our research suggests that almost all low traffic apps should continue to run fine on the `free` dynos. If yours don't, send me an email: pvh at heroku

We looked at the numbers and it's actually a very, very small percentage of applications that run between 18 and 24 hrs per day.

Eighteen hours a day is enough to keep your app running from 9AM to 3AM every day, and unless your application has a global reach, it should naturally equilibrate into a comfortable place.

We are asking that if you want 24x7 wake-time that you pay for a hobby dyno, but if you can let your application sleep when you do, you won't see any difference at all.

A better static files offering is definitely something we've been asked for a few times. Near-term, if you put a CDN in front of a static app your dyno will wake up on release, fill the cache, and go to sleep. You shouldn't see much, if any difference for your apps at all.

Hobby dynos are real dynos. :) Professional dynos, like the new `standard-1x` will have scale-out, Heroku Metrics, preboot, and mix with other dyno types: all features we have found are most useful for apps at scale.

We hope that between the new `free` and `hobby` dynos you should have good choices that support almost any personal or small scale professional app you might want to build.

You could call it a side-grade. We're also allowing users to add a worker dyno and use up to 18hrs/day of `heroku run` and scheduler one-off dynos as well. All told you can get quite a few more compute-hours for free applications now than before.