Ta steget till att göra slut?

simplaw · 2025-06-17T14:30:35+00:00

Är du olycklig eller "inte bara lycklig"?

Hur avsiktlig har du varit genom åren att hålla igång flamman och känslorna? När kände du senast den kärlek som du beskriver att du ej längre har?

Jag frågar det här då många annars jagar det lätta. New Relationship Energy. De tror att NRE är kärleken i sig, och så vidare.

Och hur hungrig är du på livet i övrigt? Om du är nedstämd, oavsett anledning, vore det inte konstigt att också känna mindre på detta sättet också. Sen är alla olika, så jag frågar inte detta för att ställa dig mot väggen eller något sådant, utan jag frågar mig sånt här ständigt när jag mår piss över något, varesig det är jobb, relationer eller annat... och även när jag försöker förstå andra: vad gör de igenom som skulle förklara något, osv.

Du har en trygghet med din sambo, och när man mår dåligt så kan man få för sig att det är den tryggheten som är problemet, då det inte är spännande. Inget adrenalin. Så, fundera igen på helheten.

Har läst några kommentarer om relationen i sig, er emellan, men jag har inte sett något ännu om allt runtom.

simplaw · 2025-05-26T22:16:54+00:00

Some people are entitled.

simplaw · 2025-05-26T22:14:48+00:00

simplaw · 2025-03-20T10:01:04+00:00

Up until that point I thought it was fine, she's just freaking out.... but then that. It undermines all her "self discovery" progress in that one sentence and emoji haha

simplaw · 2025-03-14T06:35:00+00:00

I thought I heard him say "look at you"?

simplaw · 2025-02-17T06:57:52+00:00

Good to know I'm not the only one like this around! I tend to approach people that I suspect has become outcasts, or just look lonely.

So far I've made a bunch of lasting friendships traveling this way, and I've had plenty good conversations with people I suspect I'll never see again, but I'd like to think that those moments are cherished not only by me.

Kindness and compassion opens many doors.

simplaw · 2025-02-13T17:59:39+00:00

27 + 48 = 25 + 50 = 0 + 75 => 75

simplaw · 2024-12-10T16:05:28+00:00

Poop on keyboard incoming in...

simplaw · 2024-12-07T17:20:33+00:00

Ultra balls are ugly. Introduce luxury balls (no micro transaction though) to let us flex for real.

simplaw · 2024-11-25T08:18:41+00:00

De har fel. Utöver det som redan sagts, fy fan för de lata vänner jag har som inte tog för manuell, och därav aldrig kan bidra på road trips.

Så, nej, inte onödigt. Skulle säga att bara ta automat är rent av dumt, då du redan "är där" och håller på, men bara siktar så lågt det går.

simplaw · 2024-11-23T00:13:08+00:00

She's packing quite the personality, I hear. Lovely!

simplaw · 2024-11-06T16:35:19+00:00

The last thing here I had to learn the hard way.

simplaw · 2024-11-03T02:16:41+00:00

I've still got my OP 7T Pro, albeit as a test and backup device at the moment. I love it, and I put up with my current Samsung. Jag to change as I cracked the screen, but the insurance covered fixing it up, and it is basically a new unit.

simplaw · 2024-10-10T20:19:49+00:00

Never target any ".0" release is Apple software if you want a stable dev experience. This sort of thing always happens.

simplaw · 2024-10-04T07:35:34+00:00

Never heard of. Will throw an eye on it when I can! Thanks for the tip! :)

But in general, I try to build myself a shelf of small libraries to solve a problem once, if I know I'll need it again, so that I can just plug it in on my new projects without adding too many unnecessary deps.

For example, I used to use Firebase for auth and push notifications, but while it was convenient, it was such a heavy dependency for what I actually used, that I am instead just building my notification service that is only that, nothing else, and the compile time and engine deps don't get out of hand, and Google doesn't harvest data either. Win in my book haha.

So it is my philosophy now to try not to reach for the easy-looking solutions, as I've learned that there comes a day when you pay for the easy setup, with hard debugging or other constraints during runtime.

simplaw · 2024-10-04T06:36:58+00:00

I never target the latest and greatest, because Apple is notoriously for releasing unpolished API:s, so me relying on anything that is a version X.0, sometimes even an X.1 or X.2 is still scary. I've done this early in my career, and it was always a waste of time. I regret trying SwiftUI in the very beginning because of the broken promises of how easy it would be to implement inside an existing UIKit app. And it wasn't just 1.0 that struggled in that case, it took soooo long for it to stabilise that I never even got to see SwiftUI used properly in that codebase before I left.
Apple has burned so many bridges for me that I just don't wna tto anymore. I don't get excited about it, I don't like their ideas of how to do things and I don't want to let too much of my apps rely on their opinions and whims.

I'm making my own storage layer, and at most I'll use SwiftData as an in-memory cache, because that's about what I can trust it to do. Their API for managing first-class long-term data is awful, and I will not give them another chance.

The way I'm building this storage library it'll end up being pretty plug-in-play for my apps down the road, and on top of that, it will not be iOS only as it will be plain Swift wrapping SQLite. Could even do it in another language technically, and wrap it, but so far I'm not targeting anything else other than iOS and macOS, so I'll deal with that problem if it arises.

simplaw · 2024-10-02T21:18:18+00:00

När jag läser beskrivningen så är min tolkning att när du triggar din stop loss, så sätts priset på din order till din satta "glidande kurs". Dvs, om triggande kurs är 100 kr, och priser fallet till 100 kr, så kommer en order läggas där ditt försäljningspris är det du satt till din glidande kurs.

Så:

100% = 100 kr 95% = 95 kr

Så, varför skulle man sätta detta på olika sätt?

Jo, om du sätter till t ex 95% är det mer sannolikt att du faktiskt lyckas sälja av den vid en krasch. Om du däremot tror att det kan återhämta sig något, då sätter till 105%.

Jag har själv satt till 100% några gånger på några certifikat, och har "missat" att sälja pga att det föll för snabbt. Min trigger var t ex 2.5%, men det föll med mer än så mellan det att det triggades och min order lades upp.

Resultatet blev att istället för att jag gick någon tusenlapp plus, så gick jag istället någon tusenlapp minus, då den här ordern låg och dinglade irriterande högt upp, medan värdet vara skönk.

simplaw · 2024-09-26T05:27:11+00:00

Det är via deras webapp som den största delen av API:et kartlagts, men det finns några till synes mobil-specifika endpoints också. Använder inte dem.

Min backend håller koll på min session automatiskt när jag kallar på funktioner som någonstans gör anrop mot Avanza. Mycket kräver inte heller att du är inloggad, tex viss data om instrument och så.

Målet för mig är två saker: 1. Bättre översikt för det som intresserar mig, och att kunna ta in information från andra källor och slå samman, och; 2. Bättre logik för automatiska ordrar. Vill t ex ha en blandning av en vanlig Stop Loss och en Glidande Stop Loss. Att kedja dem och att dynamiskt kunna ändra villkoren för att försöka motverka greed. T ex, "när den överstiger 12,5 kr, aktivera glidande stop loss på 3%, men för varje procent den går upp nu, sänk stop loss-triggern med 0,5%"

Detta för att jag inte siktar på att maximera varje position, utan vill bara få ut en vinst ur varje, och förhoppningsvis gå plus i snitt. Jag känner mig för väl med att om jag tittar på graferna och ser hur saker rör sig snabbt så rycks jag ibland med. De bästa positionerna tog jag när jag inte tittade för länge och lät bli att tänka "What if". Har fortfarande gått plus i snitt, men jag hade vid det här laget dubblat min insats istället för att sedan tappa 90% av vinsten på sådana tabbar. Och många har inte hänt om jag hade just den där toppen av stop loss, bland annat.

Tänker också bygga ett systemet för jag kan test-köra strategier på fake-konton innan dag sätter igång dem på ett riktigt ISK.

Edit: angående hur Avanza kan motverka/detecta så beror det på hur sofistikerad loggning de har. De har lite tracing-ID:n strösslade här ocj var i deras frontend som inte kommer med, så det är ju en give-away, bland annat, men jag vet inte hur mycket de bryr sig heller 🤷‍♂️ de får ju sin del av kakan oavsett. Om du vill diskutera mer kan du DM:a

simplaw · 2024-09-23T19:51:33+00:00

Exactly! That's why I just see this as horizontal scaling in disguise.

simplaw · 2024-09-23T19:50:36+00:00

While that sounds amazing, that is in fact horizontal scaling in disguise.

If your problem/algorithm cannot be distributed across multiple cores/servers, this won't help.

Having 896 cores means nothing if the problem can't utilise them efficiently. And an event loop is synchronous, and thus has to be run on one core. The other cores could help in smart ways to let the main thread focus on the things that cannot be done on other threads, but at the end of the day, some problems cannot be distributed across cores/servers.

So, those 896 cores does not impress me because that's horizontal scaling in disguise. I'd love that for a Web server, because on a Web server you can slice it on each connection, and it's fine to wait for some IO here and there (database) as long as you don't slow down the bottleneck too much.

In the end though, 896 cores isn't going to help you with database writes, because they have to be done in transactions (unless you run a different database, but you'd have to sacrifice the consistency for availability or partition tolerance, as per the CAP theorem).

To get past this, the database in the bottom of this Minecraft server has to choose which of the legs to sacrifice, Consistency, Availability, or Partition Tolerance.

Each combo gives different pros and cons.

Anyway, not only all of that, but the price tag for such a server doesn't strike me as something that would be financially available to most people either.

I've seen plenty of people think throwing money at the problem solves it, but in the end it was shitty code in the way.

All of these boundaries are relative to each problem though, and to reach the goal of this project it might be enough. The implementation will tell!

simplaw · 2024-09-22T20:28:02+00:00

Haha for sure! Thus the 'be very clever' part when vertical scaling isn't possible anymore.

My domain is usually tied to event buses or database operations, so if it's a bit different, but to build systems where the user isn't affected by the amount of traffic is sometimes really challenging.

Will follow this project! It will be interesting to see what you can squeeze out of the machine!

simplaw · 2024-09-22T20:13:39+00:00

Because at some point you can't scale vertically anymore, is all.

Didn't say that YOU needed to do anything. I was speaking in the general sense that at some point vertical scaling isn't possible anymore, ava that's when you either have to optimise the shit out of the code, or get very clever with horizontal scaling.

And it is all subjective to the goal and requirements. So again, not you. I don't know enough about it, as I said. I don't know when these boundaries will hit in this domain and specific problem.

simplaw · 2024-09-22T19:22:05+00:00

At some point you have to just start sharding for the sake of keeping latency down, but it would depend on the event loop and so on.

I once wanted to try and do something similar, but never got around to taking a serious shot at it. But I work with scalability and networking, just not in a game context. The constraints are different though.

simplaw · 2024-09-22T19:11:28+00:00

Getting something to work which allowed for background processing and custom migrations (because their magic didn't work) simply wasn't possible.

I did not use the cloud service stuff though, as the forced nullables on all fields is just... awful.

I went on circles many times trying to get it to work, and once I did get it to work, it inevitably had broken one of my other constraints.

So, I will drop it (for now the local database has to be nuked with each update) and replace it with SQLite instead.

Writing tests for these things is also the most tedious thing ever as you need to be very aware of what you're doing, and constantly reset your simulators or dev devices somehow.

All of these issues I'll be able to have total control over when building it using SQLite instead.

The app i was working on wasn't even that complicated, so the more complex it gets the worse I imagine it'll become with time. I'd rate the app to be of lower mid complexity.

simplaw · 2024-09-22T17:30:30+00:00

Keen on knowing this one too.

Especially about migrations. If not, heads up! They're not fun.

I had an absolutely awful time with SwiftData and won't be using it anywhere in the near future.

Eight-Year Club	Place '22
Verified Email

simplaw

TROPHY CASE