Wayland is pain.

So I dropped an FYI via slack to a colleague and they immediately replied!

How dare they! They are on vacation!

Turn off your slack, disable your notification, don't check your mails.

Your work shouldn't have any impact on how you spend your vacation. We will manage.

I don't care what codestyle you want. I even can deal with codestyle I detest. (Looking at you, Vertical Alignment)

There is pretty much only one hard requirement:

It must be enforceable via autoformatting.

I won't manually edit a file because you have a preference.

Why is my test not failing? The actual and the expected json is completely different? What the fuck!?!

It says:

static::assertJson($expected, $actual);

right there.

Oh wait.

Nevermind.

`static::assertJson` only checks for any VALID json string that I always provided in with my own expectation m)

Use `assertJsonStringEqualsJsonString` instead.

What.

Who needs meaningful defaults.

(I would claim that `assertJson` should be defaulft for string equalness, and assertValidJson should be for any Json validation. But you are free to disagree.)

That feeling when your github issue you created four years ago that generated hundreds of thumbs up is locked in the end by the maintainer without any intent of fixing it as a solution would be a breaking change.

Never mind the fact that the default was off to begin with.

I get it, it's open source and it's their tool and I should keep my sense of entitlement in check and just be thankful that they provide it.

But damn, you'd think that some sort of feedback would reach them in their ivory tower.

php's type hints are completely broken.

Why is strict mode not the default? Why does it completely break down for arrays? (You have to abuse phpdocs to get any meaningful hints but you still lose any runtime checks.) What's with union types? (I know, php8 now has them but what took you so long.)

Can you recommend a design pattern for dealing with workflows?

I am wondering how to represent a decision tree while also making it easy to maintain and each step should be unit-testable on its own.

I want to avoid a big if-else-block, but I am also unsure what design pattern to apply here.

Basically, there a bunch of yes-no-question (though some conditions may be more complex) that can be nested very deeply, and depending on a certain set of requirements we want to display different actions.

(The workflow is fixed, there is only 1 at at time yet it may change a lot over the next iterations until we figure out what our userbase wants.)

As a German developer living in Germany, I am used to write my code completely in English. In all of my former companies that was also the norm. In one company, we even talked completely in English with each other to a point where even if only German people where in a room, they would default to English at one point in a conversation because it became second nature to us.

(That company was very international and we had a lot of people from all over the world working there.)

Now, I work at a new German company that focuses on the German market. And for some reason I failed to ask them:

Do you write your code in English?

Because that's the norm, isn't it!? I just assumed it to be the case.

Nope! This time it is a mess of German and English term intermixing in glorious abysmal ways I never thought possible.

Sometimes we translate terms, sometimes we don't. So you have to wrap your mind around collections of words that COULD mean the same thing unless they don't. Best case, you have two words for the same thing, but I've seen up to five words (or abbreviations) to describe one business entity. Madness.

And don't get me started on the plurals. In English, it's almost exclusively: add an `s`.

In German, the singular and plural can be the same (e.g. all nouns ending with `-er`) so tough luck determining if you are on an object or an array of objects. (Weak typing language in use does not help either but that's an entirely different rant.)

Has anyone experience with

pre-commit/pre-commit

Is it worth checking out?

https://pre-commit.com/
https://github.com/pre-commit/...

And here I am again, reading test cases that basically boil down to:

$testCase->foo = "bar";
$this->assertEquals($testCase, "bar");

$testCase2->foo = null;
$this->assertNull($testCase2->foo);

Why would anyone feel the need to write these kind of tests? They don't do anything. If I set up my mock a certain way, of course I will have that data, esp. if the unit under test only applies the data AS IS. (Funily enough through another component that already has the relevant dummy tests in place making these tests extra redundant and obsolete.)

You would think that one test case with dummy data suffices, yet no, there are like 30 examples that lie to you about apparent business logic cases, yet in the end the way you set up the mock decides what you will or won't get.

What's the point?

So in order to ask a stackoverflow question I prepared a minimal verifiable example.

Now the issue I am facing is that my minimal verifiable example WORKS.

How am I supposed to ask it now!? Why doesn't it work in my main project? What is going on?

A 27" monitor with a 1080p resolution is a match made in hell. Oh the eye bleach. (At home I got 30" with 2k or 1440p resolution. Much better viewing experience.)

I'm having my first day in the office in the new job after two week of remote work. I think I will prefer working from home office definitly (even though the office coffee machine is nice).

It doesn't help that the internet connection in the office is 100 Mbit and at home I have 1 Gbit.

When you are at a crossroads, what helped you to decide?

I have two great job offers, and though my gut feeling is telling me to go one way due to tech stack and first communications, the other opportunity is (slightly) better paid and the company is much larger and nationwide active.

"It would be great if the feature would be implemented either today or tomorrow."

Well, nice wishful thinking. It does not constitute an emergency on my side though.

"Just start ahead"

I am supposed to transform calls from one api to another one. Yet there's no documentation, ambiguous code statements, no examples of what values are contained -- but sure, let me just start assuming how the whole thing is supposed to work. That won't lead us more into a murky waters at all.

Even more frustrating: We own the api. We should be able to tell by the access logs how we are queried. Yet for some reason, access logs cannot be accessed and I shall "just work from the swagger defintion".

Well, that swagger definition is broken, its example are shit (somebody liked to use undefined in optional fields, making me wonder even more what the heck is going on here), and I have no idea of what I am doing. Fun times.

I always confuse `for..in` with `for..of` and have to look up their respective meaning. Again.

It drives me crazy.

Do you have any mnemonic on this? How do you remember the difference?

(Now, as in this very moment, I know that for..in is for looping over keys of an object and for..of for looping over iterators. But tomorrow I will have forgotten it again.)

Sometimes people want to be too smart. If you want to consume a handful different restful API, it might make sense to abstract away some common functionality in your client implementation — yet to assume they follow the same convention in how their URI is built is borderline insane.

All I wanted to do was to change one API to a newer version, and now the implementation breaks for at least two other because it was done in an Abstract class and now I have to untangle that mess.

In some cases code duplication wouldn't be that bad. Even if an otherwise unrelated API seemingly share the same contract, still assume it has its own contract. You never know how those API evolve and I proclaim they will evolve towards breaking your assumptions.

"Could you help on project X and implement that straight forward feature?"

So I clone the repo. Run the tests in the main branch. 20 tests fail.

Yes, this will be fun and very simple ...

Uploading an xslx file to office365 to download it as an ods file only to be able to convert it to a csv file via libre office.

Direct conversion attempts with other tools would either fail converting the xslx file or break cells' values (ssconvert, soffice --headless -c, gnumeric).

One of those things where I fail to understand why it has to be so complicated.

Am I the only one who wants to be able to write functions in a human readable way, allowing for parameter in-between the words?

Instead of defining:

const enforceStringEndsWithChar(string: string, char: string) => {...}

I want to define it as:

const enforce(str: string)EndsWith(char: string) => {...}

.
.
.

I'll see myself out.

Did you ever think time estimations are hard? If so, did you ever try adding your actual taken time months after working on a ticket?

The "unit" in unit test does not mean your ENTIRE APPLICATION. Ever heard of scope!?

I am amazed how often people write overblown test setups, mock hundreds of unrelated services, just to test one tiny bit of logic.

That bit of logic could have been a pure function.

For that pure function you could write a dead simple unit test. Given that input, I expect that output. Nothing more, nothing less. (It helps even more if the pure functions only accepts primitives, like string and numbers, or very simple immutable value objects).

No I don't care that the service is used by another service, as your mocked interaction also doesn't test the service as a whole but you just assume the happy case most of the time anyway. You want to test the entire application? Let's not use unit tests for that but let's use a different kind of test for that (integration test, functional tests, e2e-tests).

If you write code in a way that easily allows for unit testing, your need to mock goes away.

Why yes, it makes total sense for a variable called `$connectionString` to only accept either booleans or integers ... wat

Also beware the beauty on how well that names conveys the variable's intent.

FML

After months I finally received an email from the external partner's support team!

```
Please be informed that we consider your Incident "XXX: How to Y?" as closed with status: Closed.
```

Why thank you.

As I was refactoring a class in a TypeScript project, I changed calls from `this.config` to `this.getConfig()`.

Suddenly, the tests were failing as somehow the live credentials were used from within the test.

Digging deeper I discovered this.

interface Base {
public config;
public getConfig();
}

So far so good. Wondering why config needs to be public, though nothing too shabby, let's look further:

class MyImpl implements Base {
constructor() {
this.config = this.getConfig()
}

getConfig = () => someGlobalVar;
}

┻━┻︵ \(°□°)/ ︵ ┻━┻

Why would you do this? This breaks dependency injection completely.

In the tests, we were of course doing:

testMe = new MyImpl();
testMe.config = testConfig;

So even though you have a getter, you cannot call it safely as the global var would take precedence. It's rather used as a setter within the constructor. WTF.

Sad part is that this pattern is kept throughout the entire codebase. So yeah for consistency!?

(And yes, I found a quick workaround by doing

getConfig = () => this.config || someGlobalVar;

though still, who in their right mind would do something like this?)

I have a bunch of contesters fort the worst interview.

#1 The Dishonest Ignorant

Me: *asks question*
#1: *stumbles*
Me: It's okay to say that you don't know.
#1: *continues to ramble on without making sense*
Me: Well, okay. That is all. I don't think that this will be a fit.

#2 The fraud

Me: How would you rate your knowledge in object orientated programming?
#2: Very advanced! I am an expert!
Me: Can you state the difference of an interface and an abstract class?
#2: *surprised pikachu-face* Well not that advanced!

#3 The trickster

During a skype call (without video):

Me: *asks question*
#3: *keyboard sounds aclacking*
Me: Are you googling?
#3: No *click clack click a clack* ... and to answer your question: *starts reading from the first search results*

The real bummer is, that in all of these cases, just saying "I don't know" would have been fine. (The "expert" OOP-guy would still have some explaining to do.)

It's not like that our interview process resolves around trick questions or that you'd get kicked out for getting one answer wrong. Though how can I trust somebody not to lie to me on a daily basis if they fake their interview?

We keep the interview relatively basic and rely on real-word coding exercise anyway and it helps us to get an idea on where we would gain support from them and where we need to support them.

As a developer you spend a lot of time learning new stuff anyways.

It blows my mind.

Functional test are failing.

Expected: 7109
Got: 9000

Grep code-base for 7109. No findings. 0_o

Dig through test setup written by a drunk.

Find:

assert(actualPrice === 1800 * conversionRate)

Goddamnit. You shall not calculate your expected values in a test setup.

In ESnext, private properties are marked with `#`.

Who thought that was a good idea? No really, who thought that was a good idea?

Why not just -- I don't know -- introduce keywords like ... let me think ... public, protected and private!?

Why this:

class MyClass {
a = 1; // .a is public
#b = 2; // .#b is private
static #c = 3;// .#c is private and static

incB() {
this.#b++;
}
}

If this becomes part of the language, no JavaScript developer may joke about php usage of `$` anymore.

My colleagues: "We should fail for scalastyle issues! Warnings will get ignored! Nobody fixes them! We should enforce a clean code style!"

Also my colleagues: Create PR with loads of `// scalastyle:off` flags comments.

¯\_(ツ)_/¯

Don't reuse your fixtures!

Each test case should be isolated. Don't ever think just because some function requires a similar input, it's safe to reuse it ALL OVER THE PLACE.

Why? Because someday, you want to change one functionality of one unit.

And you adapt your tests, fix your code, and suddenly, by changing one fixture, you break dozens if not hundreds of unrelated tests and now you have to clean up that mess.

It's even worse for functional tests with all those interwoven parts so that it becomes hard to reason about the scope of your tests when lacking proper documentation.

How I know? BECAUSE I AM CLEANING UP YOUR MESS RIGHT NOW!