*casually clicking through aws services*

*discoveres ses (email service)*

*tries it out as email driver in laravel project*

*discoveres you are in sandbox by default, means you can only send emails to yourself*

*reads documentation, says to get out of sandbox request a limit increase with default values*

// 200 per day, max 1 per second

*request what is mentioned*

*while waiting, find threads of people with the most well documented use case requests getting denied*

*pretty sure i will be denied to, thinking of starting to look elsewhere*

// next morning

*opens mail*

# your application is now out of sandbox and can now send 50k emails a day with a max of 14 per second.

Well, shit... I may have just shot myself in the foot. 🤔

5 years worth of asking my boss to get a Mac development machine for me, thereby allowing me to better create and maintain the hybrid mobile apps I've been building for him for years...

I finally got a definitive "yes, we'll do that" about 2 or 3 weeks back.

Now, running into stupid startup crashes on the aging iPad (6th gen) that I have for testing, I asked if I can just get a "Mac in cloud" subscription IN THE MEANTIME, you know, to help me meet deadlines...

His response: "Ah, yes.. that's a nice elegant solution, now you don't need a Mac! Well done."

F.. M.. L..

Admin Access

Have you ever been in a position where you become the de-facto person who works with a certain tool, but are denied full admin access to that tool for no real reason?

Two years ago I was put on the Observability squad and quickly discovered it was my thing, implementing tracking and running queries on this third-party tool, building custom stuff to monitor our client-side successes and failures.

About a year ago I hit the point where if you asked anyone "Who is the go-to person for help/questions/queries/etc. for this tool", the answer was just me lol. It was nice to have that solid and clear role, but a year later, that's still the case, and I'm still not an admin on this platform. I've asked, in an extremely professional way armed with some pretty good reasons, but every time I'm given some lame non-answer that amounts to No.

As far as I'm aware, I'm the only dev on our team at all who uses custom/beta features on this site, but every time I want to use them I have to go find an admin and ask for an individual permission. Every time. At the end of 2020 it was happening once a month and it was so demoralizing hitting up people who never even log into this site to ask them to go out of their way to give me a new single permission.

People reach out to me frequently to request things I don't have the permissions to do, assuming I'm one of the 64 admins, but I have to DM someone else to actually do the thing.

At this point it feels very much like having to tug on the sleeve of a person taller than me to get what I need, and I'm out of ways to convince myself this isn't demoralizing. I know this is a pretty common thing in large companies, meaningless permissions protocols, and maybe it's because I came from IT originally that it's especially irritating. In IT you have admin access to everything and somehow nobody gets hurt lol-- It still blows my mind that software devs who make significantly more money and are considered "higher up" the chain (which i think is dumb btw) are given less trust when it comes to permissions.

Has anyone figured out a trick that works to convince someone to grant you access when you're getting stonewalled? Or maybe a story of this happening to you to distract me from my frustration?

So sometime back I was working as an android developer for a startup managed by a guy who wasn't much of a techie. The team wanted a share image to facebook option in the app, which required FB SDK integration into the app, which in turn will increase the app size and request more permissions. On discussing this with them and asking for the app secrets, they said that I'm being ridiculous, and denied me from giving the app secrets, citing the reason 'They're called secrets for a reason'.

Here's a real tip for people new to the industry.

It's one of those things that's been said over and over again but very few can really seem to employ. I suggest you learn it /well/.

You are not your code. Criticisms of your code, ideas, or your thought processes, is not a criticism of YOU. You absolutely cannot take criticisms of your work personally.

We are engineers. We strive to seek the best solution at all times.

If someone has found a problem with your code or with an idea or whatnot, it is coming from a place of "this is not the best solution", NOT "you're an idiot".

It's coming from a place of "I'm closing this PR because it is not a change I feel suits this project", NOT "I'm closing this PR because it's coming from a woman".

It's coming from a place of "This feature request is ridiculous/this bug is not actually a bug", NOT "you're a fucking idiot, fuck you".

It's coming from a place of "I've already had to address this in a number of issues before and it's eaten up a considerable amount of my time already", NOT "I don't even know you and this I don't have time for a nobody".

You do not get to be bitchy to maintainers because they denied your request. It's not a reflection of you at all. But if you're arguing with someone who has maintained a piece of code for almost a decade, and they're telling you something authoritative, believe them. They're probably smarter than you on this subject. They've probably thought about it more. They've probably seen their code used in many different places. They have more experience than you with that codebase in almost all cases.

Believe me, if we cared about who was behind all of the issues, pull requests, etc. we get, we'd get NOTHING done. Stop taking shit personally. It's a skill, not a defense mechanism. Nobody has the time to sugar coat every little thing.

Let's normalize directness and stop wasting time during technical discussions into opportunities for ego-stroking and circle-jerking and back-patting.

I know folks do their best, but come on Apple, this can't be that hard. Bought an IPhone at an estate sale (elderly individual died suddenly, so no one had knowledge of the apple id, passwords, etc) and I've been trying to convince apple to clear the activation lock. (AS = Apple Support)

<after explaining the situation>
AS: "Have you tried putting the phone in recovery mode? That should clear the lock"
Me: "I've already done that. It prompts for the apple id and password, which I don't have"
AS: "You need to talk to the owner and get the information"
Me: "As I explained, I purchased the phone at an estate sale of someone who died. I have the bill of sale, serial number, the box, obituary. What else do you need?"
AS: "Have you tried contacting a family member? They might have have that information."
Me: "The family members at the sale told us this is all they had. This kind of thing has to happen. I can't believe Apple can't clear the activation lock."
AS: "Yes, we can, but I'm very sorry we take security seriously."
Me: "I understand, what do I do now?"
AS: "Did you log out of the phone? Go to settings ..."
Me: "Yes, I tried all those steps before calling. It prompts for the AppleID and password."
AS: "Did you try entering the password?"
Me: "No, I don't have it. I already explained there is no way to know"
AS: "Yes..yes...sorry...I'm just reading the information in front of me. I found something, have you tried submitting a activation lock removal request?"
Me: "Yes, it was denied, didn't tell me why, which is why I'm calling. What about taking this phone to an Apple store? I have all the paperwork."
AS: "Sure, you can try. You might need the death certificate. The family or the coroner will have a copy."
Me: "What!? Apple requires a death certificate to unlock a phone!? I'm pretty sure not even the family is going to give a total stranger a death certificate"
AS: "Sorry sir, I'm just reading what is in front of me. Without that certificate, there is no way to prove the person died. You can try the Apple store, but they will likely require it."
Me: "That's a lot of drama for unlocking a phone. A *phone*"
AS: "Yes sir, I understand. If there anything else we can do let us know and thank you for being an a apple customer."

Next stop, the Apple Store.

Today I found a critical bug to our software and wrote a fix and tested it locally.

Common sense would dictate that especially when it is critical you test said fix on a real release and not with a debugger attached and running onna different device altogether.

I was denied this request because the afflicted machines engineer would not be able to finish the machine before the factory acceptence test.

I stood there with glassed over eyes for a second and then to no avail tried to explain that without this fix he wouldnt even pass the internal acceptance test......

Freaking love it when devs from other teams work on you code base and implement components you already have ... Don't talk to each other, just submit your awsome code and leave a mess behind. But OK ... Just a simple click on Pull Request -> Denied!

I work as an intern in a big company. There is a person who joined the company recently with about 6 years of experience in other big companies. He can't do simple things like adjusting his computers resolution and raised a request for a new monitor. He used to wonder why his request was denied 😐 later when I got to know this had happened, I went and fixed the resolution, he was so fascinated.. Hmm...

So I work for a VPN company as the Info Sec manager long story short I'm not usually the pleb who does customer support.

But today I ended up having to do this. I spent over 1 hour helping a client that a support agent escalated the request for to me. So I figure out that his network adapters are sharing incorrectly.
I fix problem.
He tries to connect.
Denied access so I check our servers for the request and he's blocked.
I think that's odd.....

I check active subscription and this person ISNT A CLIENT THATS ACTIVE....

WHY IS SUPPORT SO IGNORANT.
UGH.

A random story that just popped back into my head while reading another rant:

Long ago, we developed our own webmail platform at the request of clients. After it was finished, it was never updated and eventually turned into an outdated insecure steaming pile of crap. Up until ~2015, it looked like the first iteration of AOL Mail from the 1990s (and it functioned as such too.) Years, we decided to sunset the platform, and allotted 6-months or so to transition all the active users off the platform and over to an alternative email provider. We had to call each client multiple times and send multiple emails with a deadline detailing when the service would be shut down, and we'd explain that if they didn't transition over to a new service and transfer all their emails before that date, then the emails would be lost forever. Lo and behold, a handful of clients ignored our repeated contact attempts, and we shut down their email service (as we told them that we would.) Of course, they called screaming and panicking "OUR EMAIL IS DOWN OUR EMAIL IS DOWN WE'RE LOSING MONEY FIX IT NOW!!!!," and we told them "We attempted to contact you multiple times, and you neglected to return our numerous calls or emails. We're happy to help you transition your old email addresses to this new provider, but because you neglected to follow the cushy deadline we provided you, all of your emails are gone."

Of course, they denied having ever received our calls/emails, and we'd have to provide them with our outgoing call recordings to prove that we did in fact contact them multiple times. Then they'd blame the mishap on their secretary, who would blame it on the intern, who would blame it on the IT guy, who would blame it on the janitor, and so on and so forth.

Moral of the story: always keep outgoing call recordings when you're sunsetting a product.

Client: We need to support uploading doc, docx, all image formats and PDF to convert and combine everything into a PDF.
Me: lol. No.

No way in hell am I going to try to convert docx to PDF in Java.

Hm, missed a bit this pile of sociopaths here on devRant.

Last few weeks:

I repeat myself, this shouldn't be hard.

Working on it for 5 mins.

O h m y g o d.

Quite nothing the past weeks worked like intended, people and management have been a complete desaster and the weather is killing me.

Cheers.

Oh. And my request to get an benzo perfursor and a sexy manly nurse was denied by my team colleague handling hardware management.

-.- He said me being in a good mood is the last missing sign that the apocalypse is happening.

Yeah. Shit is burning everywhere. We're e.g. getting hardware delivered by a supplier who said that the request *was* canceled (after 3 months...) Two days phoning back and forth, they don't understand how it was possible but we can keep the hardware. Yay. Except that we completely redid the whole planning a week before. Naaaayy....

And now I will do the best I can: get drunk.

Cheers.

For some reason I keep over engineering stuff to the point I spend 2 hours thinking the best way to do something. I'm making the backend for a project of mine and I wanted somewhat decent error handling and useful error responses. I won't go into detail here but let's say that in any other (oo) language it would be a no-brainer to do this with OOP inheritance, but Rust does OOP by composition (and there's no way to upcast traits and downcasting is hard). I ended up wasting so much time thinking of how to do something generic enough, easily extendable and that doesn't involve any boilerplate or repeated code with no success. What I didn't realize is that my API will not be public (in the sense that the API is not the service I offer), I'm the only one who needs to figure out why I got a 400 or a 403. There's no need to return a response stating exactly which field had a wrong value or exactly what resource had it's access denied to the user. I can just look at the error code, my documentation and the request I made to infer what caused the error. If that does not work I can always take a quick look at the source code of the server to see what went wrong. So In short I ended up thrashing all the refactoring I had done and stayed with my current solution for error-handling. I have found a few places that could use some improvement, but it's nothing compared to the whole revamp I was doing of the whole thing.

This is not the first time I over engineer stuff (and probably won't be the last). I think I do it in order to be future-proof. I make my code generic enough so in case any requirements change in the future I don't have to rewrite everything, but that adds no real value to my stuff since I'm always working solo, the projects aren't super big and a rewrite wouldn't take too long. In the end I just end up wasting time, sanity and keystrokes on stuff that will just slow down my development speed further down the road without generating any benefits.

Why am I like this? Oh well, I'm just glad I figured out this wasn't necessary before putting many hours of work into it.

How my friends work day goes, I worked at the same firm and on the same project, I dont pity him.
70% debugging
25% refactoring - after his pull request was denied a few times, and had to rewrite that code in question a few time. I think most people go mad
3% test writing
2% code writing

What the fuck is CORS, I can type the URL into my browser and download the file, but running a HTTP request from within a page is denied? Wtf kind of dumb no logic behaviour is this

I love how using the windows authenticator app sometimes just ends with "denied" status despite doing everything right to approve the request because, of course. Do it again.

!rant

Got a question since I've been working with ancient web technologies for the most part.
How should you handle web request authorization in a React app + Rest API?
Should you create a custom service returning to react app what the user authenticated with a token has access to and create GUI based on that kind of single pre other components response?
Should you just create the react app with components handling the requests and render based on access granted/denied from specific requests?
Or something else altogether? The app will be huge since It's a rewrite off already existing service with 2500 entities and a lot of different access levels and object ownerships. Some pages could easily reach double digits requests if done with per object authorization so I'm not quite sure how to proceed and would prefer not to fuck it up from the get go and everyone on the team has little to no experience with seperated frontend/backend logic.