jodersky
Joined 7 years ago
Karma
66
Submissions
25
Member since
Nov 8
Recent submissions
Comment · 1 day ago
I am in the same situation. However, I have found that there's a workaround/hack to make Android 'think' it has IPv6 connectivity. Instead of routing ::/0 through your VPN, simply add these two routes to your devices:
- 2001:4860:4860::/112 (for chrome)
- 2000::/128 (for the system)
The drawback is that this breaks happy eyeballs, and you may notice slower response times on requests (since now your phone will start by quering AAAA results first which always fail for sites not on your VPN, and then fall back to the A result). In practice however I haven't really noticed any difference.
Comment · 1 month ago
Another thing that becomes easier with change IDs is reviewing multiple related commits together, essentially "stacked pull requests".
If you treat a branch as your unit of review, then it becomes super difficult for someone to submit a chain of related changes. You'll be constantly rebasing your pull requests onto each other as you get feedback from dependent branches.
I heard that the github CLI recently introduced support for this, but since in git there's no concept of dependent branches (a branch isn't even an object in git, just a reference to a commit), I think this approach will always be clunkier than reviewing commits related by a change ID.
Comment · 1 month ago
It's unfortunate that change IDs aren't considered. There was a discussion [1]
in 2025, and it has resurfaced a couple of times since.
Basically, the idea is to attribute a new kind of ID to an initial 'change'. During review, or whenever a commit is rebased, the change ID is kept, whereas the commit of course changes. This allows tooling to identify all previous versions of a change, and is what enables "per-commit" code review à la Gerrit [2] (which IMO is a much better experience than the branch-review-squash model that GitHub normalized). It's also used in jj, although I'm not familiar with that.
As of today, any tool that wants a change ID needs to somehow encode it in commit message bodies. The proposed discussion was about making a change ID a standard header field that git would natively keep across rebases.
[1] https://lore.kernel.org/git/[email protected]/T/#mf941...
[2] https://gerrit-review.googlesource.com/Documentation/user-ch...
Comment · 2 months ago
> I. Codebase (https://12factor.net/codebase)
> Multiple apps sharing the same code is a violation of twelve-factor.
I never understood why the 12 factor app is against monorepos. It seems completely orthogonal to the contract between an application and its execution platform, which if I understand correctly, is the main point of 12 factor.
Comment · 11 months ago
I'm curious what the google cli is that you're referring to. Could it be kubecfg (https://github.com/kubecfg/kubecfg)?
I've used it in the past (for a quite small deployment I must say), but have been very happy with it. Specifically the diff mode is very powerful to see what changes you'll apply compared to what's currently deployed.
Comment · 1 year ago
This might be a bit of a shameless plug, but because you ask :)
Regarding no sbt, I would highly recommend to have a look at the mill build tool https://mill-build.org. I personally find it very pleasant to use as a replacement for sbt, mostly because of the following points:
- it uses regular Scala code to define a build
- it isn't DSL-heavy like sbt, which means it's A) easy to debug by simple searching, and B) anyone unfamiliar can get a vague idea of what's going on at a first glance
- it is designed around a generic task graph and isn't centered around the JVM world (disclaimer: I'm helping with development, and recently first-class support for Python and JavaScript projects was added)
Comment · 1 year ago
The article mentions they used an experimental language feature, which is enabled via a special compilation flag and came with a big warning from the start that it was in fact experimental and could be removed any time. I highly doubt that most people use any libraries that use those.
As a side note, I've personally had the experience of migrating several projects to Scala3 (when it was still called Dotty), and never had any issues with 3rd party dependencies, since Scala 3 is binary-backwards compatible with Scala 2.13
Comment · 2 years ago
AFAIK, it's not strictly true that unicast addresses are required to use a /64 network identifier.
It's common, almost necessary even, for environments with dynamic clients to use /64 subnets (precisely so that SLAAC works), but in a static environment it's perfectly fine to use prefixes larger than /64 (e.g. delegate a /80 to each individual host in a datacenter, for virtualization applications etc).
Hence, I'm wondering what the spec is you mention that is broken?
Comment · 2 years ago
One data point that really highlights this is that it is used in the flight software in Airbus planes. This alone is a very strong indicator that it is extremely robust, and also that it will be around for a very long time. There's a whole list of additional industry use-cases [1] that support this claim even more.
Comment · 2 years ago
Location: Lausanne, Switzerland
Remote: yes
Willing to relocate: no
Technologies: compilers, distributed systems, developer tooling and devops. 15 years of experience in Scala, deep knowledge of the JVM. Also multi-year experience with Python, C, C++ and open to any other language.
Résumé/CV: https://www.crashbox.io/cv.pdf
Email: in the resumeComment · 3 years ago
> I think the biggest thing is that the minimum extra spend if you want in house managed infra is basically the salary of a full time sysadmin + hardware costs.
The cloud promises to make admin tasks easier, however I have never seen it eliminate the role of a sysadmin in practice. In my experience, most organizations that run their infra on a cloud still have dedicated admin roles (often called "DevOps" or infra teams).
Hence, I think that the claim that a sysadmin's salary is an extra expense for self-managed infrastructure is exaggerated. You may need more sysadmins for achieving the same features in a self-managed setup compared to the cloud, but it is not a linear scale.
Comment · 4 years ago
I recommend to have a look at Mill. It's versatile, built on simple foundations, and implements many concepts from general-purpose build tools such as Bazel (but of course it was designed for Scala). It's easy to call it from various scripts too, and doesn't require you to design your project around your build tool.
At work we've used mill to first replace sbt and then also gradle in another project, and haven't looked back. It worked out-of-the-box for our JVM projects, and we trivially wrote custom "rules" for integrating cmake-based C++ projects into the build.
https://jakob.odersky.com/about
[first name]@[last name].com