We run the entire stack (browser, frontend, backend, database, etc) in a Linux VM, so latency between each of the pieces is as tiny as can be. This is quite different from "standard" E2E tests I've seen where the test browsers uses something like a persistent staging environment.
The real key is that we can fork that entire Linux VM to take different paths down our testing scenarios, and can run multiple of them in parallel. Tests may look something like:
new user signs up:
|- creates a todo
|- ...
|- ...
|- creates a list
The two nested tests then start from the exact same point, where the previous test left off, but can run in parallel. With enough hardware, the full suite will run as fast as the slowest branch of the test tree. When we switched away from our previous integration test suite to this (not E2E), our tests actually became faster because they share setup through the forking.
Sure. It's a bit hard to quantify because we need to run these on bare-metal machines and the unit cost is pretty high.
We run our test workload as well as a few other startups' that we have onboarded on one AWS ARM bare-metal machine at $1.7k a month. We don't saturate that machine fully either so I'm not really sure what the amortized cost would be. Certainly more expensive than Github Actions but not by a crazy amount, and the value we get out of it is way higher than GA.
Please note: working proficiency in Dutch is strictly required for these roles, and we kindly ask for no automated applications. The rest of this post will continue in Dutch.
Wij zijn een non-profit die zich inzet om lesmateriaal voor scholen beter, betaalbaarder en flexibeler te maken, in zowel digitale als gedrukte vorm.
Werktijden en kantoordagen zijn flexibel en worden in overleg bepaald op basis van de rol. Wij bieden een competitief salaris.
Technologiestack: Git monorepo, TypeScript, Yjs en React, een beetje Python, OpenTofu/Terraform, Scaleway, managed PostgreSQL en managed Kubernetes.
Openstaande rollen:
- Senior/Lead Platform & DevOps Engineer
- Senior Backend Engineer/Architect
- Senior Frontend Engineer
- Senior Full-Stack Engineer
E-mail jobs[at]openeducation.foundation met (HN) + de functienaam in het onderwerp, samen met een korte introductie en een link naar je LinkedIn-profiel en/of GitHub. Als er van beide kanten een goede match lijkt te zijn, plan ik graag een kennismakingsgesprek in.
Was trying to find it but hard. Reticulum only needs some kind of way for bytes to move from one point to another. So USB with the serial data line works as well.
On the video was using for an embedded device without WiFi nor Bluetooth to communicate with the host computer where it was connected.
We are a non-profit working to make teaching materials for schools better, more affordable, and more flexible, in both digital and print formats.
Working hours and office cadence are flexible and agreed based on the role. Dutch proficiency is required. We offer highly competitive compensation.
Technology stack: Git monorepo, TypeScript, Yjs and React, some Python, OpenTofu/Terraform, Scaleway, managed PostgreSQL, and managed Kubernetes.
Open roles:
- Senior/Lead Platform & DevOps Engineer
- Senior Backend Engineer/Architect
- Senior Frontend Engineer
- Senior Full-Stack Engineer
E-mail jobs[at]openeducation.foundation met (HN) + de functienaam in het onderwerp, samen met een korte introductie en een link naar je LinkedIn-profiel en/of GitHub. Als er van beide kanten een goede match lijkt te zijn, plan ik graag een kennismakingsgesprek in.
It currently works on the 2b, 3b and Zero 2; the latter was my actual target because it is a very nice and still lean board available for ~15$ worldwide at least until 2030, and meets very well with the Oberon philosophy. With models like the 4 or 5 series, the Pi goes more and more away from its original leanness. So, currently I'm trying to migrate the system to the ESP32-P4 platform, which seem like the perfect fit for Oberon system, specifically the Olimex board with a HDMI socket.
ESP32 is a great SOC. Watch out for RAM issues though. I have an e-reader using an ESP32 that only has 180kb or so of usable RAM which makes things very difficult to work with. You will need to specify that it has to be the versions that have addressable RAM. Unless of course, all updates are entirely firmware and the limited memory is just to hold the text editor buffer.
That is a known limitation as of now. Text updates are currently handled as whole chunks, so Epiq does not implement character-level CRDT merging.
In the event of conflicting updates to the same text block (currently title or description fields), later events take precedence.
What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previous states and manually recover overwritten changes if needed.
> What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previous states and manually recover overwritten changes if needed.
Thanks, I think that would work fine in most cases if you can open your editor with the 'prev' version and the current version in 2 panes (or in diff mode).
Thanks. There is actually also an i386 version of the system in the repository, where I modified the kernel so it runs with Multiboot, making installations much easier. An essential achievement for both platforms were the stand-alone tools, i.e. I can compile and link the whole Oberon system on Linux or any other platform (see https://github.com/rochus-keller/op2/). I even implemented an IDE which I used for the development (see https://github.com/rochus-keller/activeoberon/).
Technically yes, but since Apple locked down their OS completely, you might have to compile the tools yourself on your machine so the OS allows them to start at all.
reply