не ну так чо

Тут на днях в США зацапали рпц-шного т.наз. священника, т.е. обычного гебиста, с доказательствами его гебешности.

Не, мы-то понимаем, что они все гебня. Но это не всем очевидно.

Насчет одного моего знакомого я колебался, то так, то так. Поп в Амстердаме. Помер несколько лет назад. Одни считали, мол, понятно, что гебня. Но для меня он был источником литературы; тот же "Доктор" мне достался от него. Ну я ценил это все, конечно. Конечно, он был не источником, а передатчиком. Там же целая сеть была, по которой книги ходили.

Так ладно, но меня стремало все время его какая-то тенденция рассказывать небылицы тем, кто не в курсе. Как он всегда боролся за свободу. Как его в армии в тюрьму посадили за любовь к свободе. В реале его за самоволку посадили на губу. Но голландцам же хорошо заходила эта телега, свободолюбец, в тюрьме сидел за убеждения. За веру.

Так в конце концов я прихожу к твердому убеждению. Да, гебня. Тем более что лица, пересказывавшие его душещипательные телеги, у меня тоже, собственно, давно уже под подозрением. Там что-то есть такое.

dybr

This morning was pathetic. I tried to get into the vpn, no way. Took pictures of those stupid cisco messages, posted it on devops slack help board - silence. Restarted cisco Any Connect, etc. Tried to use another network (I have three: fiber, my french phone, my american phone). Did not help. So I did what I could: documentation, etc.

But after about 16 heures everything started working. Just judging by the time zone, it was most probably our devops or whatever woke up and fixed their network, and that was it. No worries next time, right?

As I wrote already, I've discovered that there is no direct memory leak in this service if I copy a couple of source files from that netty library into my project and use them instead. So, wtf? But instead, there's a heap memory leak.

Chris, as always, was getting on my nerves, so I a) ran it again, with the old code - reproduced both direct memory leak and heap leak. Showed him the logs. He said, ha, heap does not leak in production. I believe I know why: production has bad gc parameters, and for some reason it helps.

But anyway. I experimented with pulling the freshest versions of that memory management, then the freshest versions of the code that uses it, etc. In short, I've learned how to get the dependency tree. 

But no, the freshest (this Spring's) code still leaks.

Chris is good in pointing out errors, but he is too slow in understanding what he is told. But anyway, I'll have to talk to him slowly, in simple words. He's okay, in a sense. A useful idiot, or something.

Anyway, so I continued looking around. And found, on SO, an advice: set "directMemorySomething=0". Which will turn on the leak checker (I know that when I was running my shit, leak checker was turned off, and I was clueless how to turn it on).

And now what. No leaks. No direct memory leaks, no heap leaks. Instead, at times leak checker throws an exception because some client code attempts to reuse a variable for a new buffer while it was pointing at an old, non-released buffer. And the checker catches it.

Bingo. Will slap together a PR tomorrow, and send it for review. 

Our nubes are shining. They learn our shitty docs like they are egyptologists reading the discussion between a Man and his Ba. One of them already decided to pick up the "common library" I started, and start populating it. That would be amazing. How come we interviewed and hired two great engineers? I don't know, but it's cool. Let's see if we can also hire James, seems like he filed his resume to Jacob.

Oh, and Renato wants me to review the jira cases and update the epic, write the tickets so we could finalize what our pardners want us to do but we never had time (our precious time). Ok, tomorrow. Mañana.