WTF Bites
-
I don’t book my food 3 months in advance.
I bet most people just add an expensive bottle of booze or similar to hit the minimum and actually add what they want closer to Christmas.
edit: also plenty of people book slots early and cancel them close to Christmas so it's usually easy enough to deal with it at a more appropriate time.
-
Trying to inspect a string in the Chrome dev tools to see if it matches the spec.
It
helpfully inserts an ellipsis in the middle of the string and omits half the characters I am trying to check.
-
@error If you're looking for full equality, throw a (cryptographic) hash against it.
-
@PleegWat That just tells you a boolean result in the end, not where or how values differ, despite those both being often quite interesting. (For just an equality test, simple equality would be the first guess.)
For actual longer strings, the best approaches tend to be to compute a diff on the token sequences, where "token" depends on the text in question. (Sometimes it's characters, sometimes words in some sense, sometimes larger units.)
-
@dkf The hash trick is nice if your strings are in different places and you're trying to visually check for equality. And, indeed, it breaks down completely on further inspection.
It's also handy for "This file on server A should be equal to one of these seven files on server B, and I want to know which"
-
@Tsaukpaetra It actually does make sense to me. For a domain-joined company-owned device the recovery key is stored somewhere in the domain and they don't want a recovery password to exist so that they can remotely lock the device (in case it is stolen, but also in case you go rogue) and it cannot be unlocked except by bringing it back to the company.
Except in this case there's no way to get Bitlocker enabled whatsoever. Like, literally, cannot enable bar none.
I'd accept an auto-generated key that gets put into the Directory. This won't allow it.
I'd accept a local key stored on the bitlocker'd OS drive. This won't allow it.Stupid thing is, if I enable Bitlocker on it via an un-stupified machine and then move it over, all is good! No problems.
But enabling it straight-up? Nah, gonna have to stop you right there fam.
-
Trying to inspect a string in the Chrome dev tools to see if it matches the spec.
It
helpfully inserts an ellipsis in the middle of the string and omits half the characters I am trying to check.Like, in the console?
-
@Tsaukpaetra It was a URL if that matters.
-
Microsoft fucked up the ribbon in Office just to throw in stupid Teams crap. Now it only uses 2/3rds of the screen and 1/3rd is wasted. Fuck that.
Where's your god now, Blakey?!
-
Microsoft fucked up the ribbon in Office just to throw in stupid Teams crap. Now it only uses 2/3rds of the screen and 1/3rd is wasted. Fuck that.
The junk they add to Visual Studio is bad enough. Yuck.
Anyway, something something Office 2003.
-
Microsoft fucked up the ribbon in Office just to throw in stupid Teams crap. Now it only uses 2/3rds of the screen and 1/3rd is wasted. Fuck that.
Where's your god now, Blakey?!
Off farming in Farm Simulator, no doubt.
-
Microsoft fucked up the ribbon in Office just to throw in stupid Teams crap. Now it only uses 2/3rds of the screen and 1/3rd is wasted. Fuck that.
Where's your god now, Blakey?!
Hmm...for me they float up there on the same level as the
menuribbon section selectors. And if you shrink the window eventually the text (which is a lot shorter in English, of course) goes away and it's just the icons. And they don't seem to cut off or limit the ribbon content in any way.tl;dr Missed it by
-
@boomzilla said in WTF Bites:
Microsoft fucked up the ribbon in Office just to throw in stupid Teams crap. Now it only uses 2/3rds of the screen and 1/3rd is wasted. Fuck that.
Where's your god now, Blakey?!
Hmm...for me they float up there on the same level as the
menuribbon section selectors.They are the same level as the ribbon selectors. That's a tab where the icons don't go any further than Macro irregardless.
edit:
-
The hash trick is nice if your strings are in different places and you're trying to visually check for equality.
The win there comes from not having to move the data to do the comparison. That's an important thing in some cases, yes. Doesn't sound like this is one of those cases.
-
AEM documentation keeps talking about "POJOs" and showing code full of business logic.
-
@error Particularly Obnoxious Java Objects?
-
@error I take it you're not talking about something simple used in validation like "exactly one of these three properties must be non-
null"?
-
@error Particularly Obnoxious Java Objects?
That's all of them. I hate this language.
-
-
@error I take it you're not talking about something simple used in validation like "exactly one of these three properties must be non-
null"?That in particular would disqualify it as POJO.
-
The
WCMUsePojoabstract base class thatPOJOs derive from is 242 SLOC.
-
The
WCMUsePojoabstract base class thatPOJOs derive from is 242 SLOC.What does the "S" mean again? I always forget (assuming I'm correct in remembering the last three as "Lines Of Code").
-
The
WCMUsePojoabstract base class thatPOJOs derive from is 242 SLOC.What does the "S" mean again? I always forget (assuming I'm correct in remembering the last three as "Lines Of Code").
-
@Medinoc "Significant", as in not whitespace or punctuation.
-
@TwelveBaud But what if I am writing Python?
-
@TwelveBaud But what if I am writing Python?
You're not doing anything significant.
-
@error I take it you're not talking about something simple used in validation like "exactly one of these three properties must be non-
null"?That in particular would disqualify it as POJO.
Would putting an annotation on a getter also disqualify that object?
I was specifically talking about a method like this:
private boolean isJustOneSet() { return (a == null ? 0 : 1) + (b == null ? 0 : 1) + (c == null ? 0 : 1) == 1; }Annotate that property getter with
@AssertTrueand you have a useful piece of validation. If you are going to go "but that isn't a POJO!!!" then you end up needing a whole lot more work to validate user input, work that it is easy to forget to do in some cases. Punting things to the validation framework is very easy by comparison, but default validators can't handle "pick exactly one configuration" without assistance.Or you could do a whole custom validator for that specific POJO. That gets real old. (I have such things... but just for cases where using the standard validators would be awful, such as IPv4 dotted quad addresses. You can use a regular expression for that, but that's nasty.)
-
@error Particularly Obnoxious Java Objects?
That's all of them. I hate this language.
I take it you never owned one of these, then?
https://www.youtube.com/watch?v=yxV_pR1ZsXM
Or perhaps you did, and it shaped your attitude towards the language?
-
@error I take it you're not talking about something simple used in validation like "exactly one of these three properties must be non-
null"?That in particular would disqualify it as POJO.
Would putting an annotation on a getter also disqualify that object?
Does the annotation change how the getter works? If so, then it's not POJO. By definition.
Annotate that property getter with
@AssertTrueand you have a useful piece of validation.And you cannot arbitrarily set any combination of the fields to any combination of values anymore. If there are any constraints whatsoever, it's not POJO. And it looks like it's completely intentional. You have designed your class to be non-POJO right off the bat. You never wanted it to be POJO. So why do you even argue it should count as POJO?
If you are going to go "but that isn't a POJO!!!" then you end up needing a whole lot more work to validate user input
How about not using POJOs where non-POJOs are better? POJOs have their place. Automatic validation isn't one of them, almost by definition.
-
AEM documentation keeps talking about "POJOs" and showing code full of business logic.
I don’t think your day rate is high enough. You’re going to need therapy for the rest of your life.
-
They just emailed me to tell me that they’re staggering Christmas shopping slots and that I get to pick/reserve mine next week.
And I thought it's still Halloween season...
-
AEM documentation keeps talking about "POJOs" and showing code full of business logic.
Are you mixing up POJOs and VOs? POJOs are any objects that don't extend framework classes, don't implement complex framework interfaces and don't have complex annotations (Serializable is tolerated, you need that all over the place). But they can have complex logic. VOs are POJOs (almost always with Serializable) that don't contain logic, just hold data.
-
The
WCMUsePojoabstract base class thatPOJOs derive from is 242 SLOC.Yeah, having a standard abstract base class is the thing that does disqualify them from being POJOs.
-
AEM documentation keeps talking about "POJOs" and showing code full of business logic.
Are you mixing up POJOs and VOs? POJOs are any objects that don't extend framework classes, don't implement complex framework interfaces and don't have complex annotations (Serializable is tolerated, you need that all over the place). But they can have complex logic. VOs are POJOs (almost always with Serializable) that don't contain logic, just hold data.
He’s working with Adobe. They have very liberial interpretations of very many standard technical terms. Including what developer support and documentation means.
-
@error I take it you're not talking about something simple used in validation like "exactly one of these three properties must be non-
null"?That in particular would disqualify it as POJO.
Would putting an annotation on a getter also disqualify that object?
Does the annotation change how the getter works? If so, then it's not POJO. By definition.
Annotate that property getter with
@AssertTrueand you have a useful piece of validation.And you cannot arbitrarily set any combination of the fields to any combination of values anymore. If there are any constraints whatsoever, it's not POJO. And it looks like it's completely intentional. You have designed your class to be non-POJO right off the bat. You never wanted it to be POJO. So why do you even argue it should count as POJO?
If you are going to go "but that isn't a POJO!!!" then you end up needing a whole lot more work to validate user input
How about not using POJOs where non-POJOs are better? POJOs have their place. Automatic validation isn't one of them, almost by definition.
But I think of it as a POJO. It really is just a bag of fields and getters (setting is only via constructor) and doesn't inherit from anything. It just happens to have some annotations on some of the getters to:
- encourage the JSON deserializer to map documents from the user correctly, and
- tell the validation framework what constitutes a valid object from the perspective of the application, and
- tell one of the static checkers I use to not get snippy.
All of these observe the code, but don't modify it. I'm not one of those filthy Lombok users, so what you see is what you get. (The migration of the code to Java 17 — stalled for messy deployment reasons beyond my control that don't matter here — changes many of these things to
records.)The application totally could make invalid objects if it wanted. It doesn't want to.
-
So...
is a POJO supposed to be how the Java crowd calls POD types?
-
@Medinoc Pretty much, but with slightly different rules. The main point is that you don't have to understand the internals of them when working with them; they're just named bags of properties that don't change if you don't poke at them (via setters).
-
So...
is a POJO supposed to be how the Java crowd calls POD types?No. VOs are how Java crowd calls POD types.
@Medinoc Pretty much, but with slightly different rules. The main point is that you don't have to understand the internals of them when working with them; they're just named bags of properties that don't change if you don't poke at them (via setters).
No, that's VOs.
For POJOs the thing you don't have to understand is any framework (like JEE or OSGi), just the language. But the logic in them can still be arbitrarily complex.
-
Value Objects aren't supposed to be pokable. Their (visible) contents are supposed to be immutable; the closest thing to changing the content of a VO is to create a new object with the change already in place. They don't have setters.
They can have whatever functionality you like as long as it's read-only and doesn't change any state (which generally means querying that state, and constructing new VOs based on an existing one, both of which can be quite involved). Making the same query on a given VO should always produce the same result no matter what has happened in the meantime.
I guess the classical example would be an Immutable Date object: you can ask it for properties of the date (year, month, day day of the week, Julian Day, ISO week number...); getting the date five days or two months or one week hence involves constructing a new object to represent it.
-
@Watson Hm, you are right. So what then is the name for “data only” objects? It definitely is not POJO.
-
@Watson Hm, you are right. So what then is the name for “data only” objects? It definitely is not POJO.
DTO I guess?
POJOs aren't really well defined apart from "no framework shenanigans".
Though, maybe JavaBean is the correct one? But EE went hog wild with Beans so that'd be confusing.
-
Though, maybe JavaBean is the correct one?
No, because Swing Components are JavaBeans and very much not just data only things.
There's an actual spec for what is a JavaBean, which covers a whole load of stuff for properties including observability callbacks and even the ability to veto changes. An abbreviated form is often used where there are just getters and/or setters that follow a naming convention, but that's absolutely not the whole thing.
If you're really leaning into data-only objects, use records. Those have no hidden state and are immutable. You also get a bunch of basic methods generated for you, and are generally very convenient for that whole class of uses. But aren't beans (by default; you need to add the getters yourself) so some older systems (notably JSTL) get really snotty about them.
-
I always thought POJOs are supposed to be functionally equivalent to C++'s PODs. But I guess it's not so.
-
@Watson Hm, you are right. So what then is the name for “data only” objects? It definitely is not POJO.
DTO I guess?
Without the transfer part.
POJOs aren't really well defined apart from "no framework shenanigans".
"no framework shenanigans" is a good enough definition for me. And useful one: the point is telling people not to pull framework shenanigans into code that does not need them to keep it easier to understand.
If you're really leaning into data-only objects, use records. Those have no hidden state and are immutable
Which makes them value objects.
And it is generally a good idea to indeed make all your objects that just carry data immutable, because once you start sharing them around, something mutating them will wreak serious havoc into the logic that will be difficult to debug. But not all data objects are immutable. Even standard language objects like Date, which really, really should be.
technically just shallow-immutable; there's no enforcement of whether the contents are themselves immutable because that's a deep semantic rabbit hole to fall down
They should only contain members that are also immutable, so then shallow immutability does imply deep immutability.
-
@Watson Hm, you are right. So what then is the name for “data only” objects? It definitely is not POJO.
DTO I guess?
Without the transfer part.
I mean, if you need the data in an object, and it shouldn't have logic, you are technically gonna transfer the data around, or you wouldn't be putting the data in an object to begin with.
POJOs aren't really well defined apart from "no framework shenanigans".
"no framework shenanigans" is a good enough definition for me. And useful one: the point is telling people not to pull framework shenanigans into code that does not need them to keep it easier to understand.
No argument from me against that, I like simple code without hidden shenanigans.
-
This POJO vs VO vs etc gives me strong @blakeyrat urges.
-
Even standard language objects like Date, which really, really should be.
I can find solutions for that in an Instant.
-
@dkf Yeah, fortunately someone realized it was bad design and created a better replacement. In languages like C++, C# or Rust datetime is a by-value type (unlike Java, C# has those, even though somewhat limited), so it is referentially transparent even without being immutable, and Python got that one right.
-
-
@Bulb I come from a background where every value is referentially transparent and observably immutable.
Source lines of code - Wikipedia
?