I just reviewed a pull request with a test case like (pseudo code):

# Test MyService

const mock = createMock(myService.myMethod)
.whenCalledWith("foo")
.returns("bar");
assert(mock.myMethod("foo") === "bar"));

Why though? Why are we testing the mock? What is happening here? This test has no reason of being there instead of a fuzzy feeling that we now have unit test to lure us into a false sense of security.

I asked why we don't do an integration test. Response was: "They are slow."

Well, duh, but at least they would actually test something.

What do you gain by asserting that the mock is working the way you set it up?

I embrace the removal of the audio jack on smartphones, and I like listening to music via my Bluetooth headset.

Yet why, for fuck's sake, is a double tap on the headset's play button mapped to Call Redial?

I have lost count how often I called someone by mistake. How is such on action a meaningful default? What were they thinking, were they thinking at all?

Everytime I turn on the goddamn headset, I take extra care to ensure that I don't doubletap yet it still often happens by mistake.

I rarely call people anyways on my smartphone anyways.

Doing pair programming while I was navigating on somebody else's computer, we hit a weird behavior that our code changes weren't reflected.

Trying everything it turned out: I forgot to save.

Yet: Why though would you make me save? And why did the IDE not warn me about compiling unsaved changes? I think it was eclipse for Java, oh well. What can I expect ...

Anyways, I have gotten so used to my editors autosaving content for me as I write it, that I completely forget about doing Ctrl + S myself.

I never understood the need to hit that key combination manually as if I break something: `get reset --hard` will help to get me to a working state. (And even if I mess it up differently, my IDE's local history also let me restore recent changes.) And if it is a workign state, then I like to commit early and often. and

I am really dumbfounded why people insist on hitting save themselves.

I had no idea of how to implement the logic of a ticket. That's why I started with creating some unit tests that failed. Then I continued working until they all passed.

So it works now.

I have still no idea of how I implemented the logic.

What aren't there any 2k 32 inch 144 Hz monitors out there that are: flat. I want to upgrade my home setup from a 24" setup, which is, you know, flat. Even back in the days of the CRT monstrosities I've spent a premium on getting a flat panel, as the outside curvature was a technical obstacle to overcome.

I don't understand the need to curve the display. It distorts the lines, hinders other people looking at your screen as you have to be in the right spot, and every camera records on a flat surface. Why should it be a good thing to go curved?

I am reminded of the 3D craze.

```
public someMethod(index: string): Promise<void> {
return Promise.resolve(someAsyncFunction().then(() => {
return;
})
.catch((error) => {
this.logger.error(error);
throw error;
});
```

Somebdoy doesn't know their async / await syntax but they wanted aboard the promise-hype train. There is an entire class in that style.

If a project's structure is shit, well of course, let's continue using it because "it is known". Doing it any other way "will add complexity".

That I wasted three days making my working code adhere to the clusterfuck of a structure, nevermind that. Let's continue. And yes, colleagues do agree that the structure is shit, though let's improve it ... later.

Or in other words: Suck it up, we always have done it this way. Fuck you and your ill-advised attempts of trying to improve it.

Well, if your tests fails because it expects 1557525600000 instead of 1557532800000 for a date it tells you exactly: NOTHING.

Unix timestamp have their point, yet in some cases human readability is a feature. So why the fuck don't you display them not in a human readable format?

Now if you'd see:

2019-05-10T22:00:00+00:00

vs the expected

2019-05-11T00:00:00+00:00

you'd know right away that the first date is wrong by an offset of 2 hours because somebody fucked up timezones and wasn't using a UTC calculation.

So even if want your code to rely on timestamps, at least visualize your failures in a human readable way. (In most cases I argue that keeping dates as an iso string would be JUST FUCKING FINE performance-wise.)

Why do have me parse numbers? Show me the meaningful data.

Timestamps are for computers, dates are for humans.

Don't run `npm install` on your build machine. Use `npm ci` instead.

You want to re-merge a branch after a previous merge has been reverted on the mainline branch?

That's easy! Just revert the revert commit and then merge again. Because logic.

This is just evil.

Unlocking a dark theme by inviting friends to a service I just wanted to try out.

Also the wording is annoying. Yes, I do want the dark them, I just don't want to spam my friends for it. Subscription process cancelled, dickheads.

I forgot my password to my mindfactory account, one of Germany's biggest online vendor for computer components. So I go through the resetting process, which is:

- apply for password reset
- get a mail
- confirm the mail
(So far, so good)

- get a mail with a new CLEAR TEXT PASSWORD

Is this the stone age!?

You never send an email containing the cleartext! You never even store the password as is!
You, as the provider, should never be able to know what the actual password was.

All you are supposed to do is to generate a random salt, and hash the user's password with the salt, and then you only store the salt and the hash. And whenever a user inputs their password, all you do is to check if the you can recreate the hash with the help of the salt and your hash algorithm. (There are libraries for that!)

If a user wants to reset their password? Send them to a mail with link on where they can assign a new password.

At no point should the password ever be stored or transmitted in any other medium.

In my company, we have been have been using skype, hipchat, slack and now Teams.

Yet somehow, email always survives.

I get it as a communication channel for external clients as everybody has an email.

Yet when you as a company are using a team messenger, well then use it as your primary communication tool NO EXCEPTIONS or don't use them at all.

I don't.

This image sums it up pretty much (even though it was made for university).

Source: https://onetwentyseven.blog/2017/...

PM: "I have an easy question for you."
me: "Well let me decide if it's easy."
PM: "Where do the images for X in project Y come from?"
me: "Good question. No idea. I will come back to you."

I have seen spaghetti php code, I have seen spaghetti JavaScript code, I have seen spaghetti python code. I have seen a lot of spaghetti.

Yet this Angular project appears like it was touched by His Noodly Appendage.

And only his Noodlyness knows what's going on in there. It's truly beyond my mere mortal means of understanding.

One of those debugging days where minutes feel like hours, and hours like days.

I had the bad luck of being asked to dive into a legacy project which was unmaintained for months, but of course it's still on prod. And very suddenly the urgent need arrises to change stuff.

Yet: the docker stack won't work. It builds fine but the stack crashes.

Long story short: some internal api URI were renamed and at some point one internal api started to always require an access token. Which we set for the stage, prod env yet somebody forgot to mention that to the devs of legacy-project.

That ain't too bad.

WHAT IS FUCKING BAD IS THAT YOUR SHITTY APP SWALLOWS THE ERROR MESSAGE!

I mean it's bad enough I have to `var_dump && die` your app since you never bothered to setup a xdebug that I could use out of the box, yet egregious fact that your app would catch a valid exception but transforms it into an "internal warning" is borderline insane!

It's ok to throw exceptions. It's ok to let your service die. That's how other will know what and where to fix it. (You may want to restrict the data visible to the outside, but that's a whole different conversation.)

I really want to stress that we should add the ticket for adding the missing test cases in *this* sprint and not postpone it any further.

-- "Isn't there something more important to be added instead?"

There. ALWAYS. Is. Something. MORE. Important. The real problem was that we implement the test cases in the past to begin violating our definition of done. We have to fix and one point and we have to own that decision as nobody else will care about passing tests and test coverage. It's our job to care for that.

Yes, we can instead focus on all the other high-priorities task that should have been done yesterday, yet that won't change the fact that large part our codebase will remain an untested messy blackbox just asking for weird bugs and wild goosechases in the future.

Don't hide behind "high priority tasks". A job is done when it is fucking done and tests are part of that. Hurrying from one important task to the next will just mean we'll never do it. There is no better time than right now.

If code coverage got left behind in the past, then we'll have to suck it up in order to fix it as soon as possible, otherwise we'll just suck forever.

Hey passwd, when I want my password to be short then I want it fucking short. Don't tell me that "f" is too weak and prevent the action. A mere warning would suffice. (And I now know that if run as root it doesn't check the password criteria. Still, the default is annoying.)

I needed a short password to workaround a weird frozen system issue on unlocking the keyring in the latest Ubuntu release. It would freeze completely while I was typing my password, and hence by making my password short, I was quicker than the freeze, and hence got a useable system again.

Comments should describe the why and not the what and always be up to date ... or this will be the result.

No matter what I do and try: Scala always look so damn ugly.

And yes, I do use scalafmt. Yes, I try to follow the scala approach, yet still -- my poor eyes.

It's also not helping that the bracket mess and the lack IDE-help in regards to finding where I missed them reminds me of time wasted in lisp.

That feeling when you realize that the REST API you were trying to consume apparently does not provide a query flag to get for a more detailed response making you think you'll need to fetch one list of items and then fire almost 1,000 requests really does not compare to that feeling when a colleague points out that the REST API in question does in fact support the flag AFTER you implemented the roundabout way.

FUCKING HELL!

I just didn't realize that I could click on GET and POST blocks for the metronome API documentation opening up a frigging pop-up. (See screenshot.)

Why couldn't the information have been more upfront? Only a cursor change on hovering the area could make one thing to click there.

Oh how I blame their lack of a user interface for my blindness.

I thought that it was just a basic documentation that only told you which endpoints exist and expects you to learn by trial of fire. So I searched the interwebs and on their support forum I found an old issue making me think that my round-about way was the way to go m(

Even worse, on the support forum I cannot even leave a comment warning the poor souls comming after me that they should not do the roundabout way as that issue has been long closed.

If you want to see it yourself: https://dcos.github.io/metronome/...

Sombody really should have pointed out https://xkcd.com/927/ to them m)

Stop commenting out code blocks!

Either fix your shit or delete it.

I am open to argue what fixing may mean, as it is perfectly fine to make your broken code not reachable, e.g. via feature flags or skipping certain tests. Yet never ever should you comment those blocks!

So you say you want to keep it for historic reasons? You know, that is why we use version control! If you ever need certain functionality back, you can restore that state.

Each decent IDE also offers a local history where you can even restore code blocks that weren't even pushed or committed. So use that!

Commenting out test cases is a really bad habit, as you have no reminder that you shall restore it.

And no, a TODO and a FIXME won't count as a reminder as you have to actively look for them. And we all know how well that goes, don't we? (One time, I found a typo of a `TDO`. So even with a regular lookup for TODO, stuff will slip.)

Each test suite offers you ways to skip tests if there are valid reasons why they should not fail the build temporary and they offer colorful feedback. Yes, that means that your tests won't be green, but guess what: That's a feature! They shouldn't be.

That yellow is a fine reminder, aka warning!, that you should really fix your shit.

Commented code screams: "I DON'T KNOW WHAT I WAS DOING!" and it confuses the hell out of other developers ("Was this commented because of debugging purposes and should be active again or can I safely delete this!?") and adds verbose crap to the code base.

If you find yourself to be in a place that you comment code a lot, I also argue that your workflow is broken.

When you are using a decent debugger, there shouldn't that much of a need to comment in and out a lot of code in order to reason about your code-base.

Trying to parse JSON to case classes and vice versa is like trying to parse HTML with regexes: A straight way to hell.

TO͇̹̺ͅƝ̴ȳ̳ TH̘Ë͖́̉ ͠P̯͍̭O̚​N̐Y̡ H̸̡̪̯ͨ͊̽̅̾̎Ȩ̬̩̾͛ͪ̈́̀́͘ ̶̧̨̱̹̭̯ͧ̾ͬC̷̙̲̝͖ͭ̏ͥͮ͟Oͮ͏̮̪̝͍M̲̖͊̒ͪͩͬ̚̚͜Ȇ̴̟̟͙̞ͩ͌͝S̨̥̫͎̭ͯ̿̔̀ͅ

The documentation of scala akka http may be just gibberish as far as I am concerned. You would think that hooking into the marshalling process (aka de/serialization) would be straight forward, I've dealt with similar problems before and solved it.

I have an object, it should be transformed into a Json and vice versa. Should be easy as pie.

Not with scala and akka-http. The docs tell you how to achieve something in dozen different ways yet lack a complete example. My first custom marshaller I created in a "marshall" package in my! namespace, but it was breaking scala compilation due to some black magic.

It's not clear how when and why marshallers are added, they just somehow are. Why do I have to deal with entity marshallers vs response marshallers. I just want each instance of a certain type to be transformed into a specific Json presentation.

Asking on stackoverflow also only yields in incomplete hints of "just do boargh" presupposing certain knowledge while sounding borderline condescending.

Currently, I just want to burn the project and rebuild it with fucking PHP. Flame all you want, at least I would get things done and the JMS serializer library has decent documentation and it works in an expected way.

Akka-http, combined with Scala, looks from my current rage-driven perspective like a solution worse than the problem.

I cannot remember having seen a more unethical and pushy user interface than the one of viagogo.

I'm a frustrated to close the entire tab within the first 10 seconds. It's a sad story on on how it tries to instill a sense of urgency to BOOK NOW!

100 people are looking RIGHT NOW at the YOUR offer! Stop thinking, act fast! BUY IT, YOU FOOL OR IT IS GONE!

Here, see all those other options are already sold out m( Oh look, that option over there? Just sold out in this very instant you lazy ass.

I have seen something similar on booking.com and airbnb, yet this egregious implementation truly gets my blood boiling and sets a new low.

I'll take my business elsewhere.

If you develop a web shop, treat your customers as actual adults. Let them breathe. Let them make an informed decision.

If you need to rush them, your business model is broken.

If my employer would ask me to develop something like that, I'd escalate hard. If that wouldn't suffice, I'd reject implementing that anti-feature and would look for a new job out of principle.

Me: We should change the http response code to anything but 200 OK in the error response case of our API.
Other dev: No, it's fine.
Me: Why?
Other dev: The client successfully receives an error message.
Me: ┻━┻ ︵ヽ(`Д´)ﾉ︵ ┻━┻

That day when I destroyed the hard drive of my mother's PC when I was 12 years old. (The drive wasn't properly screwed in the case, and so after a few repositions of the case, it would one day start up sounding like a jet engine and after that scary sound: silence.

My mother took it relatively well, mostly because she saw how I was beating myself up over it. I was so mad at myself as I knew better! I knew how to create a backup strategy, I'm theory. I never really put in into practice though.

She had no backups of course. No way of regaining her data.

Now she does. And now she regularly calls me to initialize a backup of her current data on her external drive. (And every few months I sync her data over to my place on a data storage just in case she loses both her PC and external drive in a fire.)

"I'm almost done, I'll just need to add tests!"

Booom! You did it, that was a nuke going off in my head.

No, you shouldn't just need to add tests. The tests should have been written from the get go! You most likely won't cover all the cases. You won't know if adding the tests will break your feature, as you had none, as you refactor your untested mess in order to make your code testable.

When reading your mess of a test case and the painful mocking process you went through, I silently cry out into the void: "Why oh why!? All of this suffering could have been avoided!"

Since most of the time, your mocking pain boils down to not understanding what your "unit" in your "unit test" should be.

So let it be said:

- If you want to build a parser for an XML file, then just write a function / class whose *only* purpose is: parse the XML file, return a value object. That's it. Nothing more, nothing less.
- If you want to build a parser for an XML file, it MUST NOT: download a zip, extract that zip, merge all those files to one big file, parse that big file, talk to some other random APIs as a side-effect, and then return a value object.

Because then you suddenly have to mock away a http service and deal with zip files in your test cases.

The http util of your programming language will most likely work. Your unzip library will most likely work. So just assume it working. There are valid use cases where you want to make sure you acutally send a request and get a response, yet I am talking unit test here only.

In the scope of a class, keep the public methods to a reasonable minimum. As for each public method you shall at least create one test case. If you ever have the feeling "I want to test that private method" replace that statement in your head with: "I should extract that functionality to a new class where that method public. I then can create a unit test case a for that." That new service then becomes a dependency in your current service. Problem solved.

Also, mocking away dependencies should a simple process. If your mocking process fills half the screen, your test setup is overly complicated and your class is doing too much.

That's why I currently dig functional programming so much. When you build pure functions without side effects, unit tests are easy to write. Yet you can apply pure functions to OOP as well (to a degree). Embrace immutability.

Sidenote:

It's really not helpful that a lot of developers don't understand the difference between unit, functional acceptance, integration testing. Then they wonder why they can't test something easily, write overly complex test cases, until someone points out to them: No, in the scope of unit tests, we don't need to test our persistance layer. We just assume that it works. We should only test our businsess logic. You know: "Assuming that I get that response from the database, I expect that to happen." You don't need a test db, make a real query against that, in order to test that. (That still is a valid thing to do. Yet not in the scope of unit tests.)