Nice! Magic find increases the chance that a white item is turned into a magic, rare or legendary when it drops.  https://diablo-archive.fandom.com/wiki/Magic_Find_(Diablo_II)?file=MF_Graph.jpg

You rarely want more than 300mf, because it has diminishing returns.

And we warn of serious consequences for the genocide of Palestinians. Get fucked, Blitstein.

A main reason I switched to OrcaSlicer was that it can generate calibration prints for you.

You could just edit the gcode manually with a text editor. 

For the temp tower, edit the parameters sent to https://marlinfw.org/docs/gcode/M109.html . Each line should say M109 R<new temp>, like M109 R200 .

I took a course on exercise at university to get some "free points" one semester. One thing we learned was that studies show that an increase in strength decreses your all-cause mortality. It could be by over 10% as you got old.  So strength makes you live longer, statistically.

Probably because of how ava looks in this font. It got a "corporate trying to be friendly" vibe

Using too many fancy keywords. Keep it simple, you only use inline reified crossinline when you really have to. Don't make extension functions all the time, only when they make sense and then keeo them private most of the time.

Also learn how kotlin does Singletons with object.

Multiple classes in the same file is often a good thing. It lets you keep small return value wrappers and similiar, close by.

Use data class often, it's nice being immutable with copy and default toString etc. Don't use Pairs as return value, it makes for cluttered code. 

Oi, den er blandt mine favoritter på boks, nå ble jeg gira på å teste den på tapp!

Does it make noise if you turn it off an move the print head sideways with your hand?

Are the wheels on the head too tight? It should not wobble up and down if you poke it, but it should not be any tighter than just enough to stop the wobble. The dust is probably just the wheels wearing out, they do this and it's normal. Wipe off the dust with a paper towel. 

There should not be debris or loose parts inside the belt rail. If you tilt or shake the printer and hear anything, try to remove it.

The belts should be appropriately tightened. Usually all the way tight and then one full turn back.

Well you said it yourself. The campaign has to be skipped if you want any fun. I played the campaign.

D4 is so linear, easy, unrewarding and boring, you're not wrong. Im playing the campaign and it sucks. The game is too easy, I 1hit from lvl 1 to 30 and always have full hp, I can afk tank for 1 minute without getting low, my gear does no difference.

The only fun part is act 6 where the monsters are lvl 45 and I'm 30, and the density is high and I kill a lot of bosses. The acts 1 to 5 are just cutscenes, dialogs and bosses that take 3 seconds to kill. It's an ARPG without the Action, no difficulty and effectful gear,  and too easy.

I hope it gets better when I start doing the endgame stuff instead. Because the acts suck balls.

I'm doing the campaign, and by lvl 20-30 and act 3 im still having full inventories of yellows. And 5 legendaries. It's too much still.

And the game is too easy from the start. I hold left click to win, tank anything and 1-3 shot everything. I feel my power is dropping as I level, because enemies get mire spongy but that's it.  In d2 you struggle with stamina, mana, and the mobs in the den of evil will actually kill you if you don't kite. I liked that better, because your gear and stats make a noticeable difference.

It would make sense if you have any algorithms that run on all kinds of products. Or methods that they all shared. 

You could also define those fields in an interface. Make use of the override val id: String etc in the data class constructor.

In kotlin, learn to use the default argument values in constructors to enable Dependency inversion without too much boilerplate and mess.

You can replace/mock services/clients in tests and simply skip the property in production code.

```kotlin class MyService(   val httpClient = JavaHttpClient() ) {   fun doThing() = httpClient.get("123")

}

// main.kt MyService().doThing()

//test val client = { url -> OkResponse() }

val service = MyService(httpClient = client)

assertThat(service.doThing()).isEqualTo(...) ```

  1. Package by feature. Find the main categories of high level features and use those as package names. 

For your routes specifically, it is no one-size-fits-all answer. One file is fine, if you have few and small routes. One folder per route is fine, if you have many routes that also have some extra classes they need etc. You can refactor when one solution doesnt work. Start with a single file, and split when you feel it is too big.

  1. Why do you need to reuse classes? Avoid inheritance, it is just high coupling for low benefits. Composition may be more favorable. Could the data you wanted in Product just be a single object field on Book instead? 

  2. Will the project enter production? Will other people work on it? If so, write tests: unit and (e2e/service) acceptance tests. Otherwise people will become afraid of commiting code in case something breaks. To do this, you often need some SOLID.  Especially the S to keep unit tests focused, and the D for testability. O and L is not that big deal, just skip inheritance if you can; it's an edge-case of OOP not the default.

When people start making their own reified inline crossinline noinline functions 🤯 And too many infix functions. And lambda parameters (in higher order functions) without kdoc or hints to what the lambdas are/do.

I've been using maven for a few years and it works fine with kotlin.

If you just need dependencies, shaded fat jar and lint/sonar it works fine.

Haven't tried it for android, maven probably misses a plugin or two.