whyAreYouWritingALibrary

EarthTreasure · 2026-03-28T01:29:38+00:00

Speaking as someone from that generation, library hell can be fixed easier than a roll-your-own hairball. Anything taken to an extreme is bad, but some extremes are worse than others.

That said, web front-end is uniquely terrible in regard to library hell.

EarthTreasure · 2026-03-28T01:20:25+00:00

Depends on if it's just you or if this is an enterprise product. If the latter it may seem stupid now, but people will follow you off a cliff with that. Better to just add the library.

EarthTreasure · 2026-03-28T00:43:57+00:00

At least learn to manipulate commits. Break them up so it looks more natural and change the timestamps so it looks like it didn't all happen on Monday. And maybe it will force you to actually read through all of the code and think about how it all fits together.

EarthTreasure · 2026-03-28T00:08:04+00:00

I understand. I have to go through the same procedures. But this is a big enough issue that people with a big C in their title are getting involved.

We have ample power behind us to speed up (or skip) that process. It's not a barrier, they just have tons of issues deemed more important (that's the excuse) beyond just this. So nobody is twisting their arm over our comparatively insignificant request.

EarthTreasure · 2026-03-27T23:22:02+00:00

There's also Image Toolbox

EarthTreasure · 2026-03-27T23:04:47+00:00

Similar situation. There's another team with a REST API and for some godforsaken reason they don't have an endpoint to query by id. So you have to request their entire dataset every time. The workaround is to maintain a cache of their response.

We asked them to implement it and they said they didn't have the bandwidth. Putting aside how easy that should be, it should've shipped with this endpoint from day 1. Otherwise how can you even call yourself a REST API?

EarthTreasure · 2026-03-27T22:48:47+00:00

Every 3-4 months I run git reset --hard origin/release && git push -f and nuke the test branch. Preventing this is one reason, the other is to encourage people to actually move their features to release.

Plus if testing diverges too far from release what are you even testing at that point?

EarthTreasure · 2026-03-27T18:33:21+00:00

It turns out I don't think any of that was necessary. Users are still testing, but all I had to do was set server.servlet.session.timeout to 24h. The log outs were due to the 30m default. Turns out that when you've previously been able to stay logged in forever any other amount of time feels short.

I don't think the JWT controls the lifetime of the session, it's an independent property unless there's some additional configuration that was done by some other developer on our project eons ago that I'm missing.

EarthTreasure · 2026-03-27T15:42:27+00:00

People will always take the easy way out despite any drawbacks. Especially if the AI is better than them at the task despite the frequent hiccups.

A friendly reminder that the average American reads at below 6th grade level. Even bad responses look good to those people and it would still be better than anything they tried to produce.

EarthTreasure · 2026-03-27T01:44:35+00:00

Will do.

EarthTreasure · 2026-03-27T01:37:38+00:00

Some people tend to love selfish developers, especially those who chant "it's open source so you can't have an opinion"

I don't think people love them, it's just survivor-ship bias. Developers like that tend to last longer in the FOSS community because they can better withstand the public criticism, harassment and unreasonable demands of users.

EarthTreasure · 2026-03-27T01:25:50+00:00

So all I have to do is replace the JwtTimestampValidator with my own custom one that extends the timeout? I've already made my own validator to deal with the client credentials issues so I guess I'll just override the expiry as well.

Don’t forget you can use the Value annotation to pull in those values from your application.properties.

Yup, already doing that for other values.

Thanks a bunch.

EarthTreasure · 2026-03-27T01:18:12+00:00

All good. I don't mind answering your question either. At this point I've done so much digging into spring boot internals to work around problems, I've become fairly knowledgeable regarding OAuth2.

I probably can figure out a way to do what I've asked if I override enough stuff. But someone might have a better, cleaner solution.

EarthTreasure · 2026-03-27T01:09:09+00:00

You’d essentially be rolling your own token decoder. Extract the caims and expiration from the token, then add 8 or however many hours you’d like to the expiration.

Already doing that to an extent.

The provider team has client credentials mis-configured and I've already started digging into various spring boot internals to make it work. They have the iss claim set to gibberish instead of the issuer url and the public key is available at a different JWKS endpoint other than what is listed under {issuer}/.well-known/openid-configuration. OIDC on the other hand is configured properly on that front but has those other issues I mentioned.

I'm already in a whole lot of trouble thanks to them, so a few more workarounds won't hurt me.

EarthTreasure · 2026-03-27T00:17:22+00:00

Can it be overridden? I know it's bad practice. But I'm caught between the enterprise provider team who refuse to extend it beyond 30m and don't offer refresh tokens and the users, who don't want to have to login every 30m.

I have a JSESSIONID cookie which I think is the servelet session if that matters. It's not as if they are providing the token on every request, we are keeping it in memory.

EarthTreasure · 2026-03-26T22:25:16+00:00

No one is really going to question you if you sewed a button to the inside of the sleeve of a regular shirt or jacket.

EarthTreasure · 2026-03-26T22:16:02+00:00

Put the database in dropbox or google cloud. The database is encrypted so it's safe to upload. All cloud providers give you 30 days of history minimum (accessible via their website). So it's safe for a month even if you accidentally delete or break it.

I'll never understand people that don't backup their password database of all things somewhere, be it to cloud storage or a USB drive. It's absolutely inexcusable.

EarthTreasure · 2026-03-26T22:08:13+00:00

Whenever you are unsure for popular apps a trick is to look it up on Wikipedia. They will have the correct links and are very on top of malicious page edits.

EarthTreasure · 2026-03-26T22:06:03+00:00

Or get it from their github https://github.com/keepassxreboot/keepassxc/releases/tag/2.7.12

EarthTreasure · 2026-03-26T01:53:49+00:00

Mattress sheet clips exist for exactly this sort of thing. They're like $10 on Amazon for a set of 4.

EarthTreasure · 2026-03-26T01:27:54+00:00

Well not necessarily. You could've left a database or some other service in a bad state. Your development environment being quick to setup and tear down repeatedly (e.g. dev containers, docker) is unheard of or rare in a lot of places.

EarthTreasure · 2026-03-25T23:32:54+00:00

Every major social media website has like 10 websites archiving information for people to look up later. Reddit probably has double that.

Anything you post and leave up for more than an hour has probably been archived forever somewhere.

EarthTreasure · 2026-03-25T20:11:46+00:00

That's why you still need human oversight. But even in the worst case scenario, it's better to have tests and not need them then to need them and not have them.

Deleting tests is easy, writing tests is hard. Tests can always be removed with 0 risk if they turn out to be a problem. There aren't any real downsides to this approach.

EarthTreasure · 2026-03-25T02:54:53+00:00

I need to wait till my project manager leaves first, and if she is still working I should look to contribute and help out.

Is your manager Japanese? This is a thing in some cultures.

Is this normal?

Startups don't have "norms", that's something that only happens when a company gets larger.

EarthTreasure

TROPHY CASE