culturedsystems

"It is very annoying when you need to add a dependency and suddenly you have to touch 50+ injection points because that thing is widely used"

You don't have to update the injection points, because the injection points don't know the concrete details of what's being injected. That's literally the whole point of dependency injection.

Edited to add: Say you have a class A, and this is a dependency of classes B, C, etc. Using dependency injection, classes B and C are passed instances of A, they don't construct it themselves. So if you add a dependency to A, you have to change the place that constructs A, of course, but you don't have to change B and C, because they have nothing to do with the construction of A.

"because it does preloading directly in javascript, it can't possibly follow the HTTP semantic of not actually applying cookies until later when the cached route is used"

I may be wrong, but I don't think using JavaScript vs using the standard HTML <link> element to prefetch makes a difference here. I don't see anything in the HTML specs about preload or prefetch delaying cookie setting to sometime after the resource is actually loaded (although admittedly I find this bit of the spec somewhat hard to read, as it's dense with references to other parts of the spec). I tried it out, and, both Firefox and Chrome set the cookies for preloaded and prefetched links when the resource is loaded, even if the resource is never actually used.

I initially interpreted "unaccounted-for null values may cause compile-time warnings, but not compile-time errors" as meaning "in some cases, an unaccounted-for null value might not cause a compile-time error", but in the context of the rest of the spec, I think it actually means "unaccounted-for null values are not permitted to cause compile-time errors, only warnings", which seems like a bad idea to me. I can see why allowing implicit conversion from unannotated "Object" to "Object!" is a reasonable compromise to work with existing code, but I don't see why conversion from "Object?" to "Object!" would not cause a compile-time error.

Worse, permitting this conversion at compile time means developers will ignore the warning, so we'll have actual codebases which include these conversions. Any later change to enforce nullability checking at compile time will then have a significant backwards compatibility cost.

"Soft deletion isn’t a blanket rule"

That's right, I think it's really "soft deletion as a blanket rule" which is the anti-pattern; soft-deletion is one option which (IMO) is used too often without thinking about specifically what you need to achieve. If soft-deletion is used as a blanket rule, you're more likely to want to try and abstract it away via an ORM or similar, which tends to be fragile (I agree views aren't fragile, but they do add another layer of complexity in defining the relationship between the application logic and the schema). If soft deletion is chosen judiciously and represented explicitly in the business logic, it's less likely to cause problems (the "archived state" in the post is kind of an explicitly represented soft delete).

I don't think there's an explicit reference in the JavaScript spec to numbers being treated this way, because this is how all variables are treated in JavaScript - the relevant part of the specification is probably the definition of the "PutValue" abstract operation[1], which doesn't include any special cases for numbers (or other primitive types) vs. objects.

[1] https://tc39.es/ecma262/multipage/ecmascript-data-types-and-...

Temporal tables, aka system versioned tables, are something like this: https://mariadb.com/kb/en/system-versioned-tables/

The language in the UK version of the law is "strictly necessary for the provision of an information society service requested by the subscriber or user", which the ICO interprets as meaning "it must be essential to fulfil their request". I don't think tracking page views counts, because it's technically possible to serve a page without using a cookie to track that it was viewed.

The paper linked to in the Criticism section of the article [1] is well with reading, IMO. It points out that AOP only works when there is "obliviousness of application", i.e the code to which the aspect is applied doesn't need to know about the aspect, and argues that this kind of obliviousness is pretty rare.

1: http://onward-conferences.org/2009/files/steimannessay.pdf

It's an API for a specific hypermedia client, i.e, a web browser. It's not obvious that it's the best hypermedia API for a different client, for example, a JavaScript application that happens to be running in a web browser.

"quicky discover I couldn't post on the timeline of the music or videogames one"

That's technically true, but who cares? The instance timeline isn't a "community", it's just a particular filter applied to the global timeline. The communities of videogame and music enthusiasts are larger than any one instance, and can follow one another across instances, and see each others' tagged posts in searches across instances.

Taylor Swift did do something a bit like this this for a previous tour - you could get early access to the ticket sales by doing various kinds of fan activities, including buying physical copies of her records, watching videos, and posting on social media [1]. People were kind of mad about it, although I think in part that was because the "fan activities" that gave you the best chance to get tickets were the ones that also involved buying things.

[1] https://www.theguardian.com/music/2017/aug/31/bad-blood-is-t...

Emails still retain the structure of intra-office memos, something which hasn't existed for at least 20 years. We don't really notice with emails, because the initial real-world analogy became a minor detail of the more technologically evolved system. An optimistic view would be that VR will follow a similar trajectory, and attempts to recreate the real world will eventually give way to real innovations. The idea of the metaverse (and especially Meta's version), though, is so focussed on the real world analogy, I think it's more likely to be a barrier to this kind of innovation than an early version of it.

More useful than just the solutions on the Grauniad's site is https://www.fifteensquared.net/ which has solutions with explanations of most of the UK newspaper cryptic crosswords, including the Guardian.

When people write "why yet another", they usually mean "why this one specifically". And that's the case here, where the author lists what they think are the weaknesses of the state of the art, and explains why they think their innovations help with these problems. Innovation on its own isn't particularly interesting - I want to know why the author is innovating.

If your code is sufficiently distinct that block scope is useful, and there's no obvious contextual clue as to why it's distinct (like an if statement), put it in a separate function to explain why it's distinct. The article mentions this argument, but responds with some handwaving about how technically it's valid JS to use an unnamed block statement. I mean, sure, but does that mean it's a good idea?

The post gives an example - overloading a method based on the type parameter (e.g separate overloads for Option<Integer> and Option<Double>). This is why Java's generic erasure is more of a problem than Haskell's type erasure: Java erases generic parameters at compile time, whereas Haskell retains type information for long enough to use it when linking modules.

You don't need to distinguish KI (the kite) from KI (the kestrel followed by the idiot bird), because they evaluate to the same thing. Kite xy is y, and if you evaluate Kestrel Idiot xy, you get:

    KIxy -> Iy -> y

"Safari seems to ignore maximum-scale=1 and user-scalable=no"

This is somewhat ironic because, if memory serves, the original reason people started adding this to their HTML was because of some dubious scaling behaviour on iOS Safari (I think, if you didn't disable zooming, Safari responded to rotation by zooming the page to fill the new width, rather than laying out the page again).

AKA the Torvalds backup system https://lkml.org/lkml/1996/7/22/8

The Spring code isn't restricted to strings, it will accept any type. So you don't need to find unsafe string serialisation to get an RCE; what you need is some type which is unsafe when deserializing the output of its own serialise function (and for an attacker controlled instance of this type to be passed to this Spring method)

I don't think there's any vulnerability in your repo as it is. It's not deserializing attacker controlled data, it's deserializing a string which was serialised by the application. There could be a vulnerability if, instead of accepting a String, the controller accepted some other class, which itself had custom serialisation logic which was vulnerable.

I agree there's not much point using this kind of simple builder if you have named function parameters, but the GoF builder pattern has a couple of additional features which can still be useful. In the GoF examples the construction process is more complicated (maybe the order in which construction steps take place is significant, and maybe parts of the construction might be conditional), and the same construction algorithm can be used to produce different types of object. If I remember correctly, the main example in the GoF book is a builder for creating documents by adding a title, subtitle, paragraphs, etc, and the document being constructed might be a UI representation, an RTF file, HTML, etc.

Constructor inject is generally a positive here, though, as the compiler will tell you where you need to add the new dependency. If you find that you have to add the dependency in lots of places just to satisfy the compiler, not because the functionality actually requires the dependency, that's usually a sign the class should be broken up into classes with more clearly defined responsibilities.

You didn't want to couple your task to the Runnable interface, so instead you coupled it to an entire HTTP server? And in order to avoid the complexity of calling CompleteableFuture.runAsync, you're using an HTTP client? Could you explain in more detail how you think this is a simplification, because I don't get it?

ETA: I'm genuinely baffled by the proposed solution, and I struggled to phrase my comment in a way that didn't come off as confrontational. So please accept my apologies if it still appears overly negative; it's entirely possible I've not understood what your goals and constraints are.

JSF and GWT were rightly abandoned, but the new frameworks are different in ways that might be relevant. One of the main problems with JSF is the mismatch between it's stateful programming model, and HTTP's statelessness; as I understand it, LiveView uses a persistent websocket connection to a stateful server process, so that mismatch doesn't apply. Another JSF problem is it involves a component-based templating system that abstracts quite a long way from HTML, making it hard to figure out what's actually going on. LiveView, Hotwire, and htmx all seem to be much closer to HTML, which might make them easier to work with.

I admit I'm still to scarred by JSF to be keen to try out these new frameworks and find out if they've actually solved these problems, but I'd love to read an evaluation of the new server-side frameworks from someone who experienced the problems with the old ones.

Needs a [2005] tag

Video games are immensely addictive.

No they aren't, and the suggestion that people could be "addicted" to video games makes a mockery of the concept of addiction.

That link is about variable replacement in config strings, which is intentionally recursive. It doesn't mention the use of the variable replacement mechanism when interpolating values into log messages, which is what makes this vulnerability so bad, and as far as I can see was not intentional.

It's also not unlike JSF in the Java world, which went out of fashion 10 or so years ago, and for good reason: relying on a framework to paper over the distinction between client and server side turned out to be much more complicated and fragile than a cleanly defined separation. I haven't seen any authors or users of these recently developed server-side-first frameworks discuss this prior art, but I'd be interested to see if they've come up with a way around what seemed like a fundamental problem in the approach.

It seems a pretty big omission in a discussion of the US and nationhood to not mention the concept of civic nationalism, as the US is often considered the main example of civic nationalism. If a nation is an imagined community based on a myth of commonality, that myth doesn't have to be based on just biological natality (that's the etymology of "nation", but it's never been the whole meaning - definitions of nations have always appealed to a common heritage and tradition that is broader than just ancestry). The common myth can be one of values or a shared non-biological origin; indeed the belief that most Americans are descended from immigrants is an important part of the national mythology of the US. This is civic nationalism (and the idea of a nation as necessarily about common descent is, by contrast, referred to as "ethnic nationalism").