- workflow
$ heroku pg:psql -a isis-db
\d
\d+
The PHP language owner is responsible for the success of Heroku developers building in PHP. They are part of the broader “languages team”, a group of developers with similar language-specific responsibilities and shared infrastructure.
A language owner will be responsible for varying degrees of
The Node.JS language team is responsible for the success of Heroku developers building in Node. They are part of the broader “languages team”, a group of developers with similar language-specific responsibilities and shared infrastructure. | |
A language team is responsible for the success of their language on the platform, including varying degrees of | |
* building core language-specific features such as the “build pack”, | |
* working within the community to improve projects upstream to provide a better experience for Heroku users, | |
* implementing support for and document Heroku product improvements for that language's community, | |
* supporting existing and prospective customers through outreach and support, | |
* language-specific documentation and content, and | |
* marketing responsibilities such as attending and speaking at conferences. |
I hereby claim:
To claim this, I am signing this object:
I hereby claim:
To claim this, I am signing this object:
Welcome, one and all to the Cambria project. Cambria is an ongoing research project here at Ink & Switch exploring how we can operate on evolving data formats in a decentralized system. We hope this work will be exciting not just for folks working on decentralized systems but could also be applicable more broadly to other distributed systems.
Cambria was motivated by some problems we kept seeing in our work. The most common problem was that someone would add an array field to a document. New documents would work fine (the array would be added at document creation time) but existing documents, or documents shared by older clients, would cause Javascript runtime errors when the code would try to call Array methods on the object.
This is a very common problem in all kinds of distributed systems, and in a centralised system is mostly managed by locking down how the system works. Database schemas prevent writing
Last week we showed you a demo of a problem. We wanted to run two different versions of a program, both operating on different data types... but with the same underlying document.
This is a tricky problem! The old code doesn't natively understand data written by the new system. The new system relies on data the old one doesn't provide. Worst, even in our little toy example there is one field where the data type changes completely, going from a Boolean type to a string.
So, if last week was a prototype of a problem then this week is a prototype of a solution.
<!DOCTYPE html> | |
<html> | |
<head> | |
<meta charset="utf-8" /> | |
<title>Automerge (Vanilla JS, Unbundled) Demo</title> | |
<meta name="viewport" content="width=device-width, initial-scale=1" /> | |
</head> | |
<body> | |
<script type="module"> | |
// The ?bundle-deps here is very dodgy... |
const putPatch = (obj: any, p: A.PutPatch) => { | |
const { path, value } = p | |
const tail = path.pop() | |
const local = path.reduce((acc, next) => acc[next], obj) | |
local[tail] = value | |
return obj | |
} | |
const splicePatch = (obj: any, p: A.SpliceTextPatch) => { |