Этот пост написан как попытка поделиться своим небольшим опытом ручной сборки наушников-вкладышей из закупленных на AliExpress комплектующих.
Уточню, что я из РБ, поэтому вещи, касающиеся стоимости и сроков доставки, могут сильно отличаться для РФ и других стран.
Посмотрел это демо-интервью:
Интересно. Впечатления из категории "Так вот оно чо, Михалыч" :)
За свою карьеру ни разу полноценного интервью не проходил, так уж получалось, что везде устраивался "по знакомству", так что если и были где-то разговоры, то только "за жизнь" просто чтобы познакомиться друг с другом. Познавательно посмотреть как это выглядит.
Но сказать хотел о другом.
Чувствуется, что я основательно отстал от жизни и закуклился в своем маленьком болотце.
Будь я на месте собеседуемого, роль которого играл Павел Филонов, то при такой общей постановке задачи я бы вообще до рисования каких-либо квадратиков не дошел бы.
В FB-шной ленте встретилась интересная ссылка: рассказ небезызвестного в узких кругах Эрика Реймонда (это который автор нашумевшего в прошлом Собор и Базар) о том, как он переводил reposurgeon с Python на Go: Notes on the Go translation of Reposurgeon.
Чтиво занимательное. Хоть там на языке вероятного противника и довольно многабукаф, но почитать стоит.
Намедни счетчик звездочек на GitHub-е для RESTinio взял еще одну сотню. И хотя GitHub-овские звездочки -- это нечто виртуальное, что на хлеб точно не намазывается, но все-таки хоть какой-то метрикой популярности/востребованности они являются.
Года три назад очередная сотня звезд вызывала гордость и доказывала, что мы делаем полезные вещи и двигаемся в верном направлении.
Сейчас ощущения сильно двойственные и с горьким привкусом. Караван стоит, звезды идут.
В 2021-ом году для RESTinio события развивались по худшему сценарию: внешнего финансирования мне найти не удалось, собственные ресурсы закончились, приходилось принимать решение о приостановке развития RESTinio.
Опасаясь этого я был готов готов работать над нашими OpenSource проектами за копейки, т.к. потеря денег -- это всего лишь потеря денег, а вот потерю времени восполнить невозможно. Но не сложилось. По итогу для проекта был потерян целый год.
Как будет в 2022-ом не берусь предсказывать. Надеюсь, что будет получше. Но именно с RESTinio все усугубляется тем, что там предстоит очень большой объем работы. Непросто будет обеспечить все это лишь собственными средствами. А искать где-то на стороне нет желания -- уже пробовал и пришел к выводу, что принцип "не верь, не бойся, не проси" спасает от многих разочарований и сильно экономит нервы.
В общем, пока все не просто. Желание побороться еще есть. Поскольку тут затронуты более серьезные материи, такие ощущение полноты от проживаемой жизни. Однако, это уже совсем другая история.
Есть у нас небольшой и пока еще не очень старый проект json_dto. Ему чуть больше пяти лет, но уже даже на таком небольшом временном интервале проявляется важный эффект: когда проект развивается, то ты неизбежно сталкиваешься с собственными просчетами, допущенными когда-то в прошлом.
Выпущенная давеча версия 0.3.0 как раз один такой просчет и устраняет.
Суть в том, что в json_dto есть функции mandatory, optional, optional_no_default, которые связывают подлежащее (де)сериализации поле объекта с информацией о том, как это поле должно выглядеть в JSON-е:
Лет 15 назад, если не больше, пришел к выводу, что C++ хорош лишь пока проектом занимается небольшая команда хороших и опытных разработчиков. Но если это правило нарушается, то случается то, о чем предупреждал старый программерский афоризм:
Если бы строители строили дома так же, как программисты пишут свои программы, то первый же дятел вызвал бы гибель всей цивилизации.
К сожалению, единственный статически-типизированный язык программирования, на который я бы хотел уйти с C++, -- это D. К сожалению потому, что мало того, что история развития D наводит на грустные мысли о его будущем, так еще и заказную разработку на D, полагаю, найти невозможно. А уж чтобы еще и работа была интересная, а не из категории "зато за это платят", так вообще... :(
Не смотря на то, что наша маленькая компания существует уже более пяти лет, мы редко выполняли работы для заказчиков, в основном же концентрировались на создании и продвижении собственных продуктов.
А в тех немногих случаях, когда мы делали что-то под заказ, то это было, в основном, возвращение к жизни и приведение в порядок уже существующих проектов. Где не приходилось выдумывать что-то новое, скорее нужно было просто копать отсюда и до обеда.
Работали мы по схеме time-and-material, т.е. выставляли счета заказчикам исходя из затраченного нами времени. И с подсчетом этого самого затраченного времени проблем не было как раз из-за работы в режиме "отсюда и до..."
Даже в случае, когда мы сделали проект, фактически, с нуля, все равно особых сложностей с подсчетом человекочасов не возникало. Т.к. основные проектные решения как-то сами-собой родились еще в процессе написания ТЗ.
Но вот в текущем заказном проекте (в котором мы также работаем по схеме time-and-material) недавно возникла ситуация, с которой мы пока еще не сталкивались. Потребовалось именно что родить идею.
А вынашивание и рождение идей -- это процесс недетерминированный и плохо контролируемый. Плюс к тому, сам я (как выяснилось) отношусь к людям с рывковым типом производительности, т.е. пока идея не выкристаллизовалась в голове, большую часть времени страдаю какой-то левой фигней.
На практике это выглядело так: садился с блокнотиком и начинал записывать какие-то мысли по поводу задачи. Первые минут 15 это более-менее получалось. Затем мысли начинали разбегаться кто-куда и еще минут 15-20 я с этим хоть как-то справлялся, возвращая их в нужное русло. Но в последующие полчаса все неизбежно скатывалось в состояние, когда в голове образуется неконтролируемая каша из разрозненных кусочков и обрывков, после чего наступало понимание что все, финиш. Блокнотик откладывался в сторону, а я тратил время на не имеющую отношения к задаче ерунду.
Таких подходов в рамках рабочего дня было, как правило два, иногда три. Что давало 1.5-2 часа в день про которые с чистой совестью можно было сказать, что они потрачены именно на нужды заказчика.
Однако, проблема заключается в том, что плотно заниматься чем-то другим в эти дни больше не получалось.
Как я понимаю, суть в том, что после часа безуспешного выкуривания бамбука с блокнотиком работа моего мозга над задачей не прекращалась, просто переходила на подсознательный уровень. Этот уровень оказывался загруженным, и на то, чтобы взяться еще за какую-то другую серьезную задачу уже не оставалось ресурсов. Т.е. ответить на email -- пожалуйста, сделать мелкий и тривиальный фикс -- сколько угодно, пролистать какую-нибудь статью или обсуждение в чатике -- без проблем. Но вот сесть и запрограммировать что-то или же написать кусок для новой статьи (или даже заметку в блог) -- вот это уже никак.
В итоге, на рождение идеи было затрачено чуть больше недели календарного времени. Фактического времени было залогировано 12 часов. На то, чтобы зафиксировать получившееся в тексте и затем дать заказчику необходимые разъяснения ушло 5 часов (все это в течении одного рабочего дня).
Что заставляет задуматься о том, а как же правильно оценивать трудозатраты по заказному проекту вот в таких случаях, когда приходится рожать идеи и это происходит подобным образом.
Фиксировать только время, которое было затрачено на сидение с блокнотиком -- это явная работа себе в убыток. С другой стороны, логировать по 7 или 8 часов в такие дни совесть не позволяет, ведь большую часть этого времени я, фактически, бил баклуши и гонял своих собственных тараканов. Да и не хочется провоцировать вопросы со стороны заказчика о том, неужели несколько страничек сумбурного текста потребовали 40 рабочих часов подготовки...
Вот впервые оказались в такой ситуации. Есть о чем подумать.
Когда занимаешься разработкой собственных продуктов, о таких вещах беспокоится не приходится.
PS. Раз уж пошла такая пьянка, поделюсь еще одним наблюдением. По нашему опыту выходит, что даже когда по заказному проекту идет плотная работа с минимумом задержек и отвлечений, все равно выходит где-то по 110-120 часов на человека в месяц. Максимум. Остальное время либо мы на что-то вынуждены отвлекаться, либо заказчик что-то не предоставил, либо ждем какого-то подтверждения/согласования или доступности чего-то/кого-то, либо еще что-то (типа болезни, мелких форсмажоров и т.п.). Из этого следует то, что нельзя подходить к расчету предполагаемой выручки по формуле Rh*160 (где Rh -- это почасовой рейт), в реальности выйдет, в лучшем случае, Rh*120.
PPS. Не знаю, зачем этот пост был написан. Возможно, кому-то, кто задумывается о начале собственного бизнеса, будет интересно прочитать о том, во что мы сами вляпываемся.
Подошло время очередного кинообзора. В этот раз будут впечатления о нескольких фильмах и одном сериале (плюс маленький бонус в конце).
Фильмы
Красное уведомление (Red Notice, 2021). Отличный развлекательный аттракцион, в котором смешались "Телохранитель жены киллера", "Индиана Джонс", "Сокровища нации" и даже знаменитая белка из "Ледникового периода". Но ни в коем случае не следует искать в этом кино чего-либо серьезного, это чистой воды развлечение.
Финч (Finch, 2021). Неплохо сделанный и, в общем-то, прикольный фильмец. Но очень уж прямолинейный, предсказуемый, затянутый и, поэтому, унылый.
Небо (2020). Красиво снято. Но саму по себе историю рассказали настолько плоско и неинтересно, что прямо обидно. Да и количество пафоса зашкаливает ну совсем уж неприлично. А вот увидеть в эпизодической роли Владимира Онокоя было неожиданно :)
Веном 2 (Venom: Let There Be Carnage, 2021). По сравнению с первой частью сделано откровенно халтурно. Если первый фильм зашел, то можно и вторую часть глянуть, но без ожиданий чего-то стоящего.
Шан-Чи и легенда десяти колец (Shang-Chi and the Legend of the Ten Rings, 2021). Очередное кино про очередной кусочек вселенной Marvel. Может быть интересен тем, кому нравятся фильмы по комиксам от Marvel, да еще и сдобренные восточными единоборствами. В принципе, можно и посмотреть, благо юмор в фильме не позволяет воспринимать его всерьез.
Армия воров (Army of Thieves, 2021). Красиво снятая фигня.
Амнезия (Awake, 2019). Нудная и затянутая муть.
Сериал
Основание (Foundation, 2021, первый сезон). Ну очень красиво и качественно снято. Местами прям казалось, что в сериале графон сильно получше, чем в некоторых нынешних "блокбастерах". И по началу даже более-менее неплохо заходил. Была слабая надежда, что авторы попытаются удержаться в рамках научной фантастики. Но нет, без суперспособностей (предсказания, околопророческие видения) у ключевых героев все равно не смогли обойтись. Поэтому досматривал только чтобы посмотреть, закончат ли первый сезон на каком-то логическом финале (или хотя бы полуфинале).
Отдельно выскажусь по двум "знаковым" премьерам, которые не очень-то и хотелось смотреть, но все таки посмотрел (что поделать, смотреть сейчас вообще нечего, вот и приходится...)
Завершающий фильм бондианы с Крейгом. Боюсь, это самый слабый фильм про Бонда за последние лет 20-25. По впечатлениям, так вообще как будто смотришь что-то из бондианы времен 1970-х годов. Ну и главный вопрос: неужели владельцы бондианы зарезали курицу, которая несла им золотые яйца? А если нет, то как они собираются выруливать после смерти своего главного героя?
Новая "Дюна" от Вильнева. Ожидал унылое говно, его же и получил. И здесь все закономерно. Во-первых, сам литературный источник, как по мне, так откровенно уныл. Во-вторых, явственная попытка растянуть хронометраж дабы запустить многосерийный проект. В общем, звезды сошлись. Да еще и тетенька в качестве Лиет Кайнс... Понятно, что современная повесточка, но все-таки. Хотя вот визуальная и аудио-составляющие отличные, этого у Вильнева не отнять.
Мы тут выкатили очередной релиз RESTinio. Ничего серьезного, но исправлена проблема при использовании RESTinio и fmt-8.0.1 под C++20. Так что теперь RESTinio может спокойно применяться и в C++20, хотя все еще остается проектом C++14.
Сама по себе новость мелкая и вряд ли заслуживала бы отдельного поста. Но есть два момента, на которые мне самому хочется обратить внимание.
Первый момент связан с тем, что уходящий год оказался для наших OpenSource проектов очень тяжелым. Внешнего финансирования для его развития мы не нашли, открытые разработки пришлось приостановить. Вообще не думал, что в 2021-ом получится хоть какие-то обновления выпускать.
В этом плане даже такой мелкий релиз лично для меня уже оказывается знаковым. Таки живем, таки творим (как бы высокопарно это не звучало).
Боюсь загадывать, но может быть какие-то небольшие обновления получится сделать и для SObjectizer, и для json-dto. По крайней мере есть хотелки и надежда, что под их реализацию найдется возможность. А для 2021-го года само по себе наличие надежды -- это, блин, ну очень редкое явление.
Второй момент связан с тем, что при разработке RESTinio мы используем SObjectizer в некоторых тестах, где требуется проверки в многопоточных сценариях. И SObjectizer в самом RESTinio применяется уже довольно старый, еще из ветки 5.5.
Так вот, я был сильно удивлен тому, что SObjectizer-5.5 спокойно и без каких-либо проблем собрался и заработал под C++20.
Вообще, с годами, стал относиться к вопросам совместимости между версиями гораздо более трепетно. Решение делать SO-5.6 с серьезным нарушением совместимости до сих пор выглядит неоднозначно. С одной стороны, это было нужно, т.к. в ветке 5.5 накопилось всякого, что уже не удавалось никак развязать. С другой стороны, лишать пользователей возможности просто так перейти на новую версию, без необходимости менять что-то в своем коде, не есть хорошо.
И тот факт, что пользователи SObjectizer-5.5, которые не имеют возможности перевести свой софт на 5.6/5.7, могут продолжать жить с SO-5.5 и под C++20, меня сильно радует. Эдакое теплое чувство внутри.
Подошло время очередного кинообзора. Как обычно, в начале списка фильмы, которые понравились больше, а в конце -- самый шлак на который не стоит тратить свое время. Плюсом упоминание об одном фильме, который я не решился включить в рейтинг: он вам либо очень понравится (если вы любитель жанра), либо вызовет отторжение, если это не ваше кино.
Мистериум: Эффект Марко (Marco effekten, 2021). Как я понимаю, это продолжение неплохой датской серии детективных фильмов. Но уже с другими актерами на главных ролях из-за чего часть обаяния этой картины уже пропадает. В целом по атмосфере очень похоже на то, что уже было. А вот по сюжету как-то слабовато, на мой взгляд.
Безжалостный (Bulhandang: nappeun nomdeului sesang, 2017). Вроде бы и неплохо, есть внезапные твисты, которые делают сюжет интересным. Но смотреть тяжеловато, т.к. для европейского зрителя и актеры практически на одно лицо, и имена героев не запоминаются. С учетом переплетенных сюжетных линий сложно следить за повествованием.
Начать с нуля (Cambio tutto, 2020). Как по мне, так проходной фильм с довольно-таки предсказуемым сюжетом и плоско-картонными персонажами. Все держится на актрисе в главной роли, она справилась мастерски. Однако, на фоне всего остального нынешнего шлака это кино вполне можно и посмотреть.
Старый Генри (Old Henry, 2021). Затянуто. Проматывал наиболее занудные моменты. Если бы не это, то фильм был бы прекрасным образчиком того, как можно снять хорошее кино за недорого.
Мадам Парфюмер (Les parfums, 2019). Это не комедия, ни драма, ни мелодрама. Просто милый фильм с хорошими актерами. Можно глянуть если больше смотреть нечего. Но и ждать от него не нужно ничего.
Новый порядок (Nuevo orden, 2020). Мне не зашло. Такое ощущение, что авторы хотели сделать шок-контент, но пригламуренный. Получилось лайт-жестокость ради лайт-жестокости.
Клыки ночи (Night Teeth, 2021). Уж не знаю, как можно было сделать боевик про вампиров настолько скучным и унылым, но тут это получилось.
Хороший, плохой, коп (Copshop, 2021). Фильм-разочарование. Отличный трейлер, интересная фабула. Но воплощение -- это какой-то треш и отстой. Если не хотите после просмотра отплевываться и задаваться вопросом "Как можно было испоганить такую завязку?", то это кино лучше не смотреть.
Фильм вне категории: Поездка (I onde dager, 2021). Так и не понял, что это было. Для черной комедии он слишком серьезен, для Ъ-шного кровавого слэшера -- слишком ироничен и саркастичен. Лично для меня это треш, угар и содомия, чуть ли не в прямом смысле слова. Потраченного времени жаль. Но наверняка кому-то такое кино зайдет.
Продолжаю тему бюджетной аудиофилии. Поделюсь неожиданным для себя открытием, может быть другим чайникам, вроде меня, будет интересно и полезно.
Среди ЦАПов, о которых рассказывалось в предыдущем посте серии, было упоминание о безымянном ЦАПе на базе когда-то ТОПового чипа от Cirrus Logic CS4398 и усилителе TDA1308. Правда, он, как оказалось, не совсем безымянный. На просторах Aliexpress он известен как CM108. Впрочем, речь не о названии, а о звучании.
Изначально этот ЦАП показался мне излишне светлым. С "темными" накладными и полноразмерными наушниками (вроде KOSS Porta Pro) он звучал нейтрально, а вот с 32-омными вкладышами басов практически не было. Так что пользоваться им не смог. Но и на продажу выставить рука не поднялась, т.к. ну очень уж драйвовая у него подача.
Так он и лежал у меня без дела, пока не решился на эксперимент с покупкой высокоомных динамиков (выбирал между 120- и 130-омными моделями). Но дабы не выбросить деньги понапрасну сперва проверил, а тянут ли мои ЦАПики наушники с импедансом больше 100ом.
Взял т.н. impedance plug (это такой штекер-переходник для 3.5-мм разъема с дополнительным сопротивлением внутри) на 80ом и стал пробовать звучание ЦАПов со своими основными на тот момент 32-омными вкладышами (т.е. суммарное сопротивление составляло ~110ом).
Все ЦАПы, даже самые дешевые, спокойно "раскачивали" такую связку.
Но самым неожиданным стало то, что CM108 на такой связке стал звучать гораздо ровнее. Он практически перестал быть светлым, стал почти что нейтральным и сбалансированным. Басы зазвучали совсем по другому. Скорость, упругость и хлесткость осталась, но к ним теперь добавилась глубина, протяженность и объем.
"Ничего себе!", подумал я. И стал ждать посылки со 120омными динамиками.
Когда посылка пришла и новые наушники были собраны, то попробовал их в первую очередь с CM108.
Результат очень понравился. Этот ЦАП, даже не смотря на то, что он поддерживает всего 16bit/48kHz, сразу же перешел в категорию любимых. Настолько интересный, детальный, глубокий и драйвовый звук он выдает.
А давеча решил подключить 120омные наушники к ЦАПу через 80омный impedance plug.
Результат стал еще немного лучше. Как будто ручку регулировки "четкости" выкрутили еще на пару-тройку делений. Не могу сказать, что басов стало еще больше. Но вот как будто всяких мелких фоновых шумов вообще не стало и за счет этого каждый звук и отзвук стали еще разборчивее.
В общем, неожиданное и приятное открытие от устройства, которое оставил просто так, на всякий случай.
К чему я это все рассказал?
Эксперименты с повышением сопротивления ваших наушников могут привести к интересным результатам.
В качестве дополнительных источников информации к размышлению пару статей из Интернета: Правда или нет? Высокоомные наушники звучат лучше и На что влияет сопротивление наушников.
Напоследок поделюсь некоторыми своими текущими соображениями, которыми бы я руководствовался бы сейчас, если бы мне потребовалось выбрать для себя новый ЦАП.
Сейчас бы я обратил внимание на описание усилителей, которые используются в ЦАПе кроме основного чипа. Если в "свистке" производителем указывается только ЦАП-чип (например, CS43191), то такой "свисток" я бы уже не рассматривал. А вот если бы кроме ЦАПа указывалось бы, что применяется дополнительный усилитель (или даже несколько), то это стало бы для меня весомым плюсом.
И не потому, что я разбираюсь в том, как меняет звук какой-нибудь OPA1612, TDA1308 или AD8397. Нет, в этом как раз не разбираюсь.
Но зато сумел убедиться, что когда дополнительный усилитель в "свистке" есть, то звук получается "взрослее". В частности, басы получаются глубже и текстурнее.
С другой стороны, за это придется расплачиваться повышенным энергопотреблением. Ко мне еще не попадали экономичные ЦАПы с хорошим звуком, да и в отзывах/обзорах про такое слышать не приходилось.
Угораздило ввязаться в Хабросрач под статьей о грядущем C++23. Теперь сожалею о времени, потраченном на это. Наверное, часов шесть, если не больше, убито без толку.
Пытался аргументированно донести до собеседников свои мысли. Подозреваю, что безрезультатно.
Плюс еще и нахватал минусов на комментариях. Хорошо, что у меня есть некий запас кармы от статей, так что возможность полноценно присутствовать на Хабре сохранилась, а то ведь можно было и в read-only улететь. Просто за то, что почему-то решил, что имеешь право собственное мнение высказывать.
С некоторой ностальгией вспоминаются гораздо более эмоциональные и злые, но намного более свободные срачи на LOR-е. Все таки возможность напрямую назвать малолетнего дебила "малолетним дебилом" (с) -- она большого стоит. Ибо если кто-то не ценит чужое время и ведет себя как идиот, то об этом не грех и прямо в лицо сказать.
Да, возможность называть дебилов дебилами на LOR-е была ценна. К сожалению, LOR скатился в совсем уж откровенное днище. В том числе именно из-за этой возможности. Но, как мне думается, главную роль в этом сыграло отсутствие препятствий для анонимов. Когда ресурс допускает появление анонимных комментариев в духе "а в рот у меня возьмешь?", то это уже не ресурс, а помойка. Вменяемых людей, имхо, на LOR-е остались единицы.
В этом плане RSDN в свое время повел себя умнее. Там вроде как давно анонимные комментарии запретили. Поэтому на RSDN-е остатки былого величия все еще сохраняются и некоторые дискуссии там получаются, если не интересные, то хотя бы содержащие полезную информацию. К сожалению, время RSDN-а, имхо, давно ушло.
Хабр же, походу, идет своим уникальным путем, но с печальными перспективами, боюсь. Ибо есть в кармическом механизме Хабра пара вещей, дающих гремучую смесь.
Во-первых, карма может уходить в минус. Из-за чего хабровчанин превращается в человека второго сорта.
Во-вторых, минусовые оценки на Хабре анонимны. Т.е., ты можешь портить другому хабровчанину карму безнаказанно. Не суть важно почему ты это делаешь: не согласен с тем, что он пишет, или же у тебя просто личная неприязнь. Написал человек пять комментариев, ты каждому из них по минусу влепил и... Тебе от этого ничего, а человек в read-only режиме.
Кстати говоря, на RSDN-е с минусовыми оценками было лучше -- там видно, кто именно минусует. И, когда тебя минусуют одни и те же персонажи, то тебе легче разобраться -- откровенную ли муть ты несешь искренне ли заблуждаешься или же это просто личное.
Сейчас Хабр популярный ресурс, на котором можно публиковать статьи на разные темы, чем мы уже с успехом пользовались. Подозреваю, что не только мы. Посему жаль, что Хабр сохраняет свою кармическую систему. По факту, там в комментариях точно такое же меряние пиписьками и обзывание "сам дурак", но только прикрытое чуть более толстым покрывалом "приличий", чем на RSDN или LOR-е. С перспективами превратиться в такой же отстойник, как и LOR.
На вынесенную в заголовок тему заставила задуматься статья: С++23 — feature freeze близко. Несколько моих комментариев к ней и к сопутствующим материалам в FB: раз, два, три.
Есть ощущение, что С++ уже не просто подошел к пределу моих умственных способностей, но и сильно их превзошел. Подозреваю, что моих мозгов не хватит, чтобы освоить C++20 и C++23 на более-менее приличном (для себя) уровне.
И винить здесь C++ бессмысленно. Он просто живет и эволюционирует. Следовательно, он будет усложняться и дальше (на эту тему я когда-то писал большую статью, продолжаю находиться при мнении, что это естественный процесс с которым ничего не поделаешь).
Невольно задумаешься о том, а как должны были бы развиваться события, чтобы появилась какая-то надежда на горизонте?
Сейчас я бы присмотрелся к сценариям, которые в мире Java пытаются претворить в жизнь Scala, Ceylon и Kotlin. Т.е. на базе уже существующей экосистемы создать инструмент, который бы был удобнее Java, но позволял бы использовать то, что в Java уже есть.
Как по мне, так вместо введения тех же модулей в C++20, было бы гораздо перспективнее сделать какой-то новый язык, который мог бы бесшовно интегрироваться с уже существующим C++ным кодом.
Грубо говоря, какая-то спроектированная на современном уроне Vala, которая бы, в примитивном сценарии, просто транслировалась в C++ный код (например, на C++17) и компилировалась бы далее обычным C++ным компилятором. И из которой можно было бы использовать C++ные библиотеки напрямую, без необходимости писать какие-то обертки (ну или с минимальными усилиями по написанию таких оберток).
И уже в этот новый диалект можно было бы добавить фичи, которые сложно, если вообще возможно добавить в C++: модули, более дешевые и предсказуемые исключения, константность по умолчанию, семантика перемещения по умолчанию, алгебраические типы данных и паттерн-матчинг, взятые под контроль указатели, лаконичный и непротиворечивый синтаксис и т.д., и т.п.
Не знаю, насколько такой сценарий реален. Но он, как мне думается, дает возможность и продолжить использовать уже накопленный C++ный код, и писать новый код на более простом в изучении и использовании языке (возможно, даже более безопасном). И при таком развитии событий даже не сильно умные люди, вроде меня, могли бы нормально пользоваться привычными инструментами.
Подошло время очередного кинообзора. По традиции вначале списка идут фильмы, которые понравились больше. Затем те, что понравились меньше. Правда, в этом обзоре фильмов немного: новинок почти нет, заслуживающих внимания из них еще меньше. Так что в этот раз вот так.
Главный герой (Free Guy, 2021). Бодренько и задорно. Но шаблонно и как-то по детски.
Бык (2019). К достоинствам фильма можно отнести то, что там очень хорошо передана атмосфера середины 1990-х и то, что авторы не сделали хэппи-энд в розовых соплях. Сам же сюжет, имхо, вторичен и следить там особо не за чем. Смотреть этот фильм можно, например, если о "святых 1990-х" почему-то остались радужные воспоминания.
Кейт (Kate, 2021). Еще одна попытка снять "Джона Уика в юбке". Наверное, пока что наиболее динамичная. Но все равно в происходящее не верится от слова совсем.
Исчезнувший (My Son, 2021). Мне не зашло. Первая половина фильма нудная и унылая, финал невнятный. Посмотреть можно разве что если больше вообще смотреть нечего.
Виновный (The Guilty, 2021). Вторичная и, прямо скажем, никакая копия датской картины 2017. Если видели оригинал, то на копию можно не тратить время. Если не видели, то, имхо, лучше посмотреть исходный вариант.
Отдельно по поводу новой "Дюны" Вильнева. Не смотрел. Пока не планирую. Во-первых, не фанат литературного первоисточника. Во-вторых, эта "Дюна" рассказывает только начало истории. Потратить 2.5 часа на то, чтобы посмотреть завязку, а потом ждать продолжения не пойми сколько времени... Ну как-то странно это. Так что либо дождусь, пока фильм появится в подписках IVI или Kinopoisk.HD, либо же вообще буду ждать выхода продолжения.
Вынужденное продолжение темы, поднятой в предыдущем посте. Код, который там был показан, пришлось усложнить еще больше. Сегодня попробую рассказать почему это произошло и что именно получилось на данный момент.
Сегодня хочу немного поговорить о своем взгляде на то, как следует писать код. Можно даже сказать, что речь пойдет о философии, сформировавшейся за почти три десятилетия, что я в программизме.
Суть в том, что при написании кода есть отдельный класс ошибок, вызванных невнимательностью. Ну, например, в POSIX есть функция pipe, которая создает анонимный пайп. В качестве параметра в эту функцию передается указатель на массив из двух int-ов. В случае успеха в этот массив будет помещено два хэндла: первый для чтения из пайпа, второй для записи в пайп.
Проблему я вижу в том, что далее программист должен оперировать индексами 0 и 1 для того, чтобы взять нужный хендл. И здесь мы начинаем полагаться на то, правильно ли программист запомнил порядок следования хендлов в результирующем массиве. Не ошибся ли он используя индекс 0? Вдруг в момент написания кода он подумал, что 0 -- это хэндл для записи? Или он просто опечатался?
Достаточно часто этот класс ошибок провоцируется такой штукой, как последовательно идущими аргументами функции одного типа. Например, два-три-четыре и более int-ов подряд. Вот, скажем:
|
int x = ...; int cx = ...; int y = ...; int cy = ...; define_rect(x, cx, y, cy); |
Корректен ли вызов define_rect? Может быть он должен был быть записан как:
|
int x = ...; int cx = ...; int y = ...; int cy = ...; define_rect(x, y, cx, cy); |
?
SObjectizer давно уже достиг состояния, когда его возможностей хватает для закрытия наших потребностей. Да и потребностей у нас сейчас заметно поменьше, чем в былые годы. В прошлом году мы задействовали SObjectizer только в aragata. В этом году относительно недавно стали его применять в разработке прототипа нового заказного приложения. Что из этого получится и будет ли SObjectizer применяться там впоследствии -- открытый вопрос, на который сейчас сложно дать ответ. Однако же, пока что возможностей SObjectizer (+so5extra) и в этом новом проекте хватает.
Тем не менее, раз базовые потребности закрыты, а проект вполне себе жив, то вольно-невольно задумываешься о том, а куда его можно было бы двигать дальше. С учетом как нашего прошлого опыта, так и текущих впечатлений от применения SObjectizer в новой для нас области.
В результате таких размышлений появилось две идеи, которые хочется зафиксировать. Просто чтобы было где-то записано, чтобы можно было к этому вернуться впоследствии. Ну и может быть кого-то эти вещи заинтересуют и кто-то сочтет возможным поделиться своими впечатлениями на этот счет.
Итак, милости прошу под кат тех, кому интересно следить за SObjectizer-ом.
Продолжу рассказ о своей попытке приобщиться к аудиофилии в рамках скудного бюджета. В этот раз речь пойдет о таких важных приспособлениях, как портативные USB-ЦАП (они же "свистки"), поделюсь совсем краткими впечатлениями о побывавших у меня ЦАПах и распишу свои соображения на тему того, как следовало бы выбирать USB-ЦАП.
Однако, двести.
Прошу простить мне то, что пытаюсь выдать какие-то две жалких сотни звезд за некое достижение. Это, действительно, не о чем на фоне десятков тысяч звед у действительно популярных и востребованных проектов.
Но с учетом того фиаско, которое я потерпел за годы безуспешных попыток популяризации SObjectizer-а, предоление порога очередной сотни для меня самого выглядит фантастически. Пару лет назад это казалось совершенно недостижимым.
Пользуясь случаем обозначу текущий статус проекта.
SObjectizer/so5extra не умер. Проект живет. Проект используется. Причем, наверное, вне нашей крохотной компании он используется даже гораздо шире. Хотя информации о том, где и как SO-5 применяется, по прежнему, очень мало. Какие-то сведения до нас доходят отрывочно, случайно и эпизодически. Так, несколько месяцев назад узнал, что SObjectizer применяют на бакэнде в 2GIS.
На данный момент развития проекта нет. Главная причина в том, что для нас самих в SObjectizer-е есть все, что нам сейчас нужно. Добавлять что-то еще просто "шоб было" нет ни смысла, не ресурсов. Так что новая функциоальность в SO-5 появится либо тогда, когда нам самим в нем что-то потребуется, либо если кто-то у нас закажет доработку SObjectizer-а.
А так на вопросы пользователей мы отвечам, на issue реагируем. Баги, если таковые находятся, исправляем (как раз на выходных всплыл баг в so5extra, и он уже пофикшен).
Поэтому если кто-то сомневается пробовать ли SObjectizer или не пробовать, то не сомневайтесь, пробуйте.
Тем же, кто попробовал, большое спасибо за правильный выбор ;)
В последнее время много рефлексировал на тему того, как можно было бы охарактеризовать наш подход к работе на основании того, что и как делалось нами в последние пять лет.
Похоже, что из афоризма "Выберите любые два" нас можно описать как: не быстро, недорого, качественно.
Ключевое -- это качественно. Делать абы как совесть не позволяет, а для качественного результата нужно время. Да и не только совесть, уже просто руки по другому не могут. Когда ты всю карьеру занимался проектами, которые поднимаются с нуля, а затем развиваются и работают годами, то оно как-то само собой получается: сделаешь тяп-ляп, потом сам же и отгребешь, да еще в самый неподходящий момент. Отсюда и "не быстро".
А из того, что сроки удлиняются, стоимость часа работы снижается, что и ведет к "недорого".
Хотя, судя по тому, что сейчас пишут в Интернетах по поводу уровня зарплат в той же России, мы, похоже, последние, кто еще "недорого".
Подошло время очередного кинообзора. В этот раз в него попали и несколько сериалов. Как обычно, в начале списков идет то, что понравилось больше.
Фильмы
Батя (2020). Хорошее кино. Местами, как по мне, очень трогательное. Возможно, оно было бы еще лучше, если бы на место Стаса Старовойтова взяли бы умеющего играть актера.
Кроваво-красное небо (Blood Red Sky, 2021). Не ожидал, что в области фильмов про вампиров можно снять что-то свежее и интересное. Да еще от Netflix. Но тут вот звезды сошлись. Любителям жанра нужно посмотреть.
Воспоминания (Reminiscence, 2021). Идея хорошая, снято красиво, смотреть за развитием истории было интересно. Но вот розовых соплей что-то слишком уж много.
Опасный элемент (Radioactive, 2019). В принципе, хороший фильм, смотреть было интересно. Разве что обилие флешбэков несколько портило впечатление.
Отряд самоубийц: Миссия навылет (The Suicide Squad, 2021). Лично мне отлично зашел. Ожидал треша и угара, их и получил. Джеймс Ганн снял не супергеройское кино, на которое претендовала унылая первая часть, а мастерский стеб на весь этот жанр.
Кодекс киллера (The Protégé, 2021). Еще одна попытка снять "Джона Уика в юбке". Немного успешнее предыдущих. По крайней мере бодренько. Хотя с перипетиями сюжета и мотивацией героев явно что-то намудрили или налажали (скорее и то, и другое), так что я лично не очень понял что там и почему. Но ведь боевики смотрят не ради сюжета ;)
Малышка (Sweet Girl, 2021). Смотреть до какого-то момента было интересно. И твист неплохой сделали ближе к завершению. Но блин, финальная разборка в фонтане выглядит настолько невероятно, что это напрочь убивает все хорошие впечатления от фильма.
Маша (2020). Добротно снято и история неплохая. Но 2/3 фильма показывают какую-то придурошную малолетку, которая своей идиотией раздражает без меры, а в конце показывают убогий и не объясненный толком финал, после которого остается куча вопросов на тему "а что же было между двумя ключевыми историческими точками?"
Сериалы
Иерро (Hierro, 2019). Первый сезон. Интересно. Хотя слишком быстро становится понятно что к чему. И развязка какая-то несуразная.
Исповедь (A Confession, 2019). Интересно было смотреть за тем, что происходит. Но не столько из-за качества самого сериала (тут все достаточно средненько и бюджетненько), сколько из-за того, что это экранизация реальных событий.
Харлан Кобен. Невиновен (El inocente, 2021). Отлично снят. Необычный способ подачи материала (серии начинаются от лица разных персонажей). Интересно следить за развитием событий. Но постепенно начинают накапливаться несуразности и ближе к концу все происходящее начинает вызывать вопрос "Что за хрня здесь творится?" В общем, по итогу сериал разочаровал.
Отдельно упомяну совершенно неожиданный "Солнцепек". ИМХО, посмотреть его нужно. Но вот оценивать как кино подобные картины еще рано.
Сегодня какой-то спамер стал донимать меня комментариями с левыми ссылками.
Пришлось включить премодерацию комментариев. Так что если вы написали комментарий, а он все никак не появляется, то это либо из-за того, что у меня пока еще не дошли руки до модерации, либо я пока еще не получил от Blogger-а уведомления об ожидающем модерации комментарии. Прошу понять и простить.
Заодно выяснилось, что Blogger с начала этого года уже отправил несколько комментариев на премодерацию, но мне об этом забыл сказать. В связи с этим приношу извинения тем людям, чьи комментари опубликовались только сегодня.
С конца прошлой недели занимаюсь проектированием механизма, посредством которого процесс-producer смог бы передавать через shared memory информацию одному или нескольким процессам-consumer-ам. Вроде бы придумалось какое-то решение, которое выглядит рабочим. Данный пост является попыткой еще одной проверки этого решения: если получится упомянутый механизм внятно описать словами, то есть хорошая вероятность, что он будет воплощен в коде.
Может быть кому-то будет интересно посмотреть на чужой велосипед. Вдруг кто-то из читателей обнаружит незамеченные мной косяки или вообще ткнет пальцем в готовое решение, которое я, в силу узости кругозора, тупо не заметил.
В общем, всех заинтересовавшихся приглашаю под кат.
На HackerNews появился и обсуждается плач Ярославны Вальтера Брайта на тему исключений. Он там перечислил с десяток причин своей нелюбви к исключениям. Желающие могут ознакомиться сами.
Я же выделю два пункта из списка Брайта:
5. it is hard to write exception-safe code
6. very few understand how to write exception-safe code
Уже многократно говорил в своем блоге, но вынужден повторить еще раз: меры по написанию надежного и устойчивого кода в присутствии исключений точно такие же, как и при использовании кодов возврата.
Поскольку причина проблем в том, что происходит преждевременный выход из текущего скоупа и в коде нарушаются инварианты. Т.е. либо мы не освободили какие-то ресурсы, либо не закончили какую-то операцию, либо наши данные остались в несогласованном состоянии. Происходит ли выход из-за throw или из-за return-а -- не суть важно.
Еще раз: причина выхода из скоупа не важна, важно то, что мы куда-то вылетаем не доведя свою текущую цепочку действий до логического завершения.
И, как показывает практика, у многих программистов (включая меня самого) не очень хорошо с предсказанием последствий такого преждевременного выхода. В этом-то как раз и есть корень зла. Мы, люди, не особо хорошо справляемся с перебором возможных вариантов "а что, если здесь случится какая-то херня?" Это и есть основополагающая штука. А не throw, return или goto err.
У хейтеров исключений существует иллюзия о том, что если они будут писать код в стиле:
r = do_something();
if(-1 == r) {
revert_changes();
return -1;
}
то их программы будут надежнее, чем при использовании исключений.
По моим наблюдениям это, мягко говоря, не так.
Во-первых, большинство программистов очень плохо справляется с написанием кода, в котором требуется скрупулезное внимание к деталям. Плюс написанный в таком стиле код запросто может стать слишком объемным. Пример можно увидеть вот в этом моем посте шестилетней давности. А объем кода -- это дополнительные трудозатраты при сопровождении. Потребовалось добавить какую-то операцию, требующую отката в случае ошибки, и... И нужно вручную просматривать и модифицировать все места, в которых этот откат может потребоваться.
Да, я знаю, что идиома goto err сильно облегчает жизнь. Но это именно что средство для уменьшения боли, а не ее устранения.
Во-вторых, если вы не пишете совсем уж низкоуровневый код, в котором нужно оценивать во что выливается каждая строчка, а свободно используете динамическую память и разнообразные контейнеры, то вы просто задолбетесь вручную проверять успешность завершения каждой вовлеченной в ваши действия операции. Пример приводил совсем недавно.
Так что не буду спорить со всем перечнем претензий Брайта к исключениям, но вот эти два пункта -- это явно какая-то херня. При всем моем уважении к тов.Брайту.
Олимпиада в Токио закончилась почти неделю назад, а я только-только собрался с мыслями и желанием что-то высказать по этому поводу.
Общие впечатления лично у меня достаточно грустные. И не по поводу скандалов вокруг происходившего до и во время Олимпиады. А по поводу самого факта существования и значимости Олимпиады в современных условиях и в её современном виде.
Главное впечатление -- МОК своими попытками сделать Олимпиаду привлекательнее и охватить как можно большую аудиторию (в том числе и расширив список видов спорта) девальвировал значимость Олимпиады как главного спортивного события.
ИМХО, в Олимпиаде нужно оставить только те виды спорта, для которых:
Например, я не вижу смысла в сохранении тенниса в программе Олимпиады. Масштаб и сложность победы на любом из 4-х турниров Большого Шлема, имхо, в разы круче, чем то, что можно было увидеть на Олимпиаде. Тоже самое можно сказать и о футболе.
Или присутствие скейтборда или некоторых разделов МТБ в программе Олимпиады. Почему-то эти виды спорта мне напоминают анекдот про седых байкеров и молодых мотоциклистов: "А что с вами знакомиться? Вы же каждый год новые".
Прошу понять меня правильно. Я не про то, что скейтборд -- это не спорт или что это не такой серьезный спорт, как другие. Я про то, что в некоторых видах спорта смена лидеров происходит слишком часто. И победа на Олимпиаде не есть итог планомерной подготовки спортсмена к главному старту четырехлетия. Тут скорее дата проведения Олимпиады накладывается на текущую расстановку сил в конкретном виде спорта. Попала Олимпиада на 2021 -- один чемпион. А случись в 2020-ом, оказался бы другой.
Побочным эффектом того, что набор видов спорта на Олимпиаде расширяется, становится то, что сокращается число спортсменов, которые могут принять участие в Олимпиаде в конкретном виде.
Так, если в 1960-1970-е годы в боксе в некоторых весовых категориях участвовало больше сотни боксеров (емнип), то сейчас их всего-то 32. Да, система получения олимпийских лицензий обеспечивает присутствие среди этих 32-х самых ТОПовых спортсменов. Но все равно, если в 1960-х победитель игр должен был пройти путь из 6-7 поединков с самыми разными спортсменами, то сейчас этот путь заметно короче.
В общем, текущее направление движения Олимпиад мне не нравится (и это в расчет не берутся разные политические игры, которые оказывают влияние на Олимпиады). И если ничего не изменится, то лет через 12-16, боюсь, Олимпиада превратиться в какое-то заурядное событие, в котором с интересом можно будет посмотреть всего лишь несколько видов спорта.
Изменить ситуацию, на мой взгляд, можно было бы пересмотрев список видов, уже включенных в Олимпиаду (оттуда наверняка что-то можно выбросить, например, теннис, футбол, шоссейные велогонки), а также изменив критерии отбора новых видов для включения в Олимпийский турнир. Скажем, вот такие критерии:
В общем, видов спорта поменьше, спортсменов в каждом виде побольше.
Формулируя такие критерии я понимаю, что любимый мной дартс никогда не станет олимпийским видом спорта. Как и снукер. Но, как по мне, так это и к лучшему. Тот же дартс не станет лучше, если попадет на Олимпиаду.
Даже до меня долетел шум вокруг компании Xsolla с весьма необычным обоснованием необходимости уволить 150 человек. Для тех, кто как и я, в танке, вот несколько материалов на тему:
Xsolla уволила часть сотрудников пермского офиса после «анализа их активности» в рабочих чатах,
Xsolla предположительно уволила ряд сотрудников в Перми после анализа их рабочей активности,
«Мы формально еще никого не уволили. Мы сказали: компания вас не ценит» Интервью основателя Xsolla Александра Агапитова, который объявил, что разом увольняет 150 «невовлеченных» сотрудников (и тут началось).
Больше всего у меня от этой истории подгорело из-за того, что 99.9% обсуждающих эту тему a) не имеют к ней никакого отношения и b) не почувствуют на себе никаких последствий.
Ну а раз так, то позволю и я себе пару циничных высказываний.
Во-первых, это решение собственника компании. Имеет право.
Компания его, мало кто в состоянии осознать сколько всего владелец пережил и на что шел, чтобы сейчас его детище было таким, какое оно есть. И если владелец считает, что нужно пойти на сокращение 150 человек, то он имеет на это право. Как и на то, чтобы отбирать людей на увольнение по любым понравившимся ему критериям. Вне зависимости от того, что об этих критериях думают сами увольняемые или праздная публика, которая исходит на лучи известной субстанции в Интернетиках.
Так что еще раз, главное: он владелец, он может делать что хочет. В этом-то и весь смысл.
Во-вторых, нахожусь при мнении, что публика в Интернетиках так сильно возбудилась потому, что 99% возбудившихся -- это наемные сотрудники на зарплате. И часть из возбудившихся отчетливо понимает, что собственники бизнеса с ними могут поступить точно так же. А кто не понимает отчетливо ("малолетних дебилов" в ИТ всегда было в избытке, несмотря на миф о том, что это якобы высокоинтеллектуальная сфера деятельности), те что-то подозревают на уровне подкорки.
Очень неуютно признаваться себе в том, что сейчас у тебя все хорошо, ты нормально устроился, вкладываешься в любимую работу, получаешь за это приличные (по местным меркам) деньги... А завтра тебя могут пинком под зад выставить на мороз. Просто потому, что собственник бизнеса так решил. И право имеет.
Но признать это нужно. Welcome to the real world, как грится.
В-третьих, по поводу негативных предсказаний тяжелых последствий для Xsolla. Мол, после такого PR-а из Xsolla должен начаться массовый исход и вскоре там останется только сам владелец и пара-тройка калек, которых больше никуда не берут.
Чтобы оценить, насколько такой исход вероятен, нужно учесть, как минимум два важных фактора (на самом деле их больше, но для нестоличных городов роль этих двух факторов очень велика).
Первый фактор -- это емкость местного рынка труда и способность этого рынка быстро поглотить освобождающиеся ресурсы. Что-то мне подсказывает, что Пермь -- это не Москва, не Питер, не Новосибирск. И если из Xsolla за короткое время уволится, скажем, 500 человек, то работы для большинства из них в Перми может просто не быть. И если это так, то никакого массового исхода не будет.
Второй фактор -- это специализация тех, кто работает в Xsolla. Если там большое количество людей работали над каким-то собственным, заточенным под специфическую задачу продуктом, то этим людям сложно будет найти новую работу на которой их специализация была бы востребована. В таких условиях очень многие предпочтут ничего не менять, т.к. их катаклизмы не коснулись, их и здесь неплохо кормят, а просто так отказываться от гарантированной миски похлебки готовы не только лишь все.
Так что лично я думаю что негативный PR не окажет на жизнеспособность Xsolla существенного влияния. И если у компании устойчивое положение на рынке, идет поступательное развитие и не случится какого-то внезапного "черного лебедя", то Xsolla будет себе спокойно жить дальше. Благо через пару лет об этом скандале мало кто будет помнить.
Ну и напоследок сухой остаток:
PS. Отдельная часть шума -- это обсуждение того, как можно обосновать увольнение "показателями big-data". Ну ё-маё, это даже не серьезно. Суть же в том, чтобы тем или иным образом определить список подлежащих увольнению. Обставить это все потом с формальной точки зрения можно так, чтобы не подкопались. Особенно, если владелец готов идти на нормальные выплаты при увольнении. Как и сделать невыносимой дальнейшую работу тех, кто решит пойти на принцип и захочет остаться прикрываясь соблюдением бюрократии.
Одна из проблем, с которой я сталкивался будучи тим-лидом, состояла в том, что просматривая код, написанный кем-то из моей команды, я мог озвучить лишь оценку "есть ощущение, что можно сделать проще". Суть проблемы в том, что для того, чтобы более-менее подробно расшифровать это заключение нужно было потратить кучу времени и проделать часть работы, которую должен был как раз сделать автор кода. Иногда, когда человек упорно говорил, что не представляет как именно сделать проще, приходилось таки более глубоко погружаться в код. Но в большинстве случаев я этого, если не изменяет склероз, не делал.
К сожалению, такие воспоминания сложно иллюстрировать примерами кода.
Но вот на Хабре нашел статью с примером, который, как мне думается, ну просто идеален для подобной иллюстрации: История одного фееричного провала тестового задания на C#. Код, который написал автор упомянутой статьи, выложен на GitHub, там его и можно посмотреть. В частности, мне хватило беглого взгляда на вот этот файл.
Вот тут уж, действительно, смотришь на код и не можешь отделаться от двух мыслей: a) вроде бы должно быть проще и b) блин, да это же нужно самому задачу решить, чтобы объяснить, что именно должно быть проще.
Если говорить о содержимом класса TestApp::Schedule, то у меня лично сходу следующие претензии к уведенному:
Ну и еще лично у меня есть заморочка по поводу парсинга выражений "в лоб" посредством "ищем первое двоеточие, если нашли, то ищем после него второе двоеточие, если нашли, то смотрим на первый пробел после, если нашли, то..." Когда вижу такое вместо применения каких-то более формальных методов разбора (пусть даже посредством регулярок), то невольно вынужден подозревать, что написанный подобным образом код будет глючным и сложным в поддержке.
Так что я бы лично такую реализацию тестового задания бы завернул. Может быть с более лояльной общей оценкой :)
Вообще же задача сильно напоминает мне классический unix-овый cron. И если бы такое тестовое задание предстояло решать мне самому, то я бы сперва перерыл бы Интернет в поисках описаний различных подходов к ее реализации. Может быть даже в исходники cron-а бы заглянул. У меня коллега когда-то лет 17 назад что-то подобное делал и там использовались битовые массивы и, вроде бы, все это было гораздо компактнее и понятнее.
Подошло время очередного кинообзора. По традиции вначале списка идут фильмы, которые понравились больше. Завершают же список фильмы, на которые можно не тратить свое время.
Вторая жизнь Уве (En man som heter Ove, 2015). Как по мне, так добрый и милый фильм. Но зайти может не всем, т.к. в нем нет какой-то интриги и он наполнен довольно-таки стереотипными вещами.
Круэлла (Cruella, 2021). Удивительно, но на фоне всего того шлака, который идет в этом списке ниже, этот фильм даже посмотреть можно. Хотя бы из-за саундтреков. А если бы и спецэффекты были на нормальном уровне сделаны, то было бы и вообще хорошо.
Война будущего (The Tomorrow War, 2021). Можно посмотреть. Но многого ждать не стоит. И мозги нужно отключить, не вдумываться и смотреть просто как на аттракцион.
Без резких движений (No Sudden Move, 2021). Кино из, что называется, непонятого. Смотреть было интересно. Но после просмотра главный вопрос: "А кто бы теперь все это объяснил для обычного зрителя?"
Мейер Лански (Lansky, 2021). Сильно двойственные впечатления. С одной стороны, очень качественно все сделано и смотреть это на фоне остального современного шлака, просто приятно. Отдельное удовольствие опять увидеть в главных ролях Харви Кейтеля, ветеран держится молодцом. Но, с другой стороны, ничего нового в фильме нет. Такое ощущение, что все это уже видел многократно и никакой собственной изюминки нет и впомине.
Пятнадцать минут войны (L'Intervention, 2019). Фильм условно можно разделить на две части: первая (порядка 1 часа и 15 минут), в которой происходит завязка истории и подготовка к развязке, и вторая (порядка 15 минут) с собственно развязкой. Так вот, первая часть настолько уныла и неинтересна, что я даже и не знаю, стоит ли через нее продираться, чтобы посмотреть вторую часть, намного более интересную и динамичную.
Судная ночь навсегда (The Forever Purge, 2020). Если кому-то понравились предшествующие части серии про "Судную ночь", то можно попробовать посмотреть и эту. Но, как по мне, лучшей была вторая часть, в которой снимался Фрэнк Грилло. А этот же фильм -- обычный ширпотреб для любителей жанра.
Пороховой коктейль (Gunpowder Milkshake, 2021). Унылая и скучная попытка снять очередного "Джона Уика в юбке". Временами чрезмерно затянутые сцены просто выбешивали.
Во всё тяжкое (The Professor, 2018). После трейлера ожидал от фильма много большего. Получил же набор банальностей и, в некоторых местах, желание громко воскликнуть "Не верю!" Немного спасает фильм разве что обаяние Джонни Деппа и, особенно, Дэнни Хьюстона.
Заложники Марса (Settlers, 2021). Фильм развивается неспешно. В одной и той же локации. С очень небольшим количество персонажей. Но за этим всем все равно интересно следить в ожидании развязки и объяснения того, чтоже именно и почему происходит. Но вот этой самой развязки с объяснением и не случается. Унылый финал, который сливает в унитаз весь фильм.
Ага (2021). Попытка казахов снять своего собственного Джона Уика. Попытка так себе. Убедительного персонажа взяли на главную роль. А вот на все остальное, такое ощущение, денег уже не хватило. Включая, к сожалению, и экшен.
Телохранитель жены киллера (Hitman's Wife's Bodyguard, 2021). Отборнейшее говно. И по замыслу, и по исполнению.
Черная вдова (Black Widow, 2021). Редкой тупости кино с невероятно убогими для такого "блокбастера" спецэффектами. Такое ощущение, что создание фильма было отдано на откуп самым дешевым и криворуким аутсорсерам.
Красотка на взводе (Jolt, 2021). С большим трудом досмотрел до половины, потом сдался и выключил.
Отдельное мнение по поводу фильма Красный призрак (2020).
Я не понял что это было. А потому и не могу судить, хорошее это кино или нет. Но лично мне как-то не зашло. Может быть как раз потому, что я так и не понял, что это было.
Возможно, в современных реалиях нужно делать комиксы на тему ВОВ, к коим "Красный призрак" я и отношу. Но мне такое, в силу возраста и воспитания на совсем других фильмах про войну, кажется дикими.
С технической точки зрения все, вроде бы, снято достойно. Но лично меня смущало то, что ни один актер не был похож на человека, много времени проведшего зимой вне теплого помещения (пусть даже при совсем небольшом морозце). Все выглядели бодренько и свежо, как будто они все время находились в теплом помещении, а в эти заснеженные декорации заскочили буквально пару минут назад.
Сегодня попробую рассказать о тех моментах в механизме поддержки короутин C++20, которые вызывают наибольшие сложности и пока никак толком не укладываются в моих мозгах. Зачем я вообще ввязался в изучение короутин из C++20 объяснялось в предыдущем посте.
Целью является попытка структуризации изучаемой информации. Есть надежда, что формулирование разрозненных мыслей в письменном виде принесет пользу (пока что это предположение оправдывается). Но, возможно, перечисленные мной пункты окажутся актуальными еще для кого-то.
В конце поста я приведу список материалов на тему C++20 короутин, которые я счел полезными и штудированием которых занимаюсь вот уже неделю.
Примеры, которые разбираются в статьях про короутины, часто выглядят вот так:
Я тут с прошлой недели пытаюсь въехать в тему короутин, которые завезли в C++20. Пока еще не вкурил. В голове все еще каша, но хотя бы местами начинают формироваться отдельные лоскуты, которые я надеюсь в скором будущем сшить в общую картину. Поскольку процесс этот на удивление тяжелый и долгий, то не грех поделиться какими-то предварительными впечатлениями.
Понимаю, что на этот счет есть разные мнения, но лично мне после знакомства с тем, что включили в C++20, проще считать, что в C++20 короутин нет.
Есть механизм поддержки короутин со стороны языка.
А вот самих короутин нет.
ИМХО, это большая разница.
Если бы в стандартной библиотеке C++20 были готовые к использованию короутины, то у обычного разработчика занимало бы только то как посредством имеющихся короутин решить свою задачу.
Но т.к. в стандартной библиотеке короутин нет, то разработчику нужно думать и о том, как решить задачу посредством короутин, так и о том, где эти самые короутины взять. После чего приуныть, если готовых короутин под его задачу не найдется.
Мягко говоря, это просто какой-то трындец.
Я вкуриваю эти самые короутины уже пять дней. И все еще никак.
Не, поятно, что я не показатель, т.к. старый и впавший в маразм старпёр. Но, судя по отзывам, проблемы с изучением есть не только у меня. Что пугает.
При этом сам механизм поддержки короутин выглядит как очень крутой и гибкий. На уровне гениальности. Без всякой иронии. Просто поразительно как все придумано и продумано.
Проблема в моем случае в том, что моих мозгов на осознание всей гениальности замысла не хватает. Что расстраивает.
Расчет комитета по стандартизации C++ был в том, чтобы добавить в язык сам механизм. Чтобы те или иные реализации подтянулись со временем.
Как я понимаю, в Asio-1.19 эта реализация уже есть.
Вероятно, со временем и другие реализации для других прикладных ниш подтянутся.
Так что обычному разработчику нужно будет изучать не внутреннюю кухню языка в плане поддержки короутин, а возможности конкретной реализации короутин в конкретной библиотеке. Что гораздо проще.
Смущает, правда, наличие "закона текущих абстракций", согласно которому понимание того, что же происходит "под капотом" все же желательно. Но насколько все это будет актуально покажет только время. Будем посмотреть.
Ломать же голову над реализацией собственных короутин придется лишь тем немногим несчастным, кому потребуется сделать что-то свое. Таких явно будет немного.
Во-первых, это все равно будущее программирования на C++. Не удивлюсь, если через всего пять лет использование короутин будет обыденной и повседневной рутиной. Так что нужно подготовиться к грядущим изменениям.
Во-вторых, если наши SObjectizer и RESTinio продолжат свое развитие, то нужно понимать, где и как короутины могут пригодится. И уже сейчас кажется, что пригодиться могут.
Пока не видно, чтобы короутины нужны были где-то в потрохах SObjectizer-а.
Но вот где короутины явно могут помочь, так это в упрощении синхронного взаимодействия между агентами.
Сейчас если агент A хочет синхронно обратиться к агенту B (т.е. в обработчике событий E отослать сообщение агенту B и тут же, прямо внутри E дождаться ответа), то программист должен гарантировать что A и B работают на разных контекстах.
Тогда как в случае с короутинами можно сделать так, чтобы обработчик событий E сам был короутиной. Вызов операции ожидания ответа от B реализовывался бы через co_await. Например, что-то вроде:
so_5::awaitable_t A::evt_E(mhood_t<some_msg>) {
// Создаем message chain для ответного сообщения.
so_5::mchain_t reply_chain = so_5::create_mchain(so_environment());
// Отсылаем сообщение агенту B и передаем в нем reply_chain, чтобы
// агент B знал, куда отсылать ответ.
so_5::send<some_request>(B_mbox, ..., reply_chain, ...);
...
// Здесь мы хотим получить ответ.
co_await so_5::receive(from(reply_chain).handle_n(1), ...);
}
Фокус здесь в том, что диспетчер, на котором запускается A::evt_E сможет понять, что здесь у нас короутина. И когда она приостановится на вызове co_await, то можно перейти к обслуживанию следующей заявки.
А это позволяет запросто привязать агентов A и B к общему рабочему контексту. При этом они смогут "синхронно" общаться друг с другом.
Что очень круто, т.к. раньше такое в принципе было невозможно.
А вот в RESTinio для применения короутин открывается гораздо больший простор. ИМХО.
Прежде всего короутины можно использовать непосредственно в коде по работе с сетью в RESTinio. То, что сейчас делается на callback-ах, можно попробовать переделать на Asio-шных короутинах. И, есть подозрение, код внутри RESTinio получится более компактным и читабельным.
Очевидное применение короутин для упрощения жизни пользователям RESTinio -- это представление request_handler-ов в виде короутин.
Сейчас, если пользователь хочет сделать именно асинхронную обработку входящих запросов, то он должен в request_handler-е делегировать куда-то саму обработку и вернуть управление назад RESTinio.
В случае же, если request_handler будет представлен в виде короутины, то внутри request_handler-а можно инициировать асинхронные операции посредством co_await. Что, потенциально, сделает написание асинхронных обработчиков входящих запросов гораздо более простым занятием.
На данный момент RESTinio позволяет работать только с входящими HTTP-запросами, а исходящие запросы не поддерживаются в принципе. Т.е. RESTinio не может сейчас использоваться в качестве HTTP-клиента.
Причин тому множество (главное, что за поддержку этой фичи никто не захотел платить), но среди них есть и такой момент, что лично мне было непонятно, как должен был бы выглядеть интерфейс RESTinio для работы с исходящими соединениями.
А вот применение короутин, потенциально, может этот момент прояснить. Например, что-то вроде:
auto reply = co_await client.http_post(restinio::async, "https://google.com", ...);
Причем, если RESTinio будет поддерживать request_handler-ы в виде короутин, то подобный вызов можно будет делать прямо внутри request_handler-а. Т.е. приняли входящий запрос, внутри которого нужно сделать пару исходящих запросов к каким-то внешним сервисам -- нет проблем, сделали. Ничего не блокируя. Ну лепота же ж.
Я не хочу сказать, что наличие короутин делает добавление поддержки исходящих HTTP-запросов в RESTinio простым и понятным делом. Но внушает надежду, что такая поддержка может быть сделана красиво и удобно для пользователя.
В ближайший день-два я попробую написать пост, в котором расскажу, что именно затрудняет для меня разбирательство с механизмом короутин в C++20. Это нужно лично мне, т.к. надеюсь, что в процессе написания текста информация в мозгах структурируется чуть лучше. Но может кому-то это так же будет интересно.
Возможно, кто-то использует RESTinio в своих проектах и планирует со временем переходить на C++20. Если так, то вы можете быть заинтересованы в том, чтобы в RESTinio появилась поддержка короутин. Ускорить этот процесс можно за счет финансирования наших работ по RESTinio. Например, в виде договора между вашей компанией и СтифСтримом.
Тоже самое касается и SObjectizer-а.
В этот блог-пост вошли соображения, которые не хотелось впихивать в предыдущий пост дабы не раздувать его размер совсем уж до безобразия.
Попробую рассказать о том, как я сам сейчас отношусь к существующей в C++ поддержке исключений.
Хорошо, что исключения в C++ есть. Как уже говорилось в предыдущем посте, лично я плохо себе представляю как писать надежный код без использования исключений при программировании в стиле "современного C++".
Плохо то, что текущая реализация исключений:
Сегодня попробую выполнить обещание, данное в предыдущем посте, и попытаюсь рассказать немного о том, к чему на данный момент пришла работа с исключениями в arataga (если кто-то не в курсе, то arataga -- это прототип производительного прокси-сервера, который мы делали для одного клиента, пока этот самый клиент не потерял интерес к данной разработке).
Во-первых, изначально проект arataga разрабатывался в сжатые сроки и требовалось как можно быстрее получить работающий прототип чтобы оценить перспективность всей затеи. Т.е. ключевым фактором являлся "time to market". Писать на C++ в условиях горящих сроков -- то еще занятие. Поэтому для нас важно было использовать практики, которые бы обеспечивали нам и достаточно высокую скорость разработки кода, и достаточную степень его надежности и корректности.
Во-вторых, в arataga не было изначальной необходимости запрещать исключения вообще. Это не реальное время, здесь нет надобности доказывать предсказуемость поведения кода. Это не встраиваемый софт, чтобы считать каждый байт расходуемой памяти. Поэтому мы решили использовать исключения для сокращения объема кода и повышения его надежности.
В-третьих, архитектура arataga подразумевала, что будет всего один процесс, который будет обслуживать все подключения. Откуда следует то, что принцип fail-fast в смысле "если возникла непредвиденная неприятность, то просто грохаем весь процесс" здесь был бы не очень уместен. Подключений десятки тысяч, с каким-то из них точно что-то пойдет не так. Ронять все приложение вместе со всеми остальными подключениями не есть хорошо. Как следствие, нам пришлось разбираться с тем, чтобы неожиданные исключения, с которыми мы не знаем что делать, не всегда вели к краху всего приложения, а в каких-то местах просто игнорировались бы.
В-четвертых, хотя arataga и должен был работать в режиме 24/7, но жестких требований к тому, чтобы arataga не падал в любых условиях, у нас не было. Эпизодические падения в непредвиденных ситуациях, скажем, раз в неделю, никого бы не напрягали. Поэтому мы могли не заморачиваться на тотальный контроль исключений и в каких-то местах могли позволить себе смотреть на ситуацию так: "ну, если уж здесь что-то вылетит, то пусть уж лучше все просто навернется и рестартует".
В-пятых, в arataga активно используются сторонние библиотеки, которые либо не очень приветствуют выброс исключений в callback-ах (как Asio, например), либо же вообще этого не приемлют (как, например, чисто C-шная http-parser, которая про C++ные исключения ни сном, ни духом). Но callback-и в эти сторонние библиотеки передаются C++ные, в которых активно используется C++ный код, бросающий исключения. И это нужно было как-то брать под контроль.
Впервые за долгое время появилась возможность и желание написать в блог что-то на тему программирования. Сегодня речь пойдет о мелочи, которая очень сильно упростила поиск связанной информации в логах arataga.
Если кто-то не в курсе, то arataga -- это прототип производительного прокси-сервера, который мы делали для одного клиента, пока этот самый клиент не потерял интерес к данной разработке.
Пару месяцев назад представилась возможность погонять arataga под реальной нагрузкой. Чем мы с удовольствием воспользовались. Выявили несколько косяков, кое что поменяли. Но, в общем, в очередной раз убедились, что arataga работает.
Поскольку нагрузка создавалась не тестовыми программами, а реальными клиентами, трафик которых был пущен через arataga, то мы столкнулись с рядом особенностей в реализации SOCKS/HTTP-протоколов. И для разбирательства с тем, правильно ли arataga ведет себя в тех или иных ситуациях, потребовалось шерстить логи.
Грубо говоря, ищешь в логе ситуацию, помеченную как WARN или ERR, а затем смотришь, что предшествовало и/или следовало за этой ситуацией.
Потребовалось легко и быстро находить строки лога, описывающие то соединение, с которым тебе нужно разобраться.
Изначально казалось, что каждая строка лога содержит достаточное количество информации для идентификации конкретного подключения. Вот, например:
[2021-04-16 08:43:02.756] [arataga] [error] socks-3001-192.168.1.178-io_thr_1-v1: connection (3001,38) => socks5: PDU with auth methods too long, methods: 1, bytes read: 22
[2021-04-16 08:43:02.756] [arataga] [debug] socks-3001-192.168.1.178-io_thr_1-v1: connection (3001,38) removed (protocol_error), connections: 0/200
Здесь в каждой строке есть две метки, которые позволяют идентифицировать точку входа и конкретное соединение в этой точке входа:
По идее, если искать подстроки "socks-3001-192.168.1.178-io_thr_1-v1" и "(3001,38)", то в логе будет найдено все, что касается данного конкретного подключения на данной конкретной точке входа.
Проблема, однако, в том, что искать по двум подстрокам не удобно. Гораздо удобнее искать всего одну подстроку. А именно "(3001,38)" вместо "socks-3001-192.168.1.178-io_thr_1-v1".
Это проблема проявилась практически сразу, еще когда мы сами занимались отладкой первых версий arataga на собственных тестовых стендах. Собственно, поэтому и появилась в логе отдельная связка из номера порта и номера соединения на этом порту (та самая подстрока вида "(3001,38)"). Это помогало нам в нашей автономной отладке, т.к. у нас не было повторений номеров портов на точках входа.
Но когда arataga поработала под реальной нагрузкой в условиях, когда есть сотни точек входа с одинаковым номером TCP-порта (на разных IP-адресах), то выяснилось, что подстроки вида "(3001,38)" уже не позволяют легко отыскивать все, что касается конкретного подключения. Слишком уж много оказывалось вхождений "(3001,38)", относящихся к совсем другим точкам входа.
Поэтому arataga была немного доработана дла того, чтобы от пары (порт, номер соединения) перейти к триплету (уникальный ID, порт, номер соединения), где "уникальный ID" был бы неким более коротким и удобным синонимом для "socks-3001-192.168.1.178-io_thr_1-v1".
В результате сейчас в arataga записи в логе имеют вид:
[2021-04-29 09:04:34.558] [arataga] [error] http-5500-192.168.1.161-io_thr_0-v1: connection (6498_2185,5500,6) => update request-target failure: unable to parse request-target, http_parser_parse_url result: 1
Где подстрока "(6498_2185,5500,6)" уже однозначно указывает на строчки лога, относящиеся к конкретному соединению на конкретной точке входа (уникальный ID вида "6498_2185" назначен агенту "http-5500-192.168.1.161-io_thr_0-v1" при его создании):
[2021-04-29 09:04:33.981] [arataga] [info] http-5500-192.168.1.161-io_thr_0-v1: created, acl_id_seed: 6498_2185
Пора переходить к итогу и к морали.
Итог простой -- после того, как в arataga каждое соединение начало идентифицироваться не парой из (порт, номер соединения), а триплетом (уникальный ID, порт, номер соединения), то отыскивать в логах информацию, относящуюся к конкретному подключению, стало гораздо проще.
Мораль номер раз. При начале реальной эксплуатации обязательно возникнет необходимость в каких-то незапланированных доработках, которые существенно повысят удобство использования софта (или же упростят разбирательство с проблемами в софте). Эти доработки нельзя предугадать. Но желательно сделать.
И отсюда проистекает мораль номер два. Хорошо, когда между вами и заказчиком установились нормальные рабочие взаимоотношения. И вам не нужно тратить кучу времени на объяснение того, почему в перечне трудозатрат появилась еще какая-то строчка с непонятной на первый взгляд фигней. Ибо если вам придется отдельно объяснять, почему час рабочего времени был потрачен на изменение схемы идентификации подключениях в записях в лог, то желание делать что-то хорошо для этого заказчика у вас быстро исчезнет.
Спасибо тем, кто продолжает читать этот блог. Писать что-то интересное и, надеюсь, полезное, становится все сложнее. Но я буду пытаться продолжать это делать. В частности, есть желание поделиться впечатлением от использования noexcept в коде arataga. Надеюсь, что смогу найти время для того, чтобы написать соответствующую заметку.
Подошло время очередного кинообзора. В этот раз сперва речь пойдет о фильмах (упорядоченных, как обычно, от тех, что понравились, к тем, которые можно не смотреть вовсе), а затем будет сказано пару слов о двух российских сериалах.
Но, чтобы убить всякую интригу и не порождать напрасных ожиданий, скажу кратко: глянуть можно разве что "Кислород" и, если вам понравилась первая часть "Тихого места", то "Тихое место 2" (но лучше не ждать чего-то выдающегося). И все, сорян.
Фильмы
Кислород (Oxygène, 2021). Был приятно удивлен. Не ждал от продукции Netflix чего-нибудь толкового. Но у них получилось. Посмотрел с удовольствием.
Тихое место 2 (A Quiet Place Part II, 2021). Если вам понравился первый фильм, то можно посмотреть и второй. Ну а если первый восторга не вызывал, то и второй точно не вызовет. Как по мне, то вторая часть смотрится даже хуже, чем первая. Плюс у них серьезный косяк с приглашением на роль сына того же актера, что и в первой части (мальчик за 3 года сильно вырос и в продолжении это выглядит несуразно).
Бесконечность (Infinite, 2021). Красочно и местами даже динамично. Но блин, насколько же все тупо! Хотя, если этот фильм ориентирован на зрителей в возрасте 10 лет, то может и нормально для такой аудитории.
Дальний космос (Stowaway, 2021). Вот реально был неплохой заход на то, чтобы снять достойную космическую фантастику. Но, во-первых, получилось слишком нудно и затянуто. Во-вторых, почему-то в фильме не уделили никакого внимания тому, как "безбилетник" вообще попал на борт. В-третьих, почему-то сопереживать персонажам не хочется. Может быть потому, что в какие-то моменты они ведут себя как идиоты.
Первый клон (Seobok, 2021). По описанию и трейлеру ожидал, что будет бодрый фантастический боевик. Оказались фантастически нудные сопли. Смотреть можно разве что тем, кто интересуется корейским кино.
Ледяной драйв (The Ice Road, 2021). Халтура. Как по задумке, так и по исполнению.
Игры шпионов (The Courier, 2020). Не зашло. Смотреть было не интересно (особенно после прочтения вот такого взгляда на значимость предателя Олега Пеньковского). Такое ощущение, что основная цель съемок сего фильма была в том, чтобы дать Камбербэтчу повторить подвиг Кристиана Бейла в "Машинисте". Ну а появление в фильме гостиницы под названием "Отель Василий" просто подвело жирную черту под всем этим безобразием.
Сериалы
За час до рассвета (2021). Треш, угар и голые сиськи. Впрочем, при нынешней глобальной толерастии "голые сиськи" -- это еще неплохо, могла бы быть и содомия в худшем смысле этого слова. Всерьез это творение обсуждать невозможно, настолько там все убого, уныло и оторвано от реальности, что главный и единственный вопрос -- где же авторы брали такую траву?
Призрак (2019). Редкая дрянь. Смело можно не смотреть.
Честно, не представляю себе, как можно дальше жить в мире, где нормальным считается применение инструмента, провоцирующего на написание чего-то вроде:
|
add_executable(myapp main.cpp foo.c bar.cpp zot.cu) target_compile_definitions(myapp PRIVATE $<$<COMPILE_LANG_AND_ID:CXX,AppleClang,Clang>:COMPILING_CXX_WITH_CLANG> $<$<COMPILE_LANG_AND_ID:CXX,Intel>:COMPILING_CXX_WITH_INTEL> $<$<COMPILE_LANG_AND_ID:C,Clang>:COMPILING_C_WITH_CLANG> ) |
Если кто не в курсе (счастливчики!), то здесь условные операторы в угловых скобках. Вложенные.
И если бы не специальная поддержка в CMake магической COMPILE_LANG_AND_ID, то приведенный выше фрагмент пришлось бы записать вот так:
|
target_compile_definitions(myapp PRIVATE $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:AppleClang,Clang>>:COMPILING_CXX_WITH_CLANG> $<$<AND:$<COMPILE_LANGUAGE:CXX>,$<CXX_COMPILER_ID:Intel>>:COMPILING_CXX_WITH_INTEL> $<$<AND:$<COMPILE_LANGUAGE:C>,$<C_COMPILER_ID:Clang>>:COMPILING_C_WITH_CLANG> ) |
Я даже уже не пытаюсь представить какому сумрачному гению это все пришло в голову. Более того, я даже не пытаюсь больше понять, почему такое количество разработчиков готовы с этим мирится. Ну вот таков мир, что поделать, остается принимать его каков он есть.
Однако, никогда у меня не бывает настолько же сильного желания уйти навсегда из С++, как в случаях, когда самому приходится погружаться в CMake-код. Да и не только из мира C++, но и вообще из программирования.
PS. Месяца четыре назад была возможность послать C++ к чертям собачим не нарушая никаких обязательств. Почему не воспользовался... Эх.
Сегодня поделюсь своими впечатлениями о ряде динамических наушников-вкладышей, которые побывали в моих руках. Все они были куплены на Aliexpress. Часть из них пришла уже в готовом, собранном виде. Часть покупалась по комплектующим и собиралась мной самостоятельно.
Снимков наушников практически не будет, т.к. их слишком много и выглядят они в общем-то весьма однотипно. Приношу извинения, но возиться с фотографированием этого добра очень не хочется. Так что буду прилагать скриншоты со страничек этих наушников/динамиков на Aliexpress.
Подготовили презентацию о проекте arataga на английском языке. Надеюсь, кому-то будет полезна, поскольку не так-то и просто найти информацию о том, как же модель акторов применяется на практике в реальных C++ных проектах.
Эта же презентация есть на SlideShare.
Простите за политоту. Но поделюсь своим дилетантским мнением после просмотра того, что на ОНТ показали про рейс Ryanair и Романа Протасевича, а так же после прочтения нескольких заметок в Интернетах с разными точками зрения на происходящее.
Сложилось впечатление, что Протасевича слили свои же. Потому, что он не примкнул ни к одному из "центров сил" за границей. Но, при этом, является независимым, умным, деятельным, известным и имеющим некоторый авторитет. Т.е., может быть либо сильной самостоятельной единицей, либо центром притяжения для других участников протеста, что вызывает опасения у тех, кто уже сел на финансовые потоки поддержки оппозиции. Т.е. он "ничей сукин сын", которого безопаснее слить, нежели пытаться контролировать.
Слили его вовсе не нашему КГБ. А, как мне думается, российским спецслужбам. И вся эта история с минированием борта Ryanair -- это не наши контрразведчики подсуетились, а российские.
Ибо, как мне думается, единственной стороной, которая при этом ничем не рискует, но получает большие дивиденды в случае успеха -- это Россия:
Ну и добавим сюда маленький приятный бонус для Аэрофлота и других российских компаний, которые совершают рейсы в Европу и обратно напрямую через РБ, тогда как их европейские конкуренты вынуждены делать это "в обход". Плюс возможность прикупить часть или даже всю Белавиа с учетом того, что рыночная стоимость Белавиа сейчас должна несколько снизиться.
Тогда как РБ от всей этой истории получает лишь возможность предъявить миру публичные выступления одного далеко не самого знакового деятеля протестного движения, который не обладает реальной властью в этом самом протестном движении. При этом миру абсолютно пофиг все, что будет говорить РБ в свое оправдание. Так что у нас сейчас ситуация хуже не придумаешь: нужно доказать что мы не причем именно тогда, когда мы не при чем, но всем на это насрать.
На счет ценности сведений от Протасевича для нашей контрразведки не берусь судить. Но сильно удивлюсь, если там будут какие-то откровения и открытия для спецслужб. Уточнение каких-то деталей и заполнение мелких белых пятен -- это да, но основные контуры им должны были быть давно известны.
Т.е. вся эта история с Протасевичем была чем-то выгодна лидерам протеста за границей (какой-то из группировок этих лидеров). И очень выгодна РФ. А вот кому практически не выгодна -- так это РБ.
В Интернетах были вопросы о том, почему же Протасевич не уничтожил данные на своих носителях перед задержанием. Даже если не брать в расчет тот факт, что надежно удалить данные не так-то и просто, если ты не знаешь, как именно это делать, то в условиях внезапной и незапланированной посадки можно тупо не успеть это сделать.
Но главная причина, как мне кажется, в том, что Протасевич осознал, что с информацией на носителях его ценность для нашего КГБ гораздо выше, чем без нее. А цена вопроса для него здесь высока как никогда. Так что, по моему мнению, он специально не стал уничтожать информацию на смартфоне и ноутбуке.
Вот такое впечатление сложилось на эту злободневную тему.
Написал потому, что происходящее у нас в стране воспринимаю болезненно. Очень уж все это похоже на то, что творилось в СССР перед его распадом. Одну родную страну уже потерял, перспектива пережить такое еще раз сильно не радует.
Дисклаймер. Если кто-то захочет доказать в комментариях какой я дебил и насколько сильно мне не нужно лезть в то, в чем не разбираюсь, то я это и так все знаю. Давайте сэкономим друг другу время и нервы.