sleeplessone

joined 1 year ago
[–] sleeplessone@lemmy.ml 13 points 1 month ago

Preemptively blowing up a fertility clinic as a last resort.

[–] sleeplessone@lemmy.ml 8 points 1 month ago

Based if true.

[–] sleeplessone@lemmy.ml 11 points 1 month ago (2 children)

But the real savings? Repetitive code. I suck at it, I always make typos and it’s draining.

It's hard to say without being immersed in the codebase you work on, but wouldn't making your code DRY (when possible) take care of a lot of the repetition without needing to write a bunch of incredibly similar code (be it by hand or with an LLM)?

[–] sleeplessone@lemmy.ml 2 points 1 month ago

Take a drink ~~for every f-35 that gets destroyed. And take a drink for every f-35 that isn’t!~~

Heggy's way ahead of you.

[–] sleeplessone@lemmy.ml 7 points 1 month ago (1 children)

Hardly a centrist position.

Looks like run of the mill centrism to me.

[–] sleeplessone@lemmy.ml 8 points 1 month ago

They're a youtube channel run by a pair of leftist Australian rascals. They even have a video where they try to enter a CIA base in Australia.

[–] sleeplessone@lemmy.ml 9 points 1 month ago (1 children)

MDN offers webdev tutorials. While I've never tried their tutorials out, the MDN docs are really good and they're my go to when I need to figure out how a specific brower-side API works.

[–] sleeplessone@lemmy.ml 24 points 1 month ago

Militarily driving out the French and Burger imperialists was a prerequisite for their governmental success. After all, if they hadn't done that, they wouldn't be governing themselves in the first place.

[–] sleeplessone@lemmy.ml 8 points 1 month ago

My only complaint is that the Baltics aren't included in the Shut The Fuck Up Zone.

 
 

A story from my day job. I submitted it to the Daily WTF. Fingers crossed that they'll accept it.


In order to facilitate development of frontend apps that rely on my employer's antediluvian monolith codebase, a team of developers at the company came up with a backend for frontend (BFF) service that would allow developers on other teams (such as mine) to quickly make frontends that use the monolith's logic and data. The service uses a schema-driven UI approach, where developers make forms by specifying the input elements (along with some related layout and validation logic, also schema-driven) using JSON schemas. This also includes specifying classes on the element for styling purposes. Who wants hot reloading when tweaking styles for a frontend app when you can instead make a JSON schema in a separate DotNET codebase that needs to be compiled (this is sarcasm)? As gross as that aspect is though, it is not today's WTF.

Right after lunchtime today, I saw a post from one of my colleagues in the team's Teams channel saying (verbatim) "I am gonna take off this afternoon. The BFF has fried my brain and I need to unwind a bit." Curious to see what he was talking about, I went to the company's BitBucket to review the PR he just made. While looking through the schema he made, I saw a strange validator he had to use:

{
    "type": "eventValueBetweenValuesValidator",
    "eventType": "CalendarYear",
    "minValue": 1900,
    "maxValue": 99,
    "isCalendarBasedMaxValue": true,
    "message": "CalendarYear must be between {% raw %}{{minValue}}{% endraw %} and {% raw %}{{maxValue}}{% endraw %}."
}

When I was reviewing the PR, I thought this was a bug. The max value is obviously lower than the min value. A closer look at the schema seems to support this idea:

  • The value for the type field implies that the value for the input must be between 2 different values, presumably minValue and maxValue

  • The eventType field value, "CalendarYear", implies that the accepted value must be, well, a calendar year

  • isCalendarBasedMaxValue being set to true suggests that maxValue should be a calendar based value (and none of our customers were born nigh 2 millennia ago)

  • The message would produce the patently absurd "CalendarYear must be between 1900 and 99."

Considering all of this, surely setting maxValue to 99 must be a bug in the validation logic. It certainly is for the logic that produces the error message. However, upon asking my teammate who paired with the dev that opened the PR, I learned that the max value is actually the number of years in the future relative to the current year. What the schema is actually saying is that valid values for the year selected must be between 1900 and 2124 (99 years after the time of this writing).

This is its correct usage. This is not a bug. It was designed to be this way. It was at that moment that my mind also melted.

I couldn't come up with something more counterintuitive if I tried.

 

You have been visited by the catfish of good fortune. Many upvotes and new users will be bestowed upon you, but only if you reply "happy fedding" to her message.

 
 
 
 
view more: ‹ prev next ›