Our great sponsors
-
-
openvscode-server
Run upstream VS Code on a remote machine with access through a modern web browser from any device, anywhere.
There's at least one good commercial solution that basically does the same thing the blog describes [1]. Working well for us so far.
-
Sonar
Write Clean Java Code. Always.. Sonar helps you commit clean code every time. With over 600 unique rules to find Java bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work.
-
using remote resources as a part of your local dev flow can be very useful if your local environment is constrained on:
- upload and/or download bandwidth
- cpu/ram/gpu/ssd
this can be as simple as an ephemeral ec2 spot machine that reacts every time files on it’s filesystem change. it then does stuff, like building and shipping.
your local setup then needs to rsync files from local to remote every time you save a file.
i’m on an upload constrained setup right now, and this[1] significantly speeds up my iterations uploading lambda zips.
fancier setups probably are similarly advantageous, but add tradeoffs proportional to their complexity.
1. https://github.com/nathants/aws-gocljs/blob/258ea5bb72d06a50...
-
>Can you explain how a monorepo for microservices is a tooling nightmare and bandwidth sink?
bandwidth:
I meant "bandwidth" as literal bandwidth. When your codebase becomes huge, your VCS repo size becomes enormous and it becomes harder and harder to keep a full checkout on all the development machines, especially if they are over the WAN (e.g. at home on your laptop).
This has fuelled solutions like sparse checkouts (like MS vfs for git, now scalar) remote development (like TFA; but also Google's cider and srcfs etc).
tooling:
naïve monorepo tooling (which I've seen in various companies I worked for) simply perform a full build of the whole monorepo for each CI execution. At first this is just fine since you can parallelize builds and call it a day; but after a while, the builds just don't scale anymore ; flaky tests become an increasing frustration etc.
The tooling that can help scale large monorepos does exist, but requires buy in and comes with its own learning curve and tradeoffs. One well known such tool is bazel (https://bazel.build) and bazel remote builds and remote caches. These tools are hard to set up, although folks at https://www.buildbuddy.io/ can help smaller startups by offering a managed service.
(Again, I'm talking about really large monorepos. A monorepo which includes a dozen or so modules, for which you can easily perform a full re-build on a single CI worker and on your laptop is not the kind of repo that creates tooling nightmares.)
-
Docker-OSX
Run macOS VM in a Docker! Run near native OSX-KVM in Docker! X11 Forwarding! CI/CD for OS X Security Research! Docker mac Containers.
Anyone from Uber here that works on this? You ever expect a DevPod for iOS developers? I've been toying with idea of doing this in work for our devs on Intel MacBooks, using -> https://github.com/sickcodes/Docker-OSX, which enables local running on iOS devices.
I think it's hampered by licensing though, maybe that's why it's not used or mentioned in this post.
-
InfluxDB
Access the most powerful time series database as a service. Ingest, store, & analyze all types of time series data in a fully-managed, purpose-built database. Keep data forever with low-cost storage and superior data compression.
