[prog.sarcasm] Если долго сидеть на берегу, то можно увидеть как Erlang-еры...

...переписывают свой софт на Rust:

Моя идея о том, чтобы переписать наш Flussonic с Erlang на Rust оказалась совершенно прекрасной и у меня совершенно прекрасные результаты. Захват 10 000 камер на сервер - это прямо скажем серьезный результат, на рынке таких предложений мало.

Это слова Макса Лапшина, одного из самых известных пользователей Erlang-а в Рунете (ссылки на пару статей которого были даже у меня в блоге). Он же и автор мема о том, что писать на С++ -- это выгребать корки по утрам.

Сколько было в прошлом разговоров о том, насколько хорош Erlang и насколько Erlang подходит и для таких задач, где, казалось бы, C++у самое место, а не одному из самых медленных динамически-типизированных языков. И все это для того, чтобы в итоге отказаться от Erlang-а в пользу нативного компилируемого языка, прямого конкурента С++ по производительности и ресурсоемкости.

Upd.В этой теме на LOR-е еще прекрасное добавилось от Лапшина (это ответ на вопрос уперся ли Erlang в потолок производительности):

Во все потолки, какие можно было.
И производительность, и количество библиотек, и количество людей и всё прочее.
Когда стало ясно, что прийдется самому руками писать QUIC, тут я слегка устал от эрланга.
О перфомансе вида «принять 10 000 камер» и речи не идет, причем если бы не медленный сторадж, новый код можно поковырять и до 20 тыс (просто это не нужно).

При всем моем уважении к Erlang-у и людям, которые его создали, но такие факторы, как "производительность" и "количество людей", как по мне, так были очевидны много-много лет назад.

---

Если говорить серьезно, то когда вам повезло работать на проекте в течении 10-15-20 и более лет, то у вас есть возможность наблюдать за тем, как принятые вами же решения, которые когда-то давно казались крутыми и удачными, через годы не просто перестают такими быть, а нуждаются в замене на что-то, что сейчас кажется крутым и удачным (и далее по рекурсии).

[work-n-life] Послесловие к уходящему году и поздравления с НГ

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

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

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

В профессиональном плане, когда здоровье позволяло полноценно работать, все было достаточно ровно и рутинно, как и в 2024-ом: получаешь новую задачу, вникаешь, куришь бамбук, экспериментируешь, делаешь, тестируешь, доводишь до ума, получаешь новую задачу, вникаешь, куришь бамбук... И так снова и снова. Разве что местами сложность выполняемой работы несколько превышала мои возможности и мозги закипали от нагрузки. Очень надеюсь, что так продолжится и в 2026-ом.

С другой стороны, 2025-ый оказался все таким же безрадостным для наших собственных открытых продуктов. Два небольших релиза для SObjectizer и ничего нового в RESTinio 🙁 Но нельзя не вспомнить два знаковых события, связанных с SO-5: доклад Марко Арена на митапе в Болонье и использование SO-5 в проекте компании YADRO.

По поводу SObjectizer-а есть одна большая хотелка на 2026-й и было бы очень и очень здорово, если бы удалось воплотить её в жизнь.

В блог писал меньше, чем в предыдущие годы. Даже в самом тяжелом 2021-ом удалось написать на один пост больше. Отчасти это объясняется тем, что сейчас я гораздо чаще сиюминутные впечатления публикую в LinkedIn. В этом плане использую LinkedIn в качестве Twitter-а -- удобно зафиксировать какую-то эмоцию или сделать репост чего-то. Тогда как написание блог-поста требует времени и концентрации, поэтому на blogger-е публиковался меньше. Но старался не снижать качества. Чем, собственно, и собираюсь заниматься в следующем году. Так что если вы все еще находите для себя что-то интересное в моем блоге, то не переключайтесь 😉

Ну а вне работы ничего интересного не было вообще. Может быть за исключением знакомства с парой новых динамиков с Aliexpress, о чем постараюсь рассказать отдельно через месяц-другой, когда остальные покупки приедут. Бюджетная аудиофилия, к сожалению, все еще со мной 🥴

Планы на будущий год опять очень простые: прожить его.

Только вот в 2025-ом воплотить их в жизнь оказалось не так-то просто. Надеюсь, в 2026-ом будет попроще. И, если это получится, то буду стараться делать что-то полезное и публиковать что-нибудь интересное. Как-то так.

Всем же читателям пожелаю здоровья, здоровья и еще раз здоровья в наступающем 2026-ом. Пусть ваш 2026-ой будет гораздо лучше моего 2025-го.

Ну и всем нам мирного неба над головой.

---

PS. Немного слукавил по поводу отсутствия чего-либо интересного вне работы: в этом году случилось 30-летие нашего выпуска из ГГУ. На вечер встречи мне прийти не удалось, но зато раскопал свои старые фотопленки со студенческих времен и оцифровал то, что на них еще осталось. Заглянуть в прошлое на несколько десятков лет назад -- это впечатляет. Вот, например, ваш покорный слуга собственной персоной в кузове трактора "на картошке" в октябре 1990-го года.

[life.cinema] Вместо заключительного кинообзора

Так уж получилось, что в первые три месяца этого года у меня выдалось много свободного времени, часть которого уходила на просмотры всякого разного. Часть из отсмотренного попадала в традиционные кинообзоры, но далеко не все, т.к. был ряд фильмов, которые я даже не смог досмотреть (например: тыц и тыц).

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

И сегодня на этот вопрос я убедительного ответа найти не смог.

В связи с этим завязываю с публикацией списков, 99% которых составляет дешевый шлак. Может быть время от времени буду делать короткие заметки о фильмах, которые действительно понравилось. Но без привязки к конкретному графику.

Грустно, конечно. Длилась вся эта история, емнип, с октября 2012-го. Но что поделать, если кинематограф с ускорением несется по наклонной плоскости куда-то под плинтус и выдает "шедевры" вроде Капитан Америка: Новый мир, Мастер и Бесстрашный. Не хочу участвовать в этой безумной гонке наперегонки со здравым смыслом.

Upd от 2-го апреля: тем, кто воспринял этот текст слишком уж всерьез стоит обратить внимание на дату публикации ;)

[life] Пара-тройка вредных советов о том, как создать дискомфорт вашим соседям по больничной палате

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

Заранее приношу свои извинения за использование обсценной лексики, но здесь как в анекдоте про прачечную, никак не обойтись... :(

[work-n-life] Послесловие к уходящему году и поздравления с НГ

Много лет ничего не писал в стиле "итогов года" и не поздравлял своих читателей с наступающим. Подумалось, что это неправильно: какие-то отчаянные люди все еще приходят сюда, а некоторые даже находят время и желание оставлять интересные и полезные комментарии. Что для меня лично с каждым годом становится все более и более ценно.

Кроме того, в предновогоднюю пору лента в LinkedIn-е стала напоминать выставку тщеславия: у каждого второго наполеоновские планы, а у каждого третьего достижений за минувший год больше, чем у самого Цезаря. ИМХО, нужен такой предновогодний пост, прочитав который люди вроде меня почувствовали бы себя нормальными, выдохнули с облегчением, мол, а ведь у меня все не так уж и плохо, а может даже и вполне себе хорошо. Так что если вам нужна подобного рода терапия, то вы попали по адресу 😉

В профессиональном плане уходящий 2024-ый год оказался ровным и ничем не выдающимся, сплошная рутина: получаешь новую задачу, вникаешь, куришь бамбук, экспериментируешь, делаешь, тестируешь, доводишь до ума, получаешь новую задачу, вникаешь, куришь бамбук... И так снова и снова. Разительное отличие от нервяка и неопределенности 2019-2021 гг.

Очень надеюсь, что так продолжится и в 2025-ом.

С другой стороны, 2024-ый оказался безрадостным для наших собственных открытых продуктов. Два небольших релиза для SObjectizer, всего одна статья на Хабре и ничего нового в RESTinio 🙁 При этом, далеко не факт, что в 2025-ом получится выкраивать больше времени на собственный OpenSource, постараемся, конечно же, но последние годы научили не загадывать далеко наперед.

В блог писал меньше, чем во все остальные годы, за исключением 2021-го, тот вообще был в этом смысле мрачным, а уходящий 2024-й таки получше. Остается надеятся, что при очередном снижении количества хотя бы качество не ухудшилось.

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

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

Ну вот как-то так, 2024-ой год прошел тихо и спокойно, без потерь и достижений. Планы на будущий год простые: прожить его.

Своим же читателям пожелаю счастливого Нового Года. Пусть все будет хорошо! И пусть ваш 2025-й будет гораздо лучше, чем мой 2024-й 😜

[job.flame] Откуда такой акцент на софт-скиллз в последние годы?

Позволю себе немного пофлеймить в теме, в которой не разбираюсь (с другой стороны, а разве можно как-то иначе? 😉)

Когда я начинал работать, ни о каких софт-скиллах и речи не было. Это, по моим ощущениям, вообще тема текущего десятилетия. А реальный акцент на этих самых софт-скиллах делается в последние 3-4 года.

И я не мог понять, почем вдруг стало так много разговоров про софт-скиллы. Неужели с хард-скиллами все стало настолько хорошо, что можно уже подумать и о душе софт-скиллах?

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

А давеча посмотрел случайно два интервью с нейробиологом Вячеславом Дубыниным:

ЛЮДИ ТУПЕЮТ! Причина - не алкоголь или никотин. Вячеслав Дубынин.

Вячеслав Дубынин про поиски себя, выгорание, аффирмации. Как работа влияет на мозг?

И у меня появилась другая версия. Практически медицинская 🙂

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

Мы с раннего детства проводили много времени в разного рода коллективах: будь то детский сад, школа, кружки, спортивные секции, пионерские и спортивные лагеря, не говоря уже про двор. Сплошной реал, никакой виртуальности. В котором навыки этого самого общения, как и навыки существования в рамках коллектива, прививались прямыми и незатейливыми способами. Уже к 4-5-м классам школы практически каждый на своей шкуре усваивал, что трепать языком нужно поменьше, за слова принято отвечать, да и получить в лыч за эти самые слова можно очень даже легко и непринужденно. А можно и не за слова, а просто потому, что оказался не в то время и не в том месте. Всякое бывало... В общем, прямые и незатейливые способы иногда оказывались настолько жесткими и суровыми, что не все вписывались в эти условия, но это уже тема другого разговора.

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

Что наводит меня на следующую мысль: а что если у молодого поколения, которое вместо игры в "войнюшку" всем двором, чатилось в соцсетях, просто оказались недостаточно развиты те самые нейросети для общения и социализации, которые естественным образом прокачивались у нас, старпёров, в нашем далеком уже детстве?

Т.е. тупо часть мозга, которая у поколения 1960-х, 1970-х и 1980-х была хорошо развита вот просто потому, что другого выхода-то и не было, у поколения 2000-х уже просто на недоразвитом (в биологическом смысле) уровне. И, грубо говоря, нынешние 20-летние не могут в человеческое общение на таком же уровне, на котором умели мы.

С этой точки зрения становится понятным акцент на софт-скиллах. Ведь это в наше время можно было не особо заморачиваться: ведь если индивид дожил нормальным человеком до совершеннолетия, да еще и образование получил, значит с высокой долей вероятности, с общением у него более-менее. Не, конечно, феномены вроде Григория Перельмана были всегда. Но в том-то и дело, что они были феноменами. Основной же массе как-то на базовом уровне было понятно, что такое "быть мудаком", откуда и проистекало стремление таковыми не быть.

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

---

Ну ладно, эта медицинская версия слишком уж попахивает стариковским ворчанием по поводу никчемной молодежи. Так что вот еще одна.

Ранее (лет 25 назад) в найме роль HR была не столь существенна, как сейчас. А вот нонче, судя по постам в LinkedIn, практически только через HR.

Могут ли HR адекватно оценить хард-скиллы соискателей? Сильно сомневаюсь. Может и есть единицы таких продвинутых, но именно что единицы.

Тогда как софт-скиллы могут, да еще как. Отсюда и значимость этих самых софт-скиллов: ведь если процессами найма рулят HR, то растет и вес критериев, которые сами HR могут оценить. Отсюда и актуализация софт-скиллов.

Но эта версия, честно говоря, слишком банальна. А потому и не интересна 😎

[prog] Похоже, использование табуляции становится пережитком старых (не)добрых времен

Я уже более 30 лет являюсь приверженцем табуляции для отступов в коде. Но вынужден признать, что часть преимуществ табуляции сейчас уже сложно оправдать (а то и объяснить).

Во-первых, это в 1990-ом году, на 5.25" дискете емкостью 360Kb (да и даже 720Kb) приходилось место экономить. Поэтому было критично, что исходный файл с табуляцией может занимать от 1/3 до 1/2 меньше места, чем файл с пробелами. Сейчас, когда терабайты умещаются на MicroSD карте, об этом даже смешно говорить.

Во-вторых, сейчас сложно найти редактор кода, не говоря уже об IDE, который не умеет сдвигать блоки кода влево/вправо на нужное число позиций. Тогда как раньше в каком-нибудь редакторе Turbo C 2.0 такой фичи не было как класса. Хочешь сдвинуть несколько строк влево? Удаляй лишние символы в начале строки вручную. Хочешь сдвинуть вправо? Добавляй. Опять же вручную. Понятное дело, что табуляция здесь гораздо удобнее, чем пробелы.

В-третьих, экраны сейчас не в пример лучше, везде графические интерфейсы, можно поставить какой хочешь шрифт какого хочешь размера. А раньше, в текстовом режиме на каком-нибудь убогом терминале от ЕС-1840 в режиме 80x25 особо не разгонишься. И если на таком экране исходный код с отступами по 2 или 4 пробела выглядит убого, то ничего ты уже не сделаешь. Другое дело с табуляцей -- настроил под себя, хоть в единичку, хоть в восьмерку, и радуйся.

В-четвертых, раньше мне гораздо чаще приходилось извлекать фрагменты кода и вставлять их в какую-то документацию. Да даже больше: раньше код даже часто печатали на бумаге, просто чтобы поразбираться в спокойной обстановке оставляя пометки на полях (в "спокойной обстановке" ты оказывался еще и потому, что твое машинное время закончилось и нужно уступить компьютер коллеге). Возможность поменять размер отступов не трогая сам текст и здесь была очень в тему. Многие ли сейчас пишут документацию, куда вставляются фрагменты реального кода? Кто-нибудь сейчас печатает код на бумаге, чтобы покорпеть над ним с красным карандашом в руках?

Ну и не могу не поделиться еще одной своей болью последних нескольких месяцев: web-интерфейс Google Mail удаляет табуляции из фрагментов кода когда их вставляешь в текст письма копипастой, весь такой фрагмент оказывается выровнен по левому краю 🙁
Хорошо хоть Google Doc такой фигней пока(?) не страдает...

PS. Прошу понять меня правильно. Я не пытаюсь развести очередной срач на тему "tabs vs spaces". Просто как-то грустно от осознания как давно я в программизме и как много поменялось за это время.

PPS. Xотя, конечно, же, единственный верный способ -- это табуляция, все остальное должно быть предано анафеме и выжжено каленым железом, адназначна! (Желающих мне возразить прошу обратить внимание не тег Humour)

[prog.c++] Вредных советов пост: пара-тройка способов усложнить жизнь тем, кто будет сопровождать код после вас

Хочу поделиться многолетним опытом. Работает на 100%, а иногда и на все 146%. Так смело можете брать на вооружение, если решили конкретно поднасрать своим коллегам.

Во-первых, используйте std::pair и std::tuple для долгоживущих объектов. Особенно если эти объекты свободно перемещаются между различными частями программы.

Поверьте, настоящие программисты (тм) всегда будут точно знать, что означают it->first или std::get<3>(*it).

Наверняка на вашем пути встретятся душнилы, которые будут утверждать, что std::pair и std::tuple нужно ограничивать очень маленьким скоупом. Вроде возвращаемого значения лямбда-функции или же обычной вспомогательной функции, но которая вызывается всего в одном-двух местах. А для всего остального нужно создавать нормальные структуры с названиями полей, соответствующими предметной области.

Не обращайте на них внимания. Это же склеротики, которые не могут удержать в памяти даже два простых названия -- first и second, хотя что может быть проще? Ну и наверняка им платят за строчки кода, а не за решение проблем. Вот они и фигачат по 100500 строк там, где можно обойтись одним std::pair-ом.

Во-вторых, забудьте такую вещь, как strong typedef. Тем более, что в C++ из коробки ее и нет. Так что это вообще не ваш путь, а те, кто про пытается заикаться о strong typedef, просто учились программировать на Pascal-е, а значит старпёры и ничего не понимают в современной разработке софта.

Если у нас есть строковое имя пользователя и строковый же пароль в виде открытого текста, то достаточно простого std::string.

Вводить какие-то новые типы UserName и PlainTextPassword? Ради чего? Ради того, чтобы случайно не пихнуть пароль туда, где ожидается имя пользователя?

Да это вообще смешно. Ведь так никто не делает. А если вдруг, так это от кривизны рук. Настоящие программисты (тм) таких ошибок не допускают.

Но даже если какой-то джуниор-разработчик такую ошибку допустит, то он же сам себе злобный буратино, да и тестами все это ловится на раз-два.

Так что никаких strong typedef-ов. Забудьте как страшный сон.

Ну и в качестве бонуса: вам не нужны ни using, ни typedef. Если у вас есть map, значением которого будет vector из queue, то вот прямо так и нужно записывать. Никаких вспомогательных using-ов и typedef-ов!

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

void process_appropriate_items(       const std::vector<             std::pair<                   std::pair<int, int>,                   std::tuple<std::string, std::string, std::string, std::string> > > & what) {    for(const auto & p : what)       if(p.first.second > 0)          process(std::get<3>(p.second)); }

Зачем выдумывать что-то еще? Неужели вам не понятно что означает p.first.second и std::get<3>(p.second)? Да ну, не может такого быть!

---

Перестрахуюсь на всякий случай: в каждой фразе здесь должен быть тег "сарказм". Иногда и не один.

[prog.work] Конкурируем на глобальном рынке ;)

Вот эта найденная на просторах Twitter-а запись заставила вспомнить об одном моменте, который произошел в моем сознании где-то в 2017-ом году.

Дело в том, что если не считать нескольких месяцев, проведенных в ЕПАМе, когда довелось чуть-чуть прикоснулся пятым винтиком в пятисотой шестеренке к разработке продукта для глобального рынка, практически всю свою профессиональную жизнь (до создания собственной фирмы) довелось работать над продуктами, ориентированными на узкий локальный рынок. Даже в компании "Интервэйл", которая одна из первых в РФ стала делать системы мобильного банкинга и держала заметную долю рынка SMS-информирования, все равно это были довольно-таки локальные истории.

А вот когда мы создали свой "СтифСтрим" для того, чтобы оказывать поддержку пользователям SObjectizer-а, да еще и следом, для диверсификации, занялись разработкой RESTinio... Вот тогда до меня вдруг дошло, что наши OpenSource продукты в прямом смысле слова конкурируют на самом что ни есть глобальном рынке. И для того, чтобы чего-то здесь добиться, нужно стремиться быть на одном уровне с лучшими. А лучшие здесь выпускаются в OpenSource, например, Microsoft-ом или Facebook-ом. И вот с ними приходится толкаться локтями.

Признаюсь, для меня, как для троечника, с трудом закончившего университет в "условном Бобруйске"*, это осознание не сказать, что сильно обрадовало 😏

Но как-то свыкся.

Просто стараюсь о таком не думать. А то груз ответственности становится тяжелее, чем следовало бы 🙂

---

* Касательно "условного Бобруйска". Меня уже несколько раз на русскоязычных форумах попрекали тем, что нет за плечами диплома МГУ или еще чего попрестижнее. Да самим фактом проживания не в Москве/Питере/Лондоне/Силиконовой долине так же. Посему данный термин мне нравится, не позволяет свалиться в снобизм 😎

[career.flame] Рекомендация, которая меня всегда подбешивала...

..."стремись в коллектив, в котором ты будешь худшим".

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

Рекомендацию эту я встречаю уже, если не соврать, лет 15. И каждый раз меня одолевает некоторое недоумение. Чем дальше, тем больше.

В очередной раз у меня подгорело на вот этой иллюстрации, попавшейся в ленте LinkedIn:

Так что не удержусь, позволю себе излить часть желчи и сарказма.

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

Наверное, для людей, застрявших в развитии на подростковом уровне, какой-то такой критерий лучшести существует, так что не будем заострять на этом внимание. Остановимся на парочке других вопросов.

[wow] LOR торт, а я ай-ти-голодранец!

Простите, таки не удержусь, опубликую. Этот пост сделал мой день еще вчера, но сегодня с утра он мне кажется еще смешнее (выделение на скриншоте мое):

цинк

Надеюсь люди, которые задавали мне вопросы по нашим OpenSource разработкам или открывали Issues на GitHub-е, смогут составить свое впечаление о том отвечаю ли я за что-то и исправляю ли ошибки.

Если кого-то действительно интересует вопрос почему я не занимаюсь опакечиванием под Linux-ы, то, пожалуй, здесь есть исчерпывающий ответ: тыц.

[prog.flame] Нет, с любителями PascalCase (да и camelCase) нам не по пути!

Никто, ну вот вообще никто, не убедит меня, что:

TransformObtainedVideoFrameForFurtherProcessing

читается лучше, чем:

transform_obtained_video_frame_for_further_processing

Опять же никто не сможет привести хоть сколько нибудь убедительные аргументы, доказывающие, что:

transform_obtained_video_frame_for_further_processing

это плохое, негодное и слишком длинное имя.

Никто, слышите?! Даже и не пытайтесь.

PS. Полагаю, что +50% к ЗП может изменить точку зрения на прямо противоположную.

PPS. Тяпница же на дворе ;)

[prog.c++.humour] В эфире рубрика "трудности перевода" :)

Оригинал: "This special type allows checking for temporary/lifetime object issues."

Перевод: "Этот специальный тип позволяет проверять наличие временных/постоянных проблем с объектами."

"Наличие временных/постоянных проблем с объектами" в контексте разговора про C++ -- это пять! В самую точку. Поскольку в C++ всегда есть какие-то проблемы с объектами, иногда временные, иногда постоянные.

---

Даже я со своим лингвистическим кретинизмом перевел бы данную фразу как "Этот специальный тип позволяет проверять наличие проблем с продолжительностью жизни временных объектов", что было бы гораздо ближе по смыслу к оригиналу.

[prog.c++.flame^humour] Как хорошо, что я IDE не пользуюсь и не знаю, что такое бывает ;)

Подсмотренно в ТГ-чатике:

Ссылка: тыц, там же можно отследить и весь контекст.

Таки да, давным-давно работаю в gVim-е без плагинов. Вроде как полет все еще нормальный. Но я и не знаю, что именно упустил :)

Думаю, что мне удается так долго обходиться gVim-ом просто потому, что пользуюсь, в основном, C++. Иногда чистым Си, иногда Ruby. Для всех этих языков польза от IDE не сказать, чтобы большая.

А вот если бы программировал на C#, Kotlin и, особенно, на Java, то вряд ли бы без IDE обошелся.

На счет Rust-а не знаю. Язык более строгий и легче поддается парсингу со стороны IDE, если я все правильно понимаю, так что IDE может быть удобна в случае Rust-а. Но, как я слышал, многие пользуются Rust-ом и без помощи IDE.

[prog.flame;humour] А ведь на самом деле интересно где же доказательства, что .NET и Java с GC лучше, чем Rust?

Этот вопрос я впервые озвучил в Facebook-е четыре года назад. Прошло столько времени, а он, как мне кажется, все еще остается актуальным.

Вот, кстати, вспомнился еще один момент, который забавляет, когда Rust начинают противопоставлять Java и .NET-у.

Ведь в Rust-е же, по сути, такая же система управления памятью, как и в C++. Есть автоматическая память. Есть динамическая. В динамической есть аналог unique_ptr (Box), есть аналог shared_ptr (Rc, Arc).

Да, Rust следит за тем, чтобы вы корректно работали со своей памятью. Но ведь система не меняется. Либо ограниченное скоупом время жизни (автоматические переменные, Box), либо подсчет ссылок (Rc, Arc).

Но где же аргументы со стороны языков с GC о том, что подсчет ссылок -- это удар по производительности? Где убедительные бенчмарки, которые показывают, что стоимость аллокации в языке с GC -- это всего лишь инкремент одного указателя на вершину хипа? Где упоминание такой фундаментальной проблемы, как фрагментация памяти (которой, как все знают, подвержены поголовно все программы на C++)? Где напоминание о таком волшебном средстве, как compacting GC?

Где, где все те срачи, в которых сторонники Java и C# так яростно убеждали нас, что GC гораздо лучше для управления памятью, чем ручная работа? И не только с точки зрения безопасности. Но и с точки зрения производительности.

А?

[life.humour] "Время не щадит ни колес, ни дорог" (с)

Вот и меня на RSDN когда-то называли "тот самый eao197", а теперь "старпер Охотников" :)))

[prog.c++.humour] Как можно сделать хуже в попытке сделать лучше

Выдалась возможность потратить некоторое время на очистку кода RESTinio от (полу)забытых FIXME. Один из них выглядит так:

template< typename Extra_Data, typename Producer, typename Handler > class actual_router_entry_t : public router_entry_t< Extra_Data > {    //FIXME: compatibility between Extra_Data and Handler should be    //checked by static_assert. If it's possible.

Суть здесь в том, что когда пользователь задает обработчик входящего запроса (тип Handler), то должна быть возможность передать в этот обработчик ссылку на generic_request_handle_t<Extra_Data>. А если это не так, например, если пользователь забыл про свой Extra_Data и подсовывает обработчик для простого request_handle_t, то будет ошибка компиляции.

Ошибки компиляции в шаблонном C++ном коде не самое приятное чтиво и разбираться с ними то еще удовольствие. Поэтому хотелось поставить в код какой-то static_assert, который бы явно говорил программисту: у тебя Handler не дружит с твоим же собственным Extra_Data.

Однако сходу написать такой static_assert в свое время не получилось, поэтому в коде был оставлен FIXME: мол, когда-нибудь руки дойдут.

Вот, руки дошли. Попробовал написать такой static_assert.

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

Написал, удовлетворил компилятор, попытался проверить как этот новый static_assert себя поведет.

Под катом два лога с сообщениями об ошибках компилятора GCC 9.4 в режиме C++14. Первый -- это старая версия с FIXME и без static_assert-а. Вторая -- новая версия без FIXME и со static_assert-ом.

Лично мне кажется, что разобраться с ошибкой в старой версии проще. Потому что благодаря static_assert-у на несчастного пользователя вываливается намного больше совершенно ненужной информации, разобраться в которой, на мой взгляд, гораздо сложнее.

Ну и да, видимо, этот FIXME из кода просто удалю и не буду делать никаких static_assert-ов. Потому что сложность кода растет, а пользы от этого никакой :(

Upd. Тема получила неожиданное продолжение.

[prog.humour] В очередной раз пришло время штудировать собственную же документацию

Работаю над новой фичей. Для этого пришлось погрузиться в документацию по SObjectizer, в раздел по специфической и не самой тривиальной функциональности.

Документацию это писал сам, но уже не помню когда и как, поэтому читаю вообще как какой-то чужой текст.

Главная мысль: "Блин, надо бы основные моменты законспектировать..." :)

Шутки-шутками, но функциональность реально специфическая и редко используемая. Если бы не написал тогда документацию, то сейчас бы пришлось потратить в разы больше времени, чтобы вспомнить что это и как это готовить.

PS. За качество английского прошу не бить, пианист играет как умеет, google translate с grammarly на пару не смогли сделать лучше :)))

[prog.work.humour] Баян, но прекрасный

FB напомнил запись от 2016-го года. Она и тогда была баяном, но за все это время своей актуальности не утратила:

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

PS. Пока что выходит так, что своим клиентам мы гарантируем лишь безумное велосипедостроение, с остальным они и сами прекрасно справляются :)))

[prog.humour] Открыл статью о Rust, увидел пример кода, закрыл статью о Rust-е ;)

Иногда мне кажется, что у наиболее активных растоманов какой-то стокгольмский синдром в терминальной стадии :) Вот, например, свежая статья о Rust-а на Хабре: "Так ли страшен Rust, как его малюют", автор которой, будучи C#-разработчиком, активно защищает Rust в различных хабрасрачах.

Так вот, автор сперва приводит пример кода на Rust-е:

let mut guess = String::new(); io::stdin().read_line(&mut guess)     .expect("Failed to read line"); let guess: u32 = guess.trim().parse()     .expect("Please type a number!"); println!("You guessed: {}", guess);

А потом говорит, что можно сделать существенно проще и приводит вот такой аналог:

let mut guess = String::new(); io::stdin().read_line(&mut guess)?; let guess: u32 = guess.trim().parse()?; println!("You guessed: {}", guess);

Я, наверное, уже слишком старый и потихоньку начинаю выживать из ума. Поскольку мне не понятно, за счет чего второй пример "существенно проще" первого, ведь выполняется все ровно тоже самое и в той же самой последовательности. И разница состоит только в замене явного вызова expect с вменяемыми сообщениями на менее явные вопросительные знаки.

При том, что оба примера -- это попытка записать вот такой двустрочник на C#:

var number = int.Parse(Console.ReadLine()); Console.WriteLine($"You guessed: {number}");

В очередной раз убеждаюсь, что у Rust-а на данный момент две очень серьезных проблемы: ужасный синтаксис (то, что к нему можно привыкнуть не изменяет того факта, что синтаксис жуткий) и упоротые активные растоманы :)

---

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