The author likely meant .dockerignore everything, that is the way to go.
45 karma · joined March 28, 2014
25 years of helping businesses from 0 to 1. Now building my own product to do it all over again, solo.
Excellent developer experience leads to excellent customer experience.
The author likely meant .dockerignore everything, that is the way to go.
1) Horizontal scaling via workers 2) Flow tasks as executable plugins written in any language
Horizontal scaling via workers The `orchestrator` binary either runs fully standalone (with the UI, scheduler, executor, etc) or as a worker that connects to a binary that runs in server mode. The latter allows horizontal scaling by simply starting the binary in worker mode on any machine.
Flow tasks as executable plugins written in any language There's a http plugin I provide by default (others to come depending on demand). Any other task type is a separate plugin executable that provides a manifest that declares the UI elements and plugin execution code. The server (or workers) communicate with plugins over a small newline-delimited JSON protocol on stdin/stdout. Not as fast as in-process, but extensible without any code modifications in Orchestrator.
I also added a `/` command in a todo's input field to add metadata more visually. There's also a new `:` command palette.
I'm in month 4 of development, working on it full-time.
Months 1-3 were about building a desktop client. Now I'm working on a server binary customers can optionally self-host to share dashboards publicly and run workflow automations.
However, your comment hit me... :-) I'm going to record a video!
It's a project I'm working on to build a database management product I've always wanted.
I spend way too much time obsessing over UX but hope people appreciate it :).
It has a visual query builder and separate SQL tutorial.
Does Flox have an optional cloud solution as well? Can Flox install specific versions of Nix packages? What about OS-specific dependencies?
I've worked with tools like that for 5 years. Curious to understand what Flox brings to the table that we don't already have.
Local dev, cloud dev, CI, production – all with the same config file. Fingers crossed my talk submission for PackagingCon gets accepted. It'd be awesome to share this new way of working with a wider audience.
Best to follow me on Twitter or Bluesky though for up-to-date full-stack web development opinions.
We need to support local dev environments first, with the exact same config a developer can then move to the cloud.
See https://github.com/jetpack-io/devbox for how this can be achieved and https://www.mikenikles.com/blog/dev-environments-in-the-clou... for my thoughts after 3 years of working in this space.
We documented this in more detail in the "Source Code Organization" chapter at https://github.com/gitpod-io/openvscode-server/blob/main/doc....
As to where to submit PRs:
- Anything to do with running VS Code in a server context: gitpod-io/openvscode-server
- Anything else related to VS Code: microsoft/vscode
We have no intention of changing VS Code in any way or to add additional features to VS Code itself.
I noticed the same with the Brave browser a few months ago, but when we dropped Google Analytics it worked with Brave.
Diving deeper into what uBlock Origin does...
Thanks!
I'm going to completely remove all Javascript on pages that don't need it, which is most of them.
Investigation continues...
It was 3 months part-time. Evenings and weekends almost exclusively though.
As for marketing, I am planning to write a blog post and/or video series where I explain my journey, what I learned, the tools I used, share scripts I wrote to make my life easier.
It's been a fantastic learning experience and I hope my story will encourage others.