@kuba Tyle dobrze, że nie tylko ja zauważam ten problem. A po nałożeniu go na słabą dokumentację (lub jej brak), chaos informacyjny to nawet nie tyle kwestia czasu, co po prostu smutna rzeczywistość.
I need to use two different Outlook / Teams accounts at once in my browser for my job and in this case, #Firefox Containers is the thing. With two clicks you can start new session of any service fresh and don't have to login again and again in incognito mode.
In case you wonder how to use it - right-click the new tab button and choose a new context you want to use. That's all.
@wariat@kuba Wait, a w jaki sposób to dokładanie się do branży tytoniowej tu działa? Podrzuciłbyś jakiś artykuł? Brzmi ciekawie, nigdy wcześniej nie słyszałem.
Osoba A: Trzeba mieć otwartą głowę na nowe pomysły i słuchać nowych idei <tu jakaś techniczna wstawka> Osoba B: <nt. technicznej wstawki> no ale tu robisz błąd, to nie tak działa Osoba A: Jestem ekspertem, od 10 lat działam w branży, <blablabla>, totalnie się z Panem nie zgadzam, Pan nie wie o czym mówi
Ah, let me share with you that weird thought process I was into today.
So, there's that huuuuge class (~1500 lines) in our repository. It's a wrapper for some API that may be used in another API - kind of layer of abstraction, with some simple data operations in between (like translating names and variables).
My starting point was: how can I get this huuuuge class split across multiple smaller classes?
Well, "if not composition, then maybe inheritance". I thought.
Then I started doing this kind of refactor, like splitting methods into separate classes, based on functionality.
And guess what - I've achieved nothing. Like, I still have to share the same internal state, but now I have e.g. 4 different big classes and one kind of "god object" that subclasses them all.
Basically, there is no added value, because code is the same and I've only added inheritance to existing composition.
So the first solution was: "let's play with composition".
But there is no way to get it well at composition. I already have this API class that is an internal object of my class, and all methods in my class touch this internal class.
And this internal API class is also a huuuuge (~2000 lines) class which I am not the owner of.
So, composition here is probably not a good advice, as it already is on the board...
Okay, so composition is there and inheritance adds no value. Then what?
At first, I thought: maybe some more "pro", like mixin classes? Well, this would not only add the burden of subclassing but also make me explain my colleagues what do I mean with "this class won't work on its own".
Maybe I could split the class into independent classes?
Maybe - but this still similar code, using the same API underneath, but now it has multiple names and connect/disconnect methods.
I'll probably stick with this huuuuge class. It's already simple and complicated at once. And seems like I can only sacrifice "simple" without reducing complexity.
All in all, it seems better to have it all in one class and go `CTRL+F` in my IDE (or use autocompletion) instead of creating structures that may result in some smaller classes, with no reasonable explanation for these classes other than "their smaller".
Zastanawiam się, jakby tu podejść do tematu od strony wyrabiania nawyków. No bo OK, mogę odstawić kawę, ale prostsze wydaje się zastąpienie jej czymś innym.
Tylko czym? Inką? Szlugiem? Herbata raczej odpada...
@icd@ola@kuba w sumie udało Wam się mnie przyciągnąć tematyką podkastu i powiem to głośno: robicie świetną robotę ;)
Chyba po prostu brakowało mi jakiegoś przekrojowego źródła informacji w tematach prywatności w sieci. Brakuje mi czasu na przeglądanie wszystkich afer i nowinek, a u Was wszystko jest w jednym miejscu. Szacun!
Pythonista, music nerd, bookworm, blogger, gym rat and traveller. That’s pretty much it 🐍🎶📖 Professionally, automation tester with #RobotFramework experience 🤖 Here for some microblogging in both polish and english 🇵🇱🇬🇧