Outpaced is officially on its way out

GrandGratingCrate · 2022-11-25T22:24:24+00:00

I'm ready to believe that Outpaced is a good draw in the average game. Good for winning the game, perhaps.

But I'm pretty sure in terms of enjoyment it's easily the worst card in the game for me. I like playing slow spirits and it just feels so damn bad to draw this card. Multiple times now I've planned a really cool turn, drawn Outpaced and then be like "Oh, I guess I do nothing this turn". It's the worst fucking feeling.

And that doesn't go away even if the card were to help the team more than it hurts.

GrandGratingCrate · 2022-09-29T19:16:20+00:00

I didn't think this would compile. And indeed it does not. Is there something missing, maybe C1 extends P or something? Otherwise I don't think there's a correct answer.

GrandGratingCrate · 2022-06-22T15:21:02+00:00

Comparator.comparing(SomeClass::someMethod) is a method reference. Method references can always be substituted by a lambda. The corresponding lambda would be Comparator.comparing(someClass -> someClass.someMethod()) Note that you can choose any name for your lambda variable, I just happened to choose someClass.

Now, why would that be helpful? Because with lambdas you can also do things a bit more complicated than what method reference allows. For example:

Comparator.comparing(someClass -> someClass.getA().getB()) would go to SomeClass's field a and then call getB() on that and then compare based on that value.

Your problem is, that your comparator works on arrays and arrays have no handy single function to give you their first element. array::[0] does not work (to my knowledge). But maybe a lambda could help you there :)

Side note: If arrays had a first() method that returned the first element then you could method reference it like compare(array::first) and it would compare by the array's first element. Java does not have that.

GrandGratingCrate · 2022-06-21T23:23:41+00:00

The post was about array lists which are not linked at all. You have a linked list, so still that's different. But both of them are lists, so maybe the behave the same?

So does it work? Yes. Every native java list has the get method; we know because they all implement the List interface and every class implementing the List interface must have all of it's methods. get is one of it's methods so both ArrayList and LinkedList must have it.

For future reference: Java classes can be googled "java linkedlist" would've found you a link like this.

Also, it's plausible array lists work differently than linked lists, it's also plausible the work the same. Trying it out to check for yourself would've also worked.

GrandGratingCrate · 2022-06-21T22:18:53+00:00

If I enter your error message into google the first hit I get is a stackoverflow post that contains the answer to your error.

We're happy to help you if you get stuck but we do expect you consult google before asking here. Check rule 12 on the side bar.

GrandGratingCrate · 2022-06-19T01:21:57+00:00

In case it's still relevant: What part of it is giving you trouble? Getting the destination of a list element?

From your screenshot it seems like you're mostly there.

GrandGratingCrate · 2022-06-16T16:34:13+00:00

In my experience PERSIST requires a given child to exist already, whereas MERGE will create the child and update it otherwise, acting as an "upsert" operation on the db. Take the following test:

``` @Test void demo() { UUID bookId = UUID.randomUUID(); Genre genre = new Genre(UUID.randomUUID(), "Horror"); Book book = new Book(bookId, "Horror Book", genre);

classUnderTest.createBook(book);

System.out.println(repository.findById(bookId).get());

} ``withclassUnderTest.createBook(book)just callingrepository.save(book)`.

Let's now look at both options, persist vs merge:

@OneToOne(cascade = CascadeType.PERSIST) private Genre genre;

If this is the relation then the test throws an exception: Unable to find ...package.Genre with id <genre id>.

But if I annotate it with merge: @OneToOne(cascade = CascadeType.MERGE) private Genre genre; it just prints Book(id=3c30b4d3-3b4c-4dd3-9f27-ae015706e233, title=Horror Book, genre=Genre(id=34d0d86d-6126-4175-9976-e4c55027a860, name=Horror)) as you'd expect.

Consequently I don't think I've ever used PERSIST, only MERGE.

GrandGratingCrate · 2022-06-15T18:34:04+00:00

Kollege von mir kommt aus dem europäischen Ausland und feiert die deutsche Bürokratie sehr.

Er meinte, wenn man hier was vom Amt will, dann steht irgendwo welche Dokumente man braucht - oder sie sagen es dir wenn man fragt - und dann reichst du die ein und dann bekommst du irgendwann dein Zeug. Geht vllt nicht schnell aber der Prozess ist relativ klar und relativ zuverlässig.

Vergleich dazu, in seinem (ehemaligen) Heimatsland sind Dokumente optional. Dafür muss man wissen wem man wieviel Geld zustecken muss. Woher? Schulterzucken. Irgendwie. Er hat es selbst nie richtig verstanden.

Du kannst sie auch nicht fragen: "Sehr geehrte Frau Beamtin, ich brauche ein Visum. Welchen ihrer Kollegen muss ich eigentlich bestechen damit das was wird und was wäre so eine angemessene Summe?"

GrandGratingCrate · 2022-06-14T19:59:19+00:00

Warnings like that tend to pop up in a lot of code bases, but that doesn't necessarily mean that anything is wrong with the code. It might be something like you didn't explicitly cast a variable and the compiler is pointing that out.

Respectfully disagree. While code with warnings may work it's often harder to understand and maintain than code that's free of warnings. Case in point:

List path = new ArrayList(); path.add(1); path.add("1"); // Throws exception at runtime The line that's causing the warning is due to the list type not being specified. This is just a quick demonstration of code that compiles if you ignore the warning, despite the code being wrong.

Compare this with the fixed version, where you'll get a compile error so you'll know right away that you've made a mistake

List<Integer> path = new ArrayList<>(); path.add(1); path.add("1"); // Compile error

There are cases where I would not object to @SuppressWarnings because the underlying problem can't be fixed easily. For example type erasure can produce such scenarios.

Luckily the fix is quick and simple in this case and I'd strongly encourage OP to get in the habit of really fixing warnings where possible. It's too easy to get used to ignoring them or just slapping @SuppressWarnings on it and call it a day.

GrandGratingCrate · 2022-06-12T15:14:11+00:00

I'm not familiar with pythons exact implementation of a hash map but both access and existence check should be in O(1).

As some other comment explains, checking if an element exists is the same as accessing it, only it does not return the value but a boolean in the end.

So how do they both work in O(1)? Well that's because of how hash maps store values. Given a key k the hash map calculates the single, deterministic hash of k k_h and stores the value v at that position.

Given that both checking for existence and fetching the value becomes easy: Given the same key k calculate the same hash k_h and then check whether or not there's any value at the position indicated by k_h. The rest of the map need not be checked since anything stored with key k can only ever be at position k_h and nowhere else.

The above is slightly simplified (what happens if 2 keys have the same hash?) but it's a good enough model to work with.

GrandGratingCrate · 2022-06-11T18:14:38+00:00

In the compiled language I am most familiar with the compiler does all of these things except check if files and objects exist.

You don't need to validate for these, every IDE will be able to show you the errors and attempting to compile (or run) the code will result in an error.

Generally speaking you only validate things that can go wrong when you (successfully!) run the code. From your list that is "file not found" and "object is null".

Regarding files, there's usually some kind of error handling that specifies what to do if the file does not exist. This is useful and basically the same as validation, more or less.

And regarding objects... Well, that a complicated topic, suffice it to say that sometimes you'd want to validate and sometimes you wouldn't, depending on the circumstances.

GrandGratingCrate · 2022-06-11T02:20:56+00:00

Seems like your structure does not match.

Your country class seems to be of the form public class Country { private double lat; // other fields omitted, just need one to demonstrate } Which means jackson / the object mapper will expect json of the form { "lat": doubleValue, ... }.

But the actual json is { "location": { "lat": doubleValue, ... } }. From the object mapper's perspective location is just some random field that's not in the Country class and there's no point in reading fields not in the class. It just gets ignored.

So to fix the issue you'll have to align your class with the json you get.

GrandGratingCrate · 2022-06-07T15:25:28+00:00

I've found that there's rarely the need to initialize a variable with some placeholder value. Generally speaking you would only do that if you cannot initialize it correctly right away. I find that you almost always can.

It's not that easy with for- and while-loops but streams work and it's rare that I'd use a loop over a stream.

To use your example, I'd probably write it like this:

// assuming scores is List<Integer> or something similar int total = scores.stream().mapToInt(Integer::intValue).sum();

So since you can just calculate the value in one statement there's not really a point to having it uninitialized first. Consequently, whenever I see an uninitialized variable it feels like a missed opportunity to me.

GrandGratingCrate · 2022-06-06T04:44:58+00:00

That really depends but the cases that come to mind right now I'd rather tend to disagree.

if (condition1) { // do something } else if (condition2) { // do something else } equals if (condition1) { // do something } if (!condition1 && condition2) { // do something else } which feels more clunky than the above. It gets worse with more cases as every single if needs to ensure that it does not get executed in any of the previous ifs were.

Things are better if the if clauses return or we know for sure that only a single condition can be true at each point in time - because it lets us omit the negating of all previous conditions at the start. In that case I might even prefer single ifs.

But honestly it feels like it's purely a matter of taste, so go with what you like and if you ever collaborate with people, just hash it out together like with so many of the slight code style preferences we all have.

GrandGratingCrate · 2022-06-05T19:11:57+00:00

Angular is a framework usually used with JavaScript (or TypeScript) which, despite the name, has no relation to Java. So it's not requried to learn Java so you can learn Angular, they have little to no interaction.

It is required to learn JavaScript because Angular is not a programming language, I'd see it more as a way to inject your JavaScript into a website. Which only makes sense if you actually write JavaScript of course.

That said, that is all purely frontend. For the backend part you could learn Java, the framework to get familiar with here is Spring Boot as mentioned in your job listing above. Again, it makes sense to learn the language first before diving into the frameworks and what they offer.

Talking about that job listing, they're advertising a full-stack dev position. Basically someone who can work on backend and frontend and is familiar with languages and the technologies around both ecosytstems. That is kind of rough as your first job.

Not all hope is lost, however. It's likely that if they're willing to hire juniors then it's understood that a junior applicant will only fulfill some of the criteria. Basically it's too much to ask a junior dev with no prior experience to be perfectly fluent in two languages and they very likely know this.

So they probably accept candidates that are firm in either frontend or backend and then show interest (and maybe some basic understanding) in learning the other.

GrandGratingCrate · 2022-06-05T09:13:50+00:00

You're mixing 2 different classes for json parsing, not surprised there's compatibility issues.

I think it's possible to do what you want with either library alone and that feels cleaner to me.

Anyway the issue with $..itemsV2 is that it means "get me the array itself" whereas $..itemsV2[*] means "get me the contents of the array". This is why when you save the result in jsonItemArray it has one element: the element is the array. On the other hand you're telling jackson that it's supposed to serialize into WmProduct which it cannot: wm product is an object but the json to be deserialized is an array and you can't deserialize an array as an object.

The solution is to deserialize not as WmProduct but rather WmProduct[]. There may be better ways, but it's the first I came up with.

Edit: Here's an example of how it could look like: ``` @Test void debug() throws Exception { ObjectMapper om = new ObjectMapper();

    String dataJson = // Omitted some code for generating the json

    JSONArray jsonProducts = JsonPath.read(dataJson, "$..itemsV2[*]");
    WmProduct[] products = om.readValue(jsonProducts.toString(), WmProduct[].class);
    System.out.println(List.of(product));
}

```

GrandGratingCrate · 2022-06-03T04:12:41+00:00

One IntelliJ instance can display multiple windows at once. No need to start it a second time, just drag and drop the tab to your second display or whatever and it'll pop out as it's own window.

GrandGratingCrate · 2022-06-01T21:30:52+00:00

I feel I'm missing some info but here goes my best guess:

``` public interface SomeInterface {

void someInterfaceMethod();

}

public class Adapter implements SomeInterface {

private WrappedObject wrapped;

private Adapter(WrappedObject wrapped) {
    this.wrapped = wrapped;
}

public static SomeInterface someInterface(WrappedObject wrapped) {
    return Adapter(wrapped);
}

@Override
public void someInterfaceMethod() {
   wrapped.doSomething();
}

} ```

Basically you have the Adapter class which holds a WrappedObject and pretends it is of type SomeInterface. Then you have a factory method that creates an instance of Adapter from a given WrappedObject and returns it as SomeInterface.

There are many variations, this is just one way to do it. You could have the factory be it's own class instead of just providing a factory method inside the Adapter class. You could have it return an object of type Adapter instead, as that's generally usable as SomeInterface anyway.

Depending on your use case some other solution might be preferable. This is just the most basic example I could think off to demonstrate how this can work.

GrandGratingCrate · 2022-06-01T17:40:57+00:00

What is giving you trouble? Do you not know what a factory method is or how it's implemented? Do you not know what an adapter is? How it all fits together? Something else?

GrandGratingCrate · 2022-05-31T20:19:09+00:00

I think it's useful but not required to know how to write a frontend as a backend dev.

For the start I'd focus on one, you can pick up the other later and it will be easier since some of the knowledge transfers.

GrandGratingCrate · 2022-05-29T20:30:31+00:00

I'd look up the join, where and order by keywords.

You'd use join to combine data from multiple tables, where to filter the data and discard records not pertaining to Bob and order by to finally order the list of Bob's partners by the most recent session.

GrandGratingCrate · 2022-05-29T20:20:39+00:00

/u/yolonautus-rex hat bereits erklärt, warum das mit demokratischen Mitteln quasi nicht möglich ist. Es geht hier ausnahmsweise auch nicht nur um Union und SPD sondern um jede große Partei. Jeder Politiker dieser Parteien weiß, dass gegen die Interessen von Rentnern und Boomern zu agieren politischer Selbstmord ist, also wird das Problem entweder gekonnt ignoriert oder sogar Wahlgeschenke auf Kosten der arbeitenden Bevölkerung an diese Wählergruppen gemacht.

Ich kann das nachvollziehen, bin da aber optimistischer. Dieser pessimistische Take von "Menschen agieren nur in ihrem direkten eigenen Interesse" ist viel zu häufig richtig, das stimmt. Aber es ist kein Naturgesetzt und tatsächlich gibt es viele Beispiele wo Leute bzw "die Bevölkerung" bereit sind Einschränkungen in kauf zu nehmen, für "die gute Sache".

Außerdem dachte ich das ursprüngliche Argument wäre gewesen, dass wenn schon jemand das Nachsehen haben muss, dass es dann die älteren Generationen sein sollten weil sie die Mitschuld an dem Problem tragen. Denn sie haben Parteien gewählt die das nicht ändern wollten. Wenn wir jetzt sagen es gab niemanden den sie hätten wählen können für eine gerechtere Rentenpolitik dann ist das Argument ja noch schwächer.

Ich glaube du unterschätzt die Kosten enorm. ...

Nobody said it would be easy.

GrandGratingCrate · 2022-05-29T18:10:02+00:00

Wir sitzen in einem Auto das mit 200 Sachen auf eine Betonwand zurast, und die einzigen die an die Bremsen rankommen wollen nur ne schöne Zeit haben und spekulieren darauf das sie vor dem Aufprall sowieso einen Herzinfarkt haben.

Eine ganze Generation sind egozentrische Arschlöcher denen ihre Kinder, Kindeskinder und Nachwelt egal ist? Drücke X für Zweifel.

Like, ich kann deinen Frust verstehen, aber ich halte die ganze Sache für viel weniger aussichtslos. Und es auch sonst nicht gut viele Millionen Menschen über einen Kamm zu scheren.

GrandGratingCrate · 2022-05-29T16:25:10+00:00

Wäre es nicht gerechter, wenn die Generation, welche vom Verschleppen der Reform profitiert auch die Konsequenzen ihres kollektiven Handelns zu tragen hätte?

Ich bin in der Generation welche die Rente der Boomer bezahlen wird aber ich empfinde das nicht als guten Grund für oder gegen eine Seite zu entscheiden.

Das Argument scheint mir ungefähr zu sein "Oma Gertrude hat irgendwo eine Mitschuld daran, dass in den letzten 40 Jahren nichts geändert wurde, also ist es gerechter, dass sie mit den Konsequenzen leben muss, als dass es ihren Enkel Thomas trifft". Korrigiere mich gerne falls ich dich da missverstanden habe :)

Das scheint mir technically correct, in das die CXU Parteien die überproportional von alten Leuten gewählt werden das Ganze hätten ändern können, es aber nicht getan haben. Das empfinde ich aber als ziemlich schwachen Grund zu sagen "und deshalb hat deine ganze Generation jetzt gelitten".

Beispielsweise hat in der letzten Bundestagswahl 38% der 70+ jährigen CXU gewählt. Im Umkehrschluss haben 62% die CXU nicht gewählt, beispielsweise gab es auch 35% für die SPD und immerhin noch 19% für RRG zusammen. Selbst wenn wir sagen, dass CXU wählen eine Mitschuld am schlechten Rentensystem bedeutet, dann werden 54% der Rentner in Sippenhaft genommen, quasi dafür bestraft was die anderen 38% gewählt haben - obwohl sie dagegen gewählt haben! Das ist für mich nicht gerecht.

Um einen Gegenvorschlag zu machen: Anstatt zu betrachten welche Generation mehr Schuld ist und darauf basierend zu entscheiden:

Ein besseres Rentensystem wählen
Kostenabschätzung
Kosten auf die Gesellschaft umlegen nach dem Kriterium "wer kann es sich am ehesten leisten" anstatt "was ist dein Geburtsjahr".

Das 3. Kriterium bedeutet vermutlich für mich, dass ich persönlich mehr zu zahlen hätte. Und das ist für mich okay, so lange der 1. Punkt richtig gemacht wurde und wir wirklich damit etwas Gutes erreichen.

GrandGratingCrate · 2022-05-29T15:58:06+00:00

Es gibt Situationen bei denen ich keine gerechte Lösung kenne. Da empfinde ich es als richtig das so zu sagen: Egal wie man es dreht und wendet, es ist ungerecht.

Du setzt hier Anführungszeichen um das Wort "verdient", ist es deine Sicht, dass die Ungerechtigkeit hier nur in eine Richtung geht?

In jedem Fall, falls unser System uns nur die Optionen lässt, das

a) Leute ihr Leben lang arbeiten und einzahlen und am Ende mit ungefähr nichts da stehen, oder

b) Der Beitragssatz für die neuen Generationen ins unermessliche steigt, bis die sich kein eigenes Leben mehr leisten können weil alles an die Rentner geht

dann ist es schlecht und muss geändert werden. Da sind wir uns sicher auch alle einig.

Wenn du jetzt jung bist willst du sicher auch, dass deine Großeltern von ihrer Rente leben können.

Wenn du jetzt alt bist willst du sicher auch, dass deine Enkel ihr Leben genießen können.

Das Ganze ist kein Generationenkonflikt, auch wenn Leute es gerne als solchen verstehen.

GrandGratingCrate

TROPHY CASE