Lysergid

joined 1 year ago
[–] Lysergid@lemmy.ml 2 points 6 days ago

Though in reality, management will push back any unorthodox approaches/solutions/approaches as risk and additional losses on R&D.

[–] Lysergid@lemmy.ml 1 points 1 week ago

‘’’ Note: When I say “top-level” I am talking about the URL that you see in the address bar. So if you load fun-games.example in your URL bar and it makes a request to your-bank.example then fun-games.example is the top-level site. ‘’’ Meaning explicit creds won’t be sent. Even if fun-games knows how to send explicit creds, it can’t because fun-games does not have access to creds which stored for your-bank. Say suppose your-bank creds stored in local store. Since current URL is fun-games it can only access local storage of fun-games, not your-bank.

[–] Lysergid@lemmy.ml -2 points 1 week ago

Thank you! I was always wondering why the heck this (mostly) useless and broken mechanism exists. I had hesitations about disabling it but had doubts about my understanding. Now I know I’m right

[–] Lysergid@lemmy.ml 1 points 1 week ago

“Stateless” is not what “I” want, it is part of definition of REST.

Can do != what spec says you should do. You can also send clown version from the post but don’t be surprised people will find it… funny

Again, I’m not telling you are doing wrong. I’m telling you are mixing REST and RESTful web services

[–] Lysergid@lemmy.ml -2 points 1 week ago* (last edited 1 week ago) (4 children)

REST calls are same as in 2001. There is no REST 2.0 or REST 2024. Because REST is architecture guideline. It’s just more data sent over it today. HTTP code IS code. Why your system issued it is implementation detail and have nothing to do with resource representation. Examples you provided are not 403. “Too many users active” does not exist in REST because REST is stateless, closest you can get is “too many requests” - 429. Insufficient permissions is 401. I don’t even know what is “blocked by security” but sounds like 401 too. Regardless, you should not provide any details on 401 or 403 to client as it is security concern. No serious app will tell you “password is wrong” or “user does not exist”. Maximum what client should hope for is input validation errors in 400.

For those with “internal tool, I don’t care” argument - you either do not know what security in depth is or you don’t have 403 or 401 scenario in the system in the first place.

Now hear me out, you all can do whatever you want or need with your API. Have state, respond with images instead of error codes, whatever, but calling it REST is wrong by definition

[–] Lysergid@lemmy.ml 15 points 2 weeks ago

Imagine how much more common this positive vibe would be if people wouldn’t need to spend at least 1/3 of their life trying to meet ends in competitive environment

[–] Lysergid@lemmy.ml 3 points 2 weeks ago* (last edited 2 weeks ago)

At least they are not a tee pot

[–] Lysergid@lemmy.ml 2 points 2 weeks ago (1 children)

Why sit there 5 mins? This looks like normal city bus stop. Bus arrives at scheduled time, picks up passengers and takes off. I believe great ‘merica supper power nation can manage what Eastern Europe nations made happen years ago. Yes you may have few mins delays but it’s not a disaster.

If for whatever reason it must sit there for long time bust stop should be in a bay

[–] Lysergid@lemmy.ml 3 points 2 weeks ago (3 children)

I believe car drivers are capable of waiting 15 seconds while vehicle which most likely transports multiple times more passengers dropping/picking those passengers. Car drivers wait hours in traffic jams for themselves, can wait a bit for bunch of people in a bus

[–] Lysergid@lemmy.ml 4 points 2 weeks ago (4 children)

Crossings should be safe for humans and bikes. Meaning, they should be short and bikes should not be ridden across intersections if no bike lane

[–] Lysergid@lemmy.ml 23 points 2 weeks ago (17 children)

Better explain why pedestrian crossings are stretched so much instead of being on shortest trajectory to other side

[–] Lysergid@lemmy.ml 7 points 3 weeks ago

Do you have to unlock? You can open wallet from blocked screen without unlocking phone

1
submitted 2 months ago* (last edited 2 months ago) by Lysergid@lemmy.ml to c/programming@beehaw.org
 

Hello my fellow, lemons? I have this problem in my current project I’m out of clue how to approach it. Maybe someone had similar experience and can give an advice.

Our requirements captured in JIRA. Throughout years we accumulated thousands of user stories. Say suppose following naive requirements team knows about:

  • Day 1: create home page
  • Day 20: create profile page
  • Day 50: add green footer to all pages
  • Day 100: create admin page Day 150: change footer color to blue

Now I’m doing refactoring (yes, I know, this is the actual problem) on day 400 and noticed that footer on profile page having green footer. Because requirements are just set of individual statements not consolidated with all history of system no one on the team knows why is that, is it bug or requirement did change on day 300 but we cant find it now.

When I worked in Waterfall we had BRD and FRD stating current actual desired state of system which was “reduced” from individual requirements which were coming in throughout project life. When in doubt devs can check FRD and not only know how system expected to behave but also which are other parts of the system that will be affected. How is it in Agile? To my understanding FRD is not a thing in Agile. Do I need to scan through hundreds of tickets and hope I didn’t miss anything every time i’m doing any non-trivial change to system?

 
view more: next ›