Купил вот такую штуку с алика.
Это анализатор воздуха.

Заметил, что когда долго сижу в комнате и не проветриваю, то становится трудно дышать (удивительно, правда?). Начал замечать это примерно в то время, когда началась тема с короной и иногда накручивал) Ну также у меня в общаге было такое и я проветривал комнату, за что Некит называл меня ледяным троллём))

Решил как-то анализировать количественно, при каких "числах" углекислого газа мне становится душно.

Пока не могу особо ничего сказать, кроме того, что эта штука шумит высокочастотно(( особенно при зарядке.

На фотке 505 - это угл газ.
0-1000 - норма. Больше уже не очень

Avoiding Unnecessary Coupling
On the other side of the spectrum, there are practices that increase coupling. A great example of unnecessary coupling is the practice of exposing all the private properties using public getters and setters. It is a trend that originated many years ago around Java Beans. The idea of providing getters and setters came from the need to build generic code manipulation tools and integrated development environments (IDEs). Unfortunately, this practice was completely misunderstood by the wider community. Something that was meant to allow IDE integration became a bad habit replicated across other platforms and languages.

Сегодня случайно увидел в чате упоминание XY problem. Стало интересно, что это такое и когда погуглил, то очень обрадовался, что сделал это, ибо это некое формальное описание ситуации, которую иногда верчу в голове, когда задаю вопросы на форумах и в чатах.

Если коротко, то когда у тебя проблема Х, ты думаешь, что она решится, если решится проблема Y и ты спрашиваешь про проблему Y. Но часто решение последней не даёт решение первой. Поэтому надо задавать вопрос всё же про проблему X.

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

Кстати, часто читая чат по Go, вижу там вопросы, которые по уровню совершенно мне посильны, но я не понимаю их. Ну то есть, будь это вопрос про что-то более простое по теме нежели программирование, то я бы всё равно его не понял ибо дело в формулировке. И на такое даже отвечать не интересно. Как говорил мой научник одному студенту: "У тебя словесный пофигизм".

😂
if 0.1 + 0.2 == 0.3
ох как жизненно искать баг в строке сверху

У Casio вышел научный калькулятор, в который встроен маленький интерпретатор Python'a 👀

Обколются своим питхоном и думают, что пишут clean code

низкая. ничего не сказать..

Не могу отделаться от навязчивой потребности писать супер оптимальный код с точки зрения производительности. Всё бы неплохо, но зачастую производительный код не есть чистый код, а чистый код гораздо важнее.

Вот и сейчас пишу штуку, которая как-то обрабатывает 1.5 МБ файлик. Не мало, но и не ГБ. Но все равно думаю: "А вдруг там хайлоад, и будет 100к таких файликов в минуту?" и пихаю указатели всякие, не пользуюсь range т.к. он делает копию, а только через индексирование... На самом деле это какое-то ОКР. Прям заставляю себя делать адекватно.

Как прекрасен Go, что ты можешь передавать тяжелые стуктуры просто по значению и не париться, ибо содержащиеся в них слайсы ничего не весят!

Сейчас занимаюсь парсингом xml'ек (ужас), которые весят 1.5-2 МБ. После их преобразования в структуру, которая в себе содержит слайсы, размер структуры 224 Байта. БАЙТА!!! кайф. Радуюсь таким странным вещам)

Кстати другие типы также, ибо они ссылочные.

Ня)
WD Red

Статейка, в которой понятия джун\мидл разбиты на категории, чтобы устранить разные понимания необходимых навыков для этих градаций.

Про робот-пылесос

Вот такую квартиру я хочу
https://www.youtube.com/watch?v=pfsGkv96xhM