jodersky

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.

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/Z_OGMb-1oV0Ex05e@pks.im/T/#mf941...

[2] https://gerrit-review.googlesource.com/Documentation/user-ch...

> 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.

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.

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)

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

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?

[1] https://www.sqlite.org/famous.html

    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 resume

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.

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.

Unfortunately, all libraries that abstract concurrency on an application-level break the ability to get meaningful stack traces. At least all the ones I know of, including ZIO, Akka, Monix, plain Futures, etc. I know that there is tooling to counteract that (such as the abstractions used in distributed tracing), but that's again on the language level.

In my experience, for all but the most advanced applications, the debuggability advantages of using linear code outweigh the performance advantages gained by abstracting over execution contexts. Thus, I would posit that concurrency is best dealt with on the platform, not the language level, especially when starting a project.

Of course there are some situations where a library can make some concurrency task appear trivial, but as long as there is no good tooling, the time saved using beautiful abstractions tends to be paid back 5-fold when those abstraction break (which they often do as an application grows).

Consider the following code where you would like to multiply a number by two, but this number is potentially undefined:

    var x = ... // a number or null
    if (x == null) return null
    else return x * 2

    var xs = ... // a list of zero or one numbers
    return xs.map(x => x * 2)

Thus, in order to understand 80% of their utility in 20% time, I can recommend that you think of a monad as a wrapper around a value which allows you to treat special cases uniformly. In this case, a list of one or zero items. Of course there is more to it, but I this is usually enough to get people to stop worrying and interested in exploring more.

Another nice feature is what I would call its architecture: it does not try to be a service manager (instead, you are supposed to spawn it from your own favorite service manager, be that systemd, docker, or anything else, and you can hence really lock it down), hence it does not require root to run and does not rely on using system accounts by default.

I've only used it for very basic setups, but for those I can highly recommend it.

AFAIU, the recommendation from OAuth 2.1 is to drop the use of implicit flows in web apps and instead rely on code flows with PKCE. The idea would be that the web app registers itself as a so-called "public client" (see https://oauth.net/2/client-types/) when it is loaded and then uses the standard code flow with PKCE.

Essentially, the idea behind it is that the client (the web app in this case) dynamically registers itself with a secret at the authentication server. After receiving the code, it uses a hash derived from the secret to authenticate itself. An attacker who intercepts the authorization code, would not be able to exchange it for a token, since they don't have the secret. Section 1.1 of the RFC (https://datatracker.ietf.org/doc/html/rfc7636#section-1.1) has a very concise and clear explanation.

It's not something I would recommend as a substitute for wifi, but definitely worth it if you travel to multiple countries, and don't want to deal with getting and/or swapping sims at every destination.