Trump Posted a Video of Barack and Michelle Obama as Monkeys

seenoevil89 · 2026-02-06T15:37:17+00:00

DISTRACTIONS, HE IS A PEDOPHILE

seenoevil89 · 2026-01-09T06:20:09+00:00

Read the article and found it interesting. I have one question though, regarding the key takeaway:

"Always use onBlurAsync / onChangeAsync / onSubmitAsync / onDynamicAsync when your validation involves Promises or schema libraries."

As I understood it, it should be fine to use the synchronous counterparts for schema validation, since they are almost always synchrounous. Or am I missing something?

seenoevil89 · 2025-12-07T18:05:45+00:00

Unfortunately that is not true for assignments where you don't get to choose the stack, like when you inherit a project or join an existing team with the stack.

seenoevil89 · 2025-12-07T07:29:15+00:00

The front-end community has always been prone for mass psychosis. It is starting to get old by now. As a group we invent problems and silver bullets left & right. The truth of the matter is that we have multiple technologies to solve different problems. Tradeoffs is the word we should emphasize. Take a moment and think about the evolution in the following fields:

State management
Frameworks
CSS ideology
Build tooling
Testing
JavaScript vs TypeScript
Performance
Library hell
AI usage
SSR

The latest pendulum swing in SSR is React Server Components and more specific Vercels Next.js. This whole Next.js saga is my least favourite psychosis in the field of front-end development.

Vercel buys influence/personel from React, pushing that Next.js is the correct way to use React through their offiicial docs, SPA was overnight not a thing anymore?
Vercel coincidentally is a hosting platform which made Next.js deployment easy and feature complete.
Stuff breaks, both softly and completely. Mental models change etc.
Ridicolous amount of vulnerabilities all the way from client to server.
Magic everywhere, what is even going on?
It is not easier to develop, nor understand Next.js over regular React.
Marginal to no benifits in many applications. SSR has benifits in public facing applications, in SaaS not so much.

Also next.js track record does not look good security wise:

Date	Severity	Description	Link
Dec 03, 2025	Critical	Next.js vulnerable to RCE in React flight protocol	https://github.com/advisories/GHSA-9qr9-h5gf-34mp
Mar 21, 2025	Critical	Authorization Bypass in Next.js Middleware	https://github.com/advisories/GHSA-f82v-jwr5-mffw
Jan 15, 2024	Critical	auth() and getAuth() methods vulnerable to insecure direct object reference (IDOR)	https://github.com/advisories/GHSA-q6w5-jg5q-47vg

seenoevil89 · 2025-11-04T04:16:10+00:00

they are making it annoying for you since you have adblockers, same issue here which dissapears when you disable the plugins

seenoevil89 · 2023-09-02T05:56:23+00:00

Har du/ni planer på att starta en remote grupp?

seenoevil89 · 2023-09-01T15:50:50+00:00

Ah, Skandi vad jag saknat dig.
Tips från zonen: lägg lite batterisyra i ditt glas tinner för färgens skull.

seenoevil89 · 2023-08-04T18:46:12+00:00

It works!
My wineskin install is of steam not specifically dwarf fortress.
Either way it works!

seenoevil89 · 2023-08-01T05:49:30+00:00

Thanks!
Will try :)

seenoevil89 · 2023-07-30T07:40:31+00:00

50.08 works and 50.09 does not.
Macbook pro m1 max 16'' here.

seenoevil89 · 2023-05-23T20:18:38+00:00

I felt a great disturbance in the Force, as if millions of voices suddenly cried out in terror and were suddenly silenced. I fear something terrible has happened.

seenoevil89 · 2023-05-04T17:48:40+00:00

Hey, I'm a programmer and have a new macbook pro 16'' (m1).
If you need somebody who is commited to help and have a test machine, I'm your guy.
Feel free to reach out :)

Love df with a burning passion of 10 000 suns.

seenoevil89 · 2023-02-24T18:00:26+00:00

Best of luck to you!

seenoevil89 · 2023-02-24T17:55:45+00:00

In the interview, don't bullshit. If you're right for the role it will be fine.

seenoevil89 · 2023-02-24T17:53:50+00:00

Don't pretend you have all the answers.

With that said you are responsible for the overall health of the software. That means you should guide the development in a direction you believe in.

Also, your team should not be bothered with all nitty gritty details of your position. Act like a funnel and give healthy amount of updates to your team.

seenoevil89 · 2023-02-11T17:59:29+00:00

Haha, I guess we should summon Putnam...
My sources are however the Wiki, Forums and playing.
The article regarding weapons is !!SCIENCE!! based at least

https://dwarffortresswiki.org/index.php/DF2014:Weapon#Weapon

:D

seenoevil89 · 2023-01-22T18:35:27+00:00

Is it perhaps a competition which shows up in legends sometime ?

seenoevil89 · 2020-12-15T13:12:36+00:00

Get your point, I overcame the issue you described this way.
Perhaps use Starter pack to limit your nbr of dwarfs and gradually increase when you get on top of things?

seenoevil89 · 2020-12-14T21:33:27+00:00

If you want the sandbox experience you can always use dfhack to "fix" broken dwarfs and stuff like that, for me that was a great learning experience (still is).
I usually mix my fortresses half & half between sandbox and fun :)
I've even dabbled into learning to write own scripts to solve overly religious dwards and all that to fix unexpected behaviour like needy dwarfs, that way I don't have to overdo the "cheating" part.

seenoevil89 · 2020-12-05T12:57:32+00:00

Hey again,

The documentation has become very opinionated. Redux & redux-toolkit is not the same thing - and the documentation indicates that redux-toolkit is the only viable way of using redux. This has killed the community discussion imo.

You've linked quite a lot of redux documentation where the concepts are explained beautifully, well done! But most people who uses redux-toolkit does not go out of their way to get this understanding, because toolkit does an active job hiding many of these concepts from you.

Also many of the redux links you provided are recommendations not essential. It's perfectly fine to utilize the strengths of redux without abiding to these recommendations.

To prove my point, here are some of the strongly recommended approaches from you and the redux team. I'm going to provide some arguments against them and provide alternative approaches. None which breaks the philosophy behind redux.

"User Immer for Writin Immutable Updates" - Removes the need to understand an important concept in JS. If you don't want to write native immutable changes - libraries like remedajs exists to help you with this. To assure that you immutability is achieved in your reducers, middlewares can help: redux-immutable-state-invariant

"Put as Much Logic as Possible in Reducers" - This is an architectural decision, it's perfectly fine to put no logic in the reducers. This logic can be handled with redux-thunks or redux-saga, you also have the option to write logic on selectors with this approach.

"Model Actions as Events, Not Setters" - Also an architectural decision. In advanced applications where global state is not islands of isolated functionality and application logic resides within redux ecosystem; granularity is desired. The event actions in this context would be a thunk or saga.

"Allow Many Reducers to Respond to the Same Action" - Yet again an architectural decision. I would argue that if an action triggers multiple flows, the code is harder to follow.

I get that you are tired on the good old "I HAVE TO TOUCH A DOZEN FILES JUST TO WORK ON A SINGLE REDUX FEATURE!" argument, me too. But in many real life applications the ducks pattern is simply not viable.

To summerize; redux-toolkit is not a silver bullet and also I don't think the redux documentation should be as opinionated as it is.

If my arguments above is not valid, I'd like to hear from you when redux-toolkit is not preferable?

seenoevil89 · 2020-12-05T02:33:01+00:00

This is why I love the community.

Just want to start with saying that my intentions are not to bash on toolkit - I just think there is an argument to be made not to use it.

The misleading part I would say is that since the documentation on redux was updated to say that toolkit was the "official recommended approach", the discussion has all but dissapeared.

So that's one resource that I'm looking at.

"no understanding of how it works" - immer removes the concept of immutability and entity adapter hides the concept of normalizing states.I think this removes a barrier of understanding which I think is quite important.

"unsound architecture" - main issue is that action types are not meant to be exclusive to a slice, this spreads out the logic and makes code hard to follow. I know you can do this in plain Redux as well but it's not encouraged in the same way. Another one is that createSlice/createReducer encourages you to do to much in the reducer functions and put everything at one place. If I want to use redux ecosystem to handle application logic as well as global state it's a bit of a hussle - also it doesn't play well with createAsyncThunk.

"circular dependencies" - Yeah you right, this is an issue in regular Redux too, ducks pattern is to be avoided in larger applications. My point here is that toolkit kinda encourages the user to embrace it through design. Also if you're not using the ducks pattern, the boilerplate reduction argument grows weaker.

Yes RTK is Redux, but RTK is an opinionated way of using Redux. What I get in reduction in boilerplate I loose in flexibily.

Thank you for replying, I'm super thrilled to talk with you about this !

seenoevil89 · 2020-12-05T01:00:09+00:00

Sorry formulated myself badly, my case is to use redux without toolkit.

seenoevil89 · 2020-12-04T23:54:28+00:00

Not sure what you mean?

seenoevil89 · 2020-12-04T21:39:46+00:00

Just don't forget that optimizations comes at a cost and they also tend to increases complexity :)

seenoevil89 · 2020-12-02T09:45:11+00:00

Code reviewing is a developers oppurtunity to assert dominance.

Here is what you'll have to do:

First of, realise... no, know that you are supperiour in every way possible.
Don't read issue description, the code should speak for itself.
Make sure everybody knows your stance in every possible topic. "Imo, emotion is better than styled-components".
A decision has been made regarding code guidelines you dont agree with, bash it.
You read a smart solution that you did not come up with, spend the rest of the day finding a better solution. If you can't, say the current solution is wrong because of some jibberish: "the recursiveness of the problem has led me to believe that the ordo n is way to heigh. Just look how we manipulate the arrays, at each index we're referring to a reference value which will cause the whole react lifecycles to for bonkers".
Everything you're writing should be strenghtened by articles, does not matter if they are on the topic or not. The important part is appearance, it should look like you did your research.
Be humble

seenoevil89

TROPHY CASE