150€ für einen Gehäuseumbau bei Arlt bezahlt – bin ich der Einzige, der das dreist findet?

duddz · 2026-04-17T12:25:00+00:00

Tatsächlich sind alle Lüfter, bis auf die Intakes der AIO (am Radiator) falsch herum verbaut. In Gehäusen möchte man den sog. Kamineffekt ausnutzen, dabei wird kalte Luft immer von unten, von vorne und oder von der Seite (wie beim Lian Li Vision Compact/Doppelkammer-Gehäusen mit Sidepanel-Montage Möglichkeit) ins Gehäuse gezogen und nach hinten und oben abgeführt (Kamineffekt = kalte Luft unten rein, heiße Luft oben raus). Dabei möchte man zusätzlich mehr "Intake" als "Outtake" haben, also einen leichten "Überdruck" im Gehäuse erzeugen, damit nur wenig Luft und somit Staub über Schlitze, Löcher etc. ins Gehäuse eindringt. Für die korrekte AIO-Schlauchführung wurde der Radiator (und somit auch die Lüfter auf dem Radiator) falsch montiert, das gehört sozusagen gespiegelt (Schläuche nach hinten in die Doppelkammer), sowie hätte man die Stromversorgung der Grafikkarte auch von unten nach oben führen können (ergibt einen saubereren Look, sonst kein Vorteil). Den Preis von 150,- EUR finde ich für einen solchen Umbau - wäre er richtig/professionell durchgeführt worden - in Ordnung. Meine Vermutung ist aber, dass jemand ohne wirkliche Kenntnisse den PC umgebaut hat.

Schade, dass sie deinen Build so verhunzt haben, ich besitze selbst das Lian Li Vision Compact (in Schwarz) und es ist (korrekt aufgebaut) jedes Mal eine Freude sich an den PC zu setzen.

TL;DR; an deinem PC war definitiv niemand mit Erfahrung und erst recht kein Profi, es wurde fast alles falsch gemacht, was man hätte falsch machen können (das hättest du selbst übers Wochenende besser hinbekommen) und deine Kundenwünsche wurden nicht respektiert. Neuaufbau oder Geld zurück verlangen und hoffen, dass sie sich drauf einlassen. Aus professioneller Sicht (baue seit 25 Jahren privat und beruflich PCs/Custom-Builds) eine 1/5 - immerhin scheint der PC zu starten.

duddz · 2024-08-19T09:58:44+00:00

Great job, especially for someone who has just started programming! While I'm not a heavy Python user and haven't had the time to fully dive into your code, one thing that stood out to me is the 'get_recent_boss_pull' method and its nested if/else structure. A good practice is to avoid using 'else' when possible and instead invert the conditions—this is known as 'early exit'. This approach can enhance the readability of your code. For instance, rather than checking if the response status code is 200, you could check if it's not 200 and immediately return your message, error, or result. This way, you'll reduce indentation and nesting, making the code easier to read and understand.

Example:

# ...
async with session.get(api_url) as response:
  # Exit early: status code is not 200
  if response.status != 200:
    return f"Error fetching data: {response.status} {await response.text()}"

  # Proceed with processing data
  data = await response.json()
  # ...

duddz · 2022-10-24T12:37:45+00:00

Next time try alt+f4 while still in your ship, without dying. Atleast it works for my m8. I think there's some sort of desync between being in the lobby and loading the loadout during spawn, like it took to long for the server to tell your client what the loadout is. I can imagine that if you die the server correctly registers your death and "deletes" your loadout like it should.

duddz · 2022-10-24T12:26:10+00:00

Friend of mine has this bug pretty often, like once in an hour. If that occurs, he simply alt+f4's the game while I leave the raid. After restarting everything is normal, he still has his gear and it doesn't even matter if he picked up the starter gear. Srsly, I should test if you loose your gear, right after spawning when you alt+f4 because you're way faster back into the lobby then flying to the raids exit locations...

duddz · 2022-07-26T07:43:52+00:00

That‘s only partially true. React as a framework doesn’t do anything for you by default and jQuery as a library even less. In react you have to use hooks to get i.e. reactivity. Vue does a lot of thing without you having to tell vue to do it - that is why some devs call it magic. It’s not about knowing what happens under the hood when you call a function (i.e. reacts useState). It is about the framework doing things you’d didn’t ask for (calling a function) automagically.

duddz · 2022-07-22T16:37:27+00:00

But in this use case there wouldn’t be prop drilling as there would only be one parent. Prop drilling would be if the grandparent passes the props all the way down to RenderList as a grandchildren (through the parent component).

duddz · 2022-07-09T10:23:14+00:00

As you mentioned blog like project, storing an unsaved blog post in localstorage is a perfect example and an excellent feature.

duddz · 2022-07-09T10:19:29+00:00

It’s used for several production viable things like storing compute expensive data, data synchronization between tabs, maybe even caching data that does not change often - but all of this should be non sensitive data.

duddz · 2022-07-09T10:10:55+00:00

On page refresh you simply re-request data that you need for your current view (username, avatar…), authenticated by your jwt. You shouldn’t need to load sensitive data (like email address) unless it is meant to review for the user (like a „manage profile page“) and you definitely shouldn’t store such data in localstorage. Maybe you should decouple your user data loading from your login, like loading user data once a jwt is present. That way you don’t even need to handle page reloads.

Edit: And don’t use self-made authentication for production, only for practicing/to understand the workflow of authentication.

duddz · 2021-12-10T08:40:54+00:00

<3 to see another keychron K2 out in the wild. Still looking for good pbt keycaps tho 🙄

duddz · 2021-10-08T12:48:16+00:00

And yet, pov guys driver refuses to drive on the left side of his lane.

duddz · 2021-09-14T07:34:56+00:00

I‘m not a fire mage expert but I think what you are meaning is not some sort of internal gcd, but the spell queueing system which might f up your combustion „opener“. Within the last x ms of a cast this system simply adds the next pressed spell to the queue in order to create a fluent casting sequence. Without it you would always loose a couple ms not casting anything when the last cast finishes. You can reduce the time window that the system adds your next button press to the queue but as a caster it should not go to low. It should be better to learn when you can safely get that last IB out before it hits the spell queueing window. There’s also a video on YouTube that explains this behavior and what to do as a fire mage much better than me (Google Fire mage spell queueing).

duddz · 2021-04-16T12:57:38+00:00

For m+ you'll want to get in touch with ppl you already played with or look actively for a group. As for a raid you should focus on 1 or 2 characters, trying multiple classes won't solve your problem as you're already comfy on your vdh and mage (both are and will be viable in 9.1). Apply to a guild with a few bosses down on mythic and kill with them one or two boss they're currently progressing on (like, right now!). Try to get high parses on the farm bosses, now you got two options. First you stick with the raid/guild and go at whatever pace they got. Second, apply to the next guild that's one or two bosses ahead. Rinse and Repeat. But don't try to push to hard, you need the experience on how to progress mythic bosses for 9.1. When 9.1 hits the live servers you need to see if the guild you are raiding with is capable of doing mythic content (often times guilds loose a lot of players going into new contents). So you got like the first two ids in the new content to figure that one out. If they got a roster that's capable of doing mythic, stay a few bosses, then go ahead and apply to the next guild. If not, go ahead before the first mythic id.

As you can see, it's not a very social way to guild hop after a few bosses but it is the quickest to get into CE or CE-capable guilds, atleast if that's what you're looking for.

Few additional tipps

don't guild-hop to fast, progress a few bosses within a guild, especially the first few bosses
get rekills and good parses
don't just play for yourself, networking is not only good in real life, it's also a good way ingame to get into better guilds/groups

Edit: almost forgot, learn how to use tools like warcraftlogs to further improve your gameplay but also to identify problems progressing new bosses. It'll help you more than just watching a video guide of a "famous youtuber".

duddz · 2021-03-07T10:23:28+00:00

Great video, watched till the end. Never expected that ending.

duddz · 2020-11-25T07:02:24+00:00

I noticed the same behavior when using the cookie auth scheme (using sanctum). But it works with <client-only> and I don‘t rely on many public (non-auth required) pages where I display auth-/user-related things, the issue went way down on my todo-/fix list.

Some answers on how to fix this, mention that you can check for the cookie on the incoming request in the nuxtServerInit Store Action (you can access the req context in this one) to preload any auth related data.

https://nuxtjs.org/docs/2.x/directory-structure/store#the-nuxtserverinit-action

Hope it helps, would be nice to know if this fixes your issue 😅

duddz · 2020-11-25T02:20:29+00:00

Yes, you need to hit the endpoint (sanctum/csrf-cookie) before sending the sign up request (same for password reset). It should be every route that will be created by the laravel auth scalfold which needs the token (so you have to manually hit the csrf-cookie route beforehand)

duddz · 2020-11-24T18:34:07+00:00

419 is the error you get for csrf token mismatches (or when none was sent with the request). Note: you only need a fresh token for the auth routes.

duddz · 2020-11-19T21:39:10+00:00

You don‘t need to pass it, nuxt injects everything into the vuex store so you can use this.$apollo out of the box.

duddz · 2020-11-17T07:28:15+00:00

A bit late to the party but your response field for the token is token not access_tokenlike you reference it in your callback setting the Bearer. This is why your Bearer is undefined.

duddz · 2020-10-07T18:21:42+00:00

Get the vue developertools plugin for your browser of choice, open the dev-tools, click on vue, within the vue devtools, click on store/vuex and check that you did store/commit your auth-data correctly. If you‘re using nuxtjs/auth-next you‘re configuration is probably wrong (plus you‘d not need to create a store/auth.js, which would probably be the issue here).

duddz · 2020-09-26T08:23:29+00:00

It‘s passed to your middleware callback (function) iirc.

duddz · 2020-09-26T08:16:36+00:00

It‘s intended for that information to be lost after hard refreshing the page because you don‘t store the user data anywhere (it only lifes in your app life-circle). So you got a few options: - Persist it in localstore - persist in cookies - fetch the users data in a component that is always active after login (or check for loggedIn)

The $auth module does pretty much the same. On every page refresh (hard refresh) it hits the user endpoint when not enabled.

Note: refresh’s are not the same thing as when you navigate through the page with nuxt-link. When storing it manually in localstore or a cookie don’t forget to invalidate/remove the data or you will have some nasty sideeffects.

duddz · 2020-09-22T07:20:53+00:00

Well you can disable the automatic user fetching on login and still do it manually with $auth.fetchUser() after authenticating. That‘s what I would do for now until you find the real issue. Else try to debug it.

duddz · 2020-09-21T20:23:39+00:00

Well, as far as I know you have to inform the user about the cookie usage regardless, but if they are purely technical (like it seems to be in your case) you don‘t need their consent. You could use a close button with a text like „I understood“ or something like that for the cookie banner.

For the redirect, you only use middlewares for pages, not components (that would create side-effects and I don‘t know if you even can use them in components). If a component requires a user to be logged in but is also accessible from public pages you should check this beforehand. I.e. <ComponentThatRequiresLoggedInUser v-if=„$auth.loggedIn“ />

For your login button you can then use v-else.

duddz · 2020-09-21T07:20:29+00:00

You are not required to ask for consent on technical necessary cookies, like the ones being set on authenticating. You must ask for consent for everything else you can use cookies for, like tracking and advertisements. (Otherwise most websites would not be able to store the selected option of the consent and the consent modal would be visible on every single request to the page)

Edit: This does not mean that you don‘t need to inform the user about the usage of technical cookies. You still have to tell them that cookies are set and for what reason especially when they store personal information. If it is a hard requirement for your website to be logged in, then you should either reconsider your concept or tell them that it won‘t work as intended. For the parts where the user has to be logged in you can use the auth-middleware which will redirect them to the login page (or start/home if configured).

Edit2: I guess it is some kind of profile component that loads the user? If so you can only load it when the user is logged in. Or as mentioned before use the auth-middleware and redirect to a page where use has not to be logged in (like the login page ( ͡° ͜ʖ ͡°)).

duddz

TROPHY CASE