четверг, 1 декабря 2022 г.

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

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

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

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

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

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

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

[life.cinema] Очередной кинообзор (2022/11)

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

Фильмы

Смотрите, как они бегут (See How They Run, 2022). Если черные комедии могут быть ироничными, то это вот тот самый случай. Кино, конечно же, специфическое. Но мне зашло, посмотрел с большим удовольствием.

В эфире (On the Line, 2022). Мне понравилось. Но только смотреть нужно до самого конца, каким бы невероятным не казалось повествование в середине.

Битва при Логнтане (Danger Close: The Battle of Long Tan, 2019). Средней руки военный фильм. Хотя на фоне современного киношлака выглядит вполне себе достойно. Доколупаться можно было бы до батальных сцен, т.к. меня a) не сильно впечатлили спецэффекты и b) атакующих вьетнамцев не стоило выставлять такими уж картинно несущимися навстречу неминуемой смерти идиотами.

Очень плохие парни (Big Bad Wolves, 2013). Не зашло мне это кино. В нем рассказывается о таких страшных вещах, в которые даже вдумываться не хочется, но снято это все как комедия. Черным комедиям есть место, но здесь, как по мне, грань разумного была оставлена далеко позади.

Покерфейс (Poker Face, 2022). Так себе кино. Как говорится, замах на рубль, удар на копейку: вроде бы завязка была многообещающей, а развязка оказалась вообще никакой.

Корабль в Пусан (Neukdaesanyang, 2022). Прежде всего это кино не имеет никакого отношения к отличному "Поезд в Пусан" с зомби. Здесь другие монстры, не зомби. Мог бы стать нормальным представителем жанра "кишки, кровь, расп*дорасило", если бы кровь в этом "кино" была бы похожа на кровь, а не на гранатовый сок.

Шесть минут до получночи (Six Minutes to Midnight, 2020). Картинка годная, содержание -- говно.

Наблюдающий (Watcher, 2022). Унылое и скучное говно.

Сериалы

Миссис Уилсон (Mrs Wilson, 2018). В кино рассказана очень интересная история, за которой хочется следить. Поэтому мне фильм зашел настолько, что даже не хочется обсуждать все остальное.

Игра на выживание (второй сезон). Если первый сезон понравился, то можно глянуть и второй. Есть шансы не разочароваться. Но мизерные. Я разочаровался. Если же первый сезон не понравился, то второй можно и не начинать.

понедельник, 28 ноября 2022 г.

[prog.c++] Погрузился в изучение Dear ImGui и вот что любопытно...

Возникла необходимость поверхностно освоить необычный (для меня лично) оконный фреймворк Dear ImGUI.

Очень прикольная штука.

Я в свое время имел опыт работы с GUI. Причем начиная от MS-DOS, в котором мы сами рисовали подобие Windows-овских окошек/менюшек/кнопочек/пр. в графическом режиме посредством Borland-овской BGI. И заканчивая работой с Qt и MFC, по дороге пройдя через стадию прямой работы с API MS-Windows и IBM OS/2 Presentation Manager, и даже делая какие-то свои библиотеки-обертки вокруг этих самых API. Кроме Qt и MFC доводилось знакомиться и с wxWidgets (тогда еще wxWindows), и с FOX Toolkit, и с FLTK (и даже со Swing-ом в Java). В общем, какое-то представление о том, как делается "традиционный" GUI, у меня когда-то было.

Но вот Dear ImGui, который реализует идею Immediate Mode GUI (акронимом чего и является IMGUI), -- это какой-то совсем другой зверь, диковинный и непривычный.

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

Однако, на написание поста толкнуло совсем другое впечатление.

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

И, что удивительно, пользователей Dear ImGui, судя по их скриншотам, коих предоставлено уже немало, эта "ненативность" внешнего вида не волнует от слова совсем.

Удивительно это для меня потому, что доводилось читать немало споров про выбор GUI-фреймворка для кроссплатформенных приложений и одним из требований (или одной из претензий) к существующим инструментам было то, что рисуемые GUI-фреймворком контролы визуально отличаются от нативных (т.е. родных для ОС).

Типа, вот Qt -- да, хороший фреймворк, но на такой-то платформе его кнопки отличаются от родных. И т.д., и т.п.

Я таких претензий никогда особо не понимал. Как по мне, так GUI-интерфейс должен быть продуманным и удобно заточенным под задачу. А само GUI-приложение должно быть отзывчивым. И если это так, что внешний вид контролов в GUI-приложении -- это уже мелочь.

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

Таки здравый смысл еще где-то остался. Что не может не радовать.

понедельник, 21 ноября 2022 г.

[prog] Что-то странное: появилось желание сделать реализацию MQTT v5 :)

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

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

Так что если мне задать вопрос "а над какой задачей было бы интересно поработать?", то я зависну на некоторое время и вряд ли смогу дать вменяемый ответ. А невменяемый мог бы звучать как "ни над какой" ;)

Но вот просматривая спецификацию MQTT подумал, что как раз сделать свою реализацию MQTT v5 было бы интересно. Причем как клиентскую, так и серверную.

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

Еще подумалось вот что: в конце 2016-го и начале 2017-ого мы в "СтифСтрим" решали какой еще открытый продукт родить, чтобы иметь в своем портфолио что-то кроме SObjectizer-а. И основных идей было две: либо какой-то MQ-шный брокер, либо встраиваемый в C++ приложения HTTP-сервер.

И мне сейчас кажется, что если бы спецификация MQTT v5 была доступна уже тогда, то, возможно, RESTinio бы и не случилось бы. Мог бы быть какой-то MQ-шный брокер на C++ на базе SObjectizer-а. Но тогда MQTT v5 еще не было, а делать свой брокер намного более простого MQTT v3 на фоне уже существовавших тогда альтернатив не выглядело перспективной затеей.

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

суббота, 19 ноября 2022 г.

[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 гораздо лучше для управления памятью, чем ручная работа? И не только с точки зрения безопасности. Но и с точки зрения производительности.

А?

пятница, 18 ноября 2022 г.

[prog.c++] Впечатлился рассказом RisingWave Labs о переписывании cloud database с C++ на Rust

История от стартапа RisingWave Labs: "Building a Cloud Database from Scratch: Why We Moved from C++ to Rust". И дополнение к ней в виде интервью с основателем этого стартапа Yingjun Wu на medium: "The founder of the database rewrite with Rust is back: Was it worth deleting 270,000 lines of C++ code?" (только осторожно, это интервью на medium под звездочкой, поэтому открывать лучше в incognito window, чтобы не нарваться на ограничение по числу бесплатных просмотров).

История хорошая. Если вкратце: некий стартап решил запилить новую cloud database (чтобы это не значило) и начал пилить на C++, т.к. C++ вполне себе естественный выбор, плюс у этих людей был опыт в C++ (а сам Yingjun Wu, как выяснилось в интервью кроме как на C++ больше ни на чем проектов не делал). Пилили-пилили семь месяцев, забабахались вылавливать баги и бороться с проблемами управления зависимостями. И решили все переписать на Rust. Что и сделали. За пару месяцев (да, всего за пару месяцев).

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

Сам я много лет выступал в этих наших интернетиках в качестве адвоката C++, но в данном случае даже не буду пытаться как-то защищать C++. Как по мне, то на основании прочитанного думается, что RisingWave сделали правильный выбор в пользу Rust-а. Наверное, им вообще сразу же нужно было начинать на Rust, а не тратить время на C++.

Здесь же я попробую сформулировать свое впечатление о том, как RisingWave дошли до жизни такой, затрону несколько показавшихся мне странными моментов, попробую высказать свое мнение о том, как использовать на C++, чтобы затем не пришлось переписывать все на другом языке программирования.

Кому интересно милости прошу под кат.

понедельник, 14 ноября 2022 г.

[life] Посмотрел интервью Олега Тинькова на канале "Русские Норм!" Зачем-то

Где-то, если не ошибаюсь, в LinkedIn, увидел небольшую подборку фрагментов из этого интервью, захотелось посмотреть полную версию. Посмотрел. Жалею о потраченном времени.

Собственно, вот: https://www.youtube.com/watch?v=AsB3aGyl62Y

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

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

Вроде бы тем, кто застал СССР в уже сознательном возрасте, такие вещи должны бы быть знакомы. Вот, например, были в СССР отличный актер Олег Басилашвили и прекрасный режиссер Станислав Говорухин. Авторитеты в своем ремесле. Известные люди. К мнению которых многие прислушивались. И, что ужасно, прислушивались даже когда Басилашвили и Говорухин рассуждали не о кино или актерском мастерстве, а о политике и управлении государством.

Теперь уже и непонятно почему прислушивались.

Вроде бы прошло больше 30 лет, можно было бы сделать соответствующие выводы.

Но нет. Наверное, выросло новое поколение.

Примечательно, что Олег Тиньков сам же обозначил два ключевых момента, которые позволяют смело направлять изрядную часть его высказываний прямиком в /dev/null.

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

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


Для меня важным триггером стали два момента, озвученных Тиньковым когда он пытался сравнивать уровень развития России и США:

  • выработка электроэнергии в США в 50 (пятьдесят, это не моя опечатка, сам Тиньков на этом внимание заострял) раз больше, чем в России. Первая же ссылка в Гугле идет на Wikipedia (со ссылкой на British Pertroleum), где сказано, что за 2021-й год в США было произведено 4406 ТВт-ч, тогда как в России -- 1157 ТВт-ч.
  • протяженность железных дорог в США и России. Опять же, смотрим в Wikipedia и видим, что на 2022-ой год суммарная длина ж/д в США 293564км, тогда как в РФ всего 85500км. Казалось бы да, существенная разница (хотя здесь надо было бы учесть и длину дорог в бывших республиках СССР, и даже в Польше и Финляндии, которые когда-то входили в состав Российской Империи). Но вот если послушать знающего человека, то окажется, что не все так однозначно и не в длине счастье.

В общем, в вопросах бизнеса и маркетинга Олег Тиньков, для меня лично, величина.

А вот зачем слушать его мнение на счет геополитики мне не понятно.

вторник, 8 ноября 2022 г.

[life.cinema] Кратко о фильме "На Западном фронте без перемен" 2022-го года

Посмотрел на выходных новый фильм от Netflix "На Западном фронте без перемен", по мотивам одноименной знаменитой книги Ремарка.

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

Книгу "На Западном фронте без перемен" прочитал в выпускном классе школы и она перевернула мои представления о том, что из себя представляет война. Т.к. в советских книгах о войне, которые издавались в 60-70-х и начале 1980-х, такой жести именно про быт на войне, про ощущения простого человека, не писалось. Ну или мне не попадалось. Подозреваю, что наши редакторы и цензоры намеренно щадили читателей, особенно молодых, тех, кто о войне мог знать лишь из рассказов дедушек и бабушек. А вот Ремарк цинично срывает с читателя розовые очки героической военной романтики.

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

Посему, если говорить в двух словах, то получается как-то так: если вы читали книгу, то фильм можно и не смотреть. А если книгу не читали, то лучше таки ее прочесть, а кино можно и не смотреть.

Пожалуй, главное, чего не хватило именно мне -- это передачи мироощущения молодых людей, которые после войны были названы "потерянным поколением" (к которым, помнится, принадлежал сам Ремарк). Вчерашние школьники, которые попали на фронт прямо из-за парты. И которые ничего, кроме войны, не видели, и ничего, кроме войны, не умеют. И которые не понимаю ради чего на этой войне выживают. И не знают, что их ждет позже. Дилогия Ремарка "На Западном фронте без перемен" и "Возвращение", как мне показалось, именно про это.

Тогда как фильм от Netflix, по ощущениям, пытается сконцентрироваться только на том, что война -- это ужас-ужас. И все, не более того.

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

Визуальная часть вполне себе OK, хотя даже здесь нет никаких открытий и откровений. Спасти рядового Райана, Во имя чести и 38-я параллель задрали здесь планку качества так, что не только лишь все могут до нее дотянуться.

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

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

четверг, 3 ноября 2022 г.

[work.memories] Понравилась мне на Хабре статья от корпоративного архитектора в Сбербанке

Отличная статья: Как я в зеленом банке архитектором работал.

Думал просто просмотреть по диагонали, но залип.

Вспомнилось всякое из прошлого, т.к. в свое время доводилось иметь дело с разработкой для банков (к счастью, не долго и немного), и для этого самого зеленого банка в частности :)

Я у себя в VK недавно давал ссылку на свой старый текст в блоге, а там был вот такой фрагмент:

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

Если кому-то показалось, что я преувеличивал, то почитайте вышеупомянутую статью на Хабре :) Думаю, что в мое время в Сбербанке регламенты были послабже и вопросы решались несколько быстрее...

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

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

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

Но, тем не менее, как вспомню всю эту корпоративную херню, так не по себе становится.

Кстати, о корпоративной херне. Последние пару лет работы в "Интервэйле" прошли под знаком попыток перехода на бюрократизированные рельсы. Фактичести, менеджеры с бэкграундом в банковской сфере попытались перестроить правила работы софтверной компании. Со всеми вытекающими.

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

И ведь разбирались, что характерно.

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

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

Мой мимиметр зашкалил от уровня мимишности этих ожиданий.

Какой "наивный чукотский юноша" :) Говорю это без отрицательных конотаций. Просто лучшего афоризма для обозначения столь высокой степени наивности не вспомнилось.

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

вторник, 1 ноября 2022 г.

[life.cinema] Очередной кинообзор (2022/10)

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

Фильмы

Добрый медбрат (The Good Nurse, 2022). Хорошее кино. Но! Его нужно смотреть не читая предварительно описание того, о чем эта картина. Иначе никакой интриги не будет, останется только наблюдать за хорошей игрой актеров.

Массовый побег (Pacto de Fuga, 2020). Нормальный фильм, даже не хочется ни к чему придираться. Но, все-таки, мне не хватило какого-то нерва, чтобы переживания за главных героев нарастали и к концу фильма достигли своего апогея.

Большой куш (Jipuragirado japgo sipeun jimseungdeul, 2020). Мне зашел, но мне нравятся такого рода истории, когда куча независимых на первый взгляд сюжетных нитей в итоге тесно переплетаются. Разве что динамизма хотелось бы чуть побольше.

Лучшие в аду (2022). Суровое кино. Пожалуй, лучшее на военную тематику за последний год (если не больше). Меня, правда, сильно раздражали вставки с пояснениями и ТТХ вооружений. Однако, думаю, что если бы этих вставок не было, то фильм бы воспринимался еще более суровым и трагичным.

Бандит (Bandit, 2022). Так себе кино. Потенциально интересную историю рассказали настолько убого, что получился какой-то дешевый водевиль.

Код Красный (Red Joan, 2018). Красиво, добротно. И не такой шлак, как "Красный воробей". Но, тем не менее, явно снято для внутреннего потребления нашим "вероятным противником", с замшелыми штампами про кровавого тирана Сталина и преувеличением значимости английской ядерной программы во время Второй Мировой войны.

Быстрее пули (Bullet Train, 2022). Динамично, да и снято весьма качественно. Но вот в меня не попал совершенно. Какой-то юмористический комикс на фоне горы трупов и жестоких убийств.

Человек из Рима (The Man from Rome, 2022). Из хорошего только отличная операторская работа. Все остальное откровенная халтура, начиная от шаблонно-картонных персонажей и заканчивая откровенно дерьмовой постановкой тех немногих сцен с рукопашными схватками, которым нашлось место.

Средневековье (Jan Žižka, 2022). Мне фильм показался затянутым и плохо раскрывающим суть происходящих событий (кто кем и кому приходился и из-за чего весь сыр бор). Да и работа оператора меня, мягко говоря, раздражала.

Сериалы

Дивный новый мир (Brave New World, 2020, первый сезон). Сам исходный роман не читал, поэтому оцениваю только то, что увидел и понятия не имею насколько это все соотносится с оригиналом. Снято красиво. Но, такое ощущение, что фильм должен быть интересен разве что молодой аудитории, лет до 25, может быть до 30, пока еще гормоны бурлят. Для людей постарше эта вся излишняя концентрация на сексе выглядит уже странно.

Художник (первый сезон, 2021). Редкостная халтура. Смело можно не смотреть.

Кино вне категории

Последний клиент (Klienten, 2022). Так и не понял что сказать по поводу этого фильма. С одной стороны, хороший сюжетный поворот в самом конце. С другой стороны, большую половину фильма происходящее на экране вызывает вопрос "Что за фигню здесь показывают?" И я не уверен, что финальный твист все это окупает. В общем, кого-то этот фильм может привести в восторг, а кого-то сильно разочаровать.

суббота, 29 октября 2022 г.

[prog.c++] Дикая идея о том, как можно было бы еще улучшить fmtlib и std::format

Навеяно срачем на RSDN вот в этой теме.

По сути, там были указаны реальные проблемы, которые есть при использовании fmtlib и, соответственно, std::format.

Одна из этих проблем в том, что для описания форматера для моего типа T мне нужно делать специализацию для fmt::formatter, а это нельзя сделать в моем пространстве имен. Поэтому, если я в своем пространстве имен только что определил тип T, то мне нельзя здесь же определить и фоматтер для него, нужно сперва закрыть свое пространство имен, а потом открыть его вновь.

Еще одна проблема показана вот в этом комментарии. Позволю себе процитировать:

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

namespace htlib::v2
{
template<typename type_t>
struct is_point {

    static std::false_type test(...);
    template<htlib::v2::uint_t dimensions, typename other_t>
    static std::true_type test(const htlib::v2::pointxd_t<dimensions, other_t>&);

    static constexpr bool value = decltype(test(std::declval<type_t>()))::value;
};
template<typename type_t>
inline constexpr bool is_point_v = is_point<type_t>::value;

// namespace htlib::v2

template<typename char_t, typename point_t>
class std::formatter<point_t, char_t, std::enable_if_t<htlib::v2::is_point_v<point_t>>>
{
//...
}

Вот такие мета-функции приходится писать что бы написать форматер для всех наследников базового шаблонного класса.

Хотя в случае с функциями была простая перегрузка, типа:

template<htlib::v2::uint_t dimensions, typename other_t>
void formatter(const htlib::v2::pointxd_t<dimensions, other_t>&);

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

Очень хорошо выгоды от свободных функций сформулированы здесь:

если бы std::format для кастомизации использовал бы не шаблон класса со специализациями, а неквалифицированный вызов функции с каким-то предопределенным именем, это могло бы дать ряд преимуществ:

  • Пользователь мог бы определять кастомные форматтеры в том же пространстве имен, что и пользовательские типы. Это удобнее писать и удобнее читать, потому что не нужно рвать пространства имен или выносить определения в какие-то отдельные места;
  • При определении кастомных форматтеров пользователь мог бы использовать дополнительные параметры по умолчанию — как в списке шаблонных параметров, так и в списке формальных параметров функции, что дает возможность использования SFINAE и вообще дает большую гибкость в тех случаях, когда кастомизацию нужно сделать не для одного конкретного типа, а для какого-нибудь сеймейства типов, объединенных каким-то признаком;
  • Как частный случай — форматтер, определенный для базового класса автоматом будет работать и для всех производных, для которых не предоставлена своя собственая версия форматтера;
  • Используя квалифицированные вызовы, пользователь мог бы внутри кастомго форматтера повторно использовать форматтеры из других пространств имен, что дает возможность декорирования форматтеров.

Хотя лично мне перспектива писать свободные функции parse и format для своих типов не очень нравится, имхо, класс formatter с методами parse и format для таких целей удобнее, имхо. Да и совместимость с уже написанным кодом терять не хочется, так что подход со свободными функциями должен как-то сочетаться с уже написанными formatter-ами.

Посему возникла дурацкая идея о том, как можно подружить оба эти подхода.

Суть в том, чтобы оставить класс formatter как он есть. Но не создавать его напрямую, а получать посредством свободной функции-фабрики. Как раз эту самую функцию-фабрику можно будет определить в собственном пространстве имен рядом со своими типами.

Под катом слепленный на коленке за 10 минут пример того, как это может быть.

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

А копать глубоко нет возможности. Я тут, к сожалению, слегка зашился и чувствую, что едва хватает сил на выполнение обязательств по текущему проекту. Даже за PR для RESTinio не могу взяться :(

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

Напоследок скажу, что на RSDN-е были таки обозначены актуальные проблемы, с которыми люди сталкиваются в fmtlib и std::format. И было бы хорошо тем или иным способом решить эти проблемы. Наверняка способы найдутся.

понедельник, 24 октября 2022 г.

[prog] Ссылки на несколько критических по отношению к языку Go статей

Решил собрать в одно место ссылки на несколько статей, в которых рассказывается насколько в языке Go не все хорошо. В склерозник, что называется.

Первая статья: Data Race Patterns in Go. Специалисты из Uber-а приводят перечень проблем с многопоточностью, с которыми они столкнулись в своей кодовой базе. Общее впечатление от статьи: слишком уж много косяков в языке, который кичиться своей простой и удобной моделью конкурентного программирования.

Вторая статья: We Need To Talk About The Bad Sides of Go. На самом деле это один из постов в серии, где рассказывается о том, что в Go хорошо, что плохо и что хотелось бы исправить автору этой самой серии.

Третья, но даже не статья, а серия статей о недостатках языка Go. Приведу ссылку только на первую из серии, все остальные ссылки уже там, внутри. Итак, начинать следует отсюда: Go'ing Insane Part One: Endless Error Handling.


В общем-то, желания связываться с Go и так не было, а стало еще меньше :)

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

воскресенье, 23 октября 2022 г.

[life] Очередная веха в прослушивании плейлистов дня на Yandex.Music

Странная история (в плане того, что я сам не понимаю зачем она мне), о которой уже писал. Но есть повод вернуться к ней еще раз.

В сентябре 2022-го счетчик достиг значения 730, т.е. ровно два года ежедневного пользования плейлистами дня на Yandex.Music.

Тогда встал вопрос о том, а что дальше.

Дальше маячило красивое число 777.

Ну и вот, собственно.

Честно скажу, я сам понятия не имею зачем мне это все нужно.

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

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

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

Будет ли продолжение у этой странной истории?

А вот фиг знает. Хотелось бы, конечно, и до 888 довести. Но недавний негативный опыт с попыткой продления подписки на Yandex.Plus (раз, два, три) наводит на мысли, что в текущее турбулентное время подписки на сетевые сервисы не есть удобно и надежно. И прерваться все это может внезапно и не по твоей вине. Так что будем посмотреть.

пятница, 21 октября 2022 г.

[work.idiotic] Что-то меня триггернуло с раздела "Короткая память" в статье "Молодежь нынче пошла не та, или поиск системного аналитика «за 200»"

Собственно, вот статья на хабре: Молодежь нынче пошла не та, или поиск системного аналитика «за 200»

А вот целиком раздел, который меня триггернул:

На вопросы о том, что было пару лет назад, кандидаты часто отвечают «это было давно, не помню уже». Так отвечали про свой прошлый проект – в чем была его суть и ценность, про нотацию диаграмм которую использовали на прошлом месте работы, или про структуру спецификации требований.

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

Почему меня это расстраивает? Это обесценивает опыт. Полученный опыт переходит в устойчивые умения и навыки, повышающие ценность сотрудника, только после фазы осознания и рефлексии. Ответ «не помню» позволяет предположить, что полученный опыт был выкинут из головы сразу же после завершения работы, и никак не закрепился. При таком подходе полезность и ценность сотрудника растёт медленно (если вообще растёт).

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

А вот я, например, такой памятью не обладаю. Быстро забываю то, чем не пользуюсь на постоянной основе.

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

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

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

Какое именно решение в итоге было сделано я уже и не помню. Чтобы вспомнить, мне нужно посидеть в тишине минут 15-20-30, возможно еще и порисовать каракули на бумаге. Но и то результат не гарантирован. Зато если заглянуть в исходник, то все вспомнится чуть ли не моментально.

Что уж говорить о проектах 2-3- и более летней давности.

К чему я это?

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

Посему незачем подходить к людям с единой меркой.

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

воскресенье, 16 октября 2022 г.

[prog.wow] Неожиданное применение SObjectizer-а :)

Когда-то Страуструп сказал что-то вроде "когда вы даете людям инструмент, то вы даже представить себе не можете какими неожиданными способами этот инструмент будет применяться". Вот я сегодня увидел очередное подтверждение этой мысли. Стал читать статью Есть ли жизнь без RTTI: пишем свой dynamic_cast от разработчиков PVS-Studio, а там SObjectizer упоминается. В списке тестовых проектов на которых гоняют новые версии PVS-Studio.

Вот ведь, чего только не бывает :)

PS. Кстати говоря, пересекался с ребятами из PVS-Studio на конференциях по C++. Очень надеюсь, что у них все хорошо, и введенные против РФ санкции на них пагубно не сказались.

понедельник, 10 октября 2022 г.

[work;business;life] Очередной ДР у StiffStream-а

Официально "СтифСтрим" начал свое существование 10-го октября 2016-го года. Так что сегодня у нашей маленькой компании очередной день рождения, нам уже шесть.

Конечно, когда все это начиналось в 2016-том, то будущее спустя 5-6 лет виделось совсем другим, более ярким и красочным :)

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

Хотя тут как посмотреть, т.к. начинали мы совсем маленькой компанией -- три человека в штате и один совместитель, а за прошедшие шесть лет стали совсем крохотной: один штатный сотрудник + один совместитель. Благо ушедшие ребята, с которыми мы это все организовывали, помогают по мере сил, за что им отдельное спасибо.

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

  • то, что называется wishful thinking. Не сказал бы, что мы безоглядно выдавали желаемое за действительное (но и не возьмусь утверждать обратного), скорее была в нас слишком сильная вера в то, что мы "прогнем этот изменчивый мир" своими способностями и своим упорством. Типа "терпение и труд все перетрут" + "у нас крутые продукты" и вот это вот все;
  • то, что мы располагали возможностью сразу много инвестировать в компанию и долгое время не уделяли достаточного внимания заказной разработке.

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

Вероятно, самое важное, что произошло с моим мировоззрением за последнее время -- это отношение к перспективе принять решение о закрытии компании.

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

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

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

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

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

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

Посему продолжаем продолжать :)

Кстати говоря, ген велосипедостроения во мне настолько силен, что мне временами кажется, что даже "СтифСтрим" -- это лисапед, придуманный и сделанный для того, чтобы работать так, как нравится и хочется. Точно так же как наши библиотеки были придуманы и сделаны для того, чтобы писать программы так как нравится и хочется, с наименьшим количеством сложностей.


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

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

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


PS. Если кто не в курсе, "СтифСтрим" по-русски означает "упрямый поток". Или, более точно, "упертый поток". Думаю, что шесть лет существования "СтифСтрима" наглядно показывают, что упертости нам не занимать ;)

суббота, 1 октября 2022 г.

[life.cinema] Очередной кинообзор (2022/09)

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

Фильмы

Шпион, которого не было (Rogue Agent, 2021). Мне очень понравился. Может быть слегка затянут, но не сильно и, возможно, это тоже работало на вовлечение зрителя в происходящее. Так что один из немногих вменяемых фильмов за последнее время.

Тед К. Унабомбер (Ted K, 2021). Если бы его сократить минут на 15-20, то было бы просто отличное кино. А так получилось слишком уж заунывно местами. Но все равно на фоне остального киношлака это хоть что-то достойное просмотра.

Ведьма (Manyeo, 2018) и Эксперимент "Ведьма" (Manyeo 2, 2022). Я сперва посмотрел вторую часть ничего не зная про первый фильм. Показалось, что история рассказана так, как будто это продолжение чего-то. Выяснилось, что есть еще и первая часть. Так что посмотрел эти фильмы в обратном порядке. И могу сказать так: первая часть мне зашла, хотя кино на любителя, скажем так. А вот вторую можно и проигнорировать.

Черный телефон (The Black Phone, 2021). Вроде бы и снято хорошо, и следить за происходящим интересно. Но, во-первых, не страшно. И, во-вторых, быстро начинаешь понимать, что "финал окажется несколько предсказуем" (с). В итоге я так и не понял, понравилось ли мне или нет. Скорее не понравилось.

Я был там (I Came By, 2022). Странные впечатления от фильма. Вроде бы и сюжет нормальный, и актеры пытаются играть, и куча трупов образовалась в процессе. А вот никакого желания сопереживать происходящему на экране не происходит. Так что глянуть можно, но меня не торкнуло.

Стейк от кутюр (Tendre et saignant, 2020). Большую часть фильма смотреть было интересно, но вот финал откровенно разочаровал. Такое ощущение, что ради хэппи-энда создатели фильма решили наплевать и послать по известному адресу всю логику предыдущего повествования.

Тор: Любовь и гром (Thor: Love and Thunder, 2022). Ну такое себе. Третий Тор был смешным и в должной мере самоироничным, этот попытались сделать в таком же духе, но получилось какое-то лоскутное одеяло, в котором какие-то фрагменты еще ничего, но остальное сильно так себе. Любителям серии можно глянуть, а вот нелюбители могут смело проходить мимо.

Вышка (Fall, 2022). Как по мне, так заурядная сказочка, в которой есть всего один интересный момент, а все остальное вызывает желание воскликнуть "не верю!"

Барракуда (The Enforcer, 2022). Занудно и экшена не хватает.

В постели с незнакомцем (The Stranger in Our Bed, 2021). Пока смотришь, то вроде бы интересно. Но когда в финале пытаешься связать воедино все ниточки, то возникает ощущение, что тебе попытались впарить какую-то нелогичную фигню. Так что меня лично фильм сильно разочаровал.

Пропавшая (Alone, 2020). Начиналось очень даже неплохо. Но затем повествование свалилось в такую муть, что оставалось только разбивать себе лицо фейспалмами.

Сериал

Перевал (Der Pass, 2018, два сезона). В обоих сезонах первые пару серий достаточно нудные, их нужно перетерпеть (особенно во втором сезоне). Дальше все смотрится достаточно интересно, но вот финалы лично меня разочаровали, особенно во втором сезоне. Так что на безрыбье сойдет, но чего-то выдающегося ждать не стоит.

пятница, 30 сентября 2022 г.

[soft.bragging] Третья сотня звезд на GitHub-е для SObjectizer

Однако, триста.

Очередные сто звезд были накоплены практически за год, вторая сотня звезд была набрана в начале сентября 2021-го года.

Что особенно отрадно, как это то, что очередная сотня была набрана практически без PR-а с нашей стороны. Всего каких-то жалких три статьи на Habr-е и лишь один анонс на reddit-е. В районе 2017-2020 годов в популяризацию SObjectizer-а нами вкладывалось гораздо больше усилий.

Традиционно уже скажу, что проект живет. В 2022-ом даже получилось сделать полноценный релиз SObjectizer-5.7.4 и so5extra-1.5.0. И пусть это относительно минорные обновления, но на фоне всей той жести и неопределенности, которая творится в мире в последние два года, удалось сделать хотя бы это.

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

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

В заключение хочу поблагодарить всех, кто рискнул выбрать SObjectizer для своего проекта или иным образом поспособствовал его популяризации. Если бы не вы, то история SObjectizer-а уже давно бы закончилась. А так еще поборемся... :)

вторник, 27 сентября 2022 г.

[prog.c++] Опыт встраивания интепретатора Python-а в C++ приложение посредством pybind11, vcpkg и CMake

Давеча потребовалось встроить интерпретатор Python-а в C++ приложение.

Поскольку в проекте уже использовался vcpkg, то часть проблем отпала сама собой: подтянуть Python3 в проект и слинковаться с ним особой проблемы не составило. Правда пришлось в CMakeLists.txt для приложения, в которое Python3 вставлялся, добавить несколько строчек, чтобы на Linux-е к приложению линковалось бы еще и библиотеки util и dl.

Под Linux-ом результирующий бинарник даже сразу запустился. А вот под Windows при старте приложение выдавало ошибку типа вот такой:

Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized

ModuleNotFoundError: No module named 'encodings'

и все, никакой нормальной работы.

Как я понял, проблема в том, что когда Python стартует, то он пытается разыскать свою стандартную библиотеку (т.е. туеву хучу *.py файлов). И под Windows он ее найти не может.

В процессе разбирательства выяснилось интересное. Когда мы работаем в Linux-е, то vcpkg при компиляции Python3 раскидывает компоненты Python следующим образом (cmake-build -- это каталог, в котором идет сборка проекта):

суббота, 24 сентября 2022 г.

[prog.flame] Пару слов на тему cpp2/cppfront от Герба Саттера

Досмотрел выступление Герба Саттера на CppCon 2022, где он рассказывал про свой эксперимент на тему cpp2 и транслятора cppfront.

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

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

Так что всячески желаю этому проекту успехов и бурного развития.

Но, с другой стороны, вот что меня сильно смущает.

среда, 21 сентября 2022 г.

[prog.c++] Отказался от использования маркера can_throw в arataga

В проекте arataga использовался прием, который на момент активной работы над arataga, существенно повышал мне коэффициент спокойного сна. Подробнее об этом трюке я писал два года назад на Habr-е: can_throw или не can_throw?

В двух словах: в функции/методы, в которых можно было спокойно выбрасывать исключения, передавался специальный маркер типа can_throw_t. Этот маркер указывал, что функция/метод вызывается из контекста, в котором исключения перехватываются и обрабатываются. Соответственно, если такой маркер в функции/методе есть, значит я могу сделать throw или вызвать какую-то бросающую исключение операцию. А если такого маркера нет, то мне нужно обрамить свои действия блоком try-catch.

К появлению can_throw привело то, что в arataga пришлось писать много callback-ов, которые вызывались при выполнении IO-операций через Asio и парсинге HTTP-протокола посредством http_parser. В таких контекстах исключения нельзя было выпускать наружу и требовалось понимать, пишу ли я сейчас код для callback-а или для чего-то другого.

Надо сказать, что прием can_throw мной всегда оценивался как не вполне однозначный.

Да, на этапе активной разработки arataga он сыграл свою положительную роль. И я до сих пор думаю, что если бы не вспомнил про идею с can_throw (это не моя придумка, когда-то что-то подобное обсуждалось на одном из форумов), то реализация первой версии arataga наверняка затянулась бы и мне пришлось бы потратить больше усилий на тестирование.

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

Потом же развитие aragata было заморожено вообще. Сейчас этот проект важен для меня как демонстрация того, как выглядит реальный код для продакшена на SObjectizer.

Кроме того, arataga представляет из себя отличный полигон для проверки нововведений в SObjectizer. Т.е. если есть идея какой-то новой фичи для SObjectizer-а и эта фича упростит потроха arataga (или снизит накладные расходы), значит фича стоит того, чтобы ее воплотить в жизнь.

Проект arataga интересен еще и тем, что это один из двух проектов за последние несколько лет, в которых я серьезно задумывался над использованием stackfull-короутин. В arataga в виде короутин можно было бы реализовать обработчики отдельных подключений (т.е. модель coroutine per connection). И, если бы в SObjectizer была поддержка stackfull-короутин "искаропки", то может быть именно с модели coroutine per connection я реализацию arataga и начал бы.

Но в SObjectizer поддержки stackfull-короутин нет. Все еще нет.

Давеча у меня появилось некоторое время чтобы подумать о том, что же в SObjectizer можно добавить. Вариантов для рассмотрения не так, чтобы много, и stackfull-короутины в short-list-е.

Тут-то проект arataga в очередной раз и вспомнился. Если добавлять короутины в SObjectizer, то в arataga их можно будет и сразу же протестировать "в деле".

Дабы освежить в памяти детали работы arataga погрузился в код...

И слегка прифигел от количество can_throw в реализации connection-handler-ов.

Когда смотришь свежим взглядом на то, что сам же делал два года назад и уже основательно все позабыл, то твой собственный код уже выглядит как чужой. Что дает возможность оценивать его объективно и непредвзято.

Обилие can_throw обескуражило настолько, что стало понято, что с этим нужно что-то делать. Только после этого можно было задуматься о попытке переписать arataga на короутинах.

Анализ кода показал, что сейчас в arataga осталось совсем не так много мест, в которых нужно заботиться о выбросе исключения наружу. И эти все места уже старательно обернуты в try-catch. Так что can_throw реально стал выглядеть избыточным рудиментом.

Поэтому в итоге can_throw из кода arataga был полностью изъят.

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

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

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


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

PS. Я заикнулся о том, что рассматриваю возможность добавления stackfull-короутин в SObjectizer. Но тут все очень не просто. Погружение в arataga наводит на мысль о том, что stackfull-короутины здесь могут и не помочь. Так что еще рано говорить о том, что решение о добавлении stackfull-короутин в SObjectizer принято. Тут еще нужно думать и думать, да и вообще это уже совсем другая история.

воскресенье, 18 сентября 2022 г.

[photo.wtf] Что-то меня нехило так бомануло при попытке посмотреть запись стрима с разбором композиции в фотографии учеников

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

Благо на YouTube можно не только увеличить скорость воспроизведения, но и проматывать откровенно пустую болтологию. Так что потратив не сильно много времени (но уже несколько афигев от бесполезности длинных вступительных слов) я таки добрался до разбора первых нескольких фотографий.

И уже на втором снимке меня бомбануло так, как не бомбило уже давно.

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

И все!

Ну ахиреть, блин.

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

суббота, 17 сентября 2022 г.

[prog] В склерозник: статья с поверхностным разбором принципов решения задач на coding interview

В кои-то веки в дайджесте от Medium проскочила интересная ссылка: Popular Problem-Solving Approaches in Data Structures and Algorithms.

В ней кратко описываются несколько категорий подходов к решению алгоритмических задачек, которые любят использовать на собеседованиях. Плюс ссылки на примеры этих самых задач с разборами возможных решений (я так понял, что все ссылки ведут на https://www.enjoyalgorithms.com/coding-interview/).

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

пятница, 16 сентября 2022 г.

[prog.c++] Хочется странного: структуры, которые можно инициализировать только посредством designated initializers

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

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

frames_buffer_t make_buffer(size_t frame_size, size_t frames_count);

При вызове такой функции запросто можно перепутать аргументы местами и написать:

auto buf = make_buffer(32, 1024);

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

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

struct capture_params_t {
  size_t m_frame_size;
  size_t m_frames_count;
  ...
};

Поскольку, опять же, если мы оперируем только примитивными типами, то глядя в код сложно понять, все ли с ним нормально:

capturing_stream_t make_stream(const capture_params_t & params) {
  auto buf = make_buffer(params.m_frames_count, params.m_frame_size);
  ...
}

Или даже так:

capture_params_t tune_params(const capture_params_t & default_values) {
  capture_params_t result{ default_values };
  if(has_enough_memory()) {
    result.m_frame_size = default_values.m_frames_count * 4u;
    ...
  }
  ...
  return result;
}

Тогда как в случае использования даже примитивных strong typedef подобные ошибки самим компилятором отлавливаются на раз. Ну и при чтении кода как-то все более понятно. ИМХО, конечно же.

Самый простой вариант в C++ после C++11 -- это что-то вроде:

struct frame_size_t { size_t m_value; };
struct frames_count_t { size_t m_value; }

frames_buffer_t make_buffer(frame_size_t frame_size, frames_count_t frames_count);

Что приводит к тому, что в коде уже приходится писать так:

auto buf = make_buffer(frame_size_t{32}, frames_count_t{1024});

И тут уже глядя на код можно задуматься, а нормально ли, что у нас в буфере большое количество маленьких фреймов? Может быть должно быть наоборот?

В общем, в последнее время пытаюсь регулярно применять strong typedef в том или ином виде.

Но время от времени сталкиваюсь со случаями, когда введение strong typedef в виде отдельных типов выглядит как overkill.

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

class probe_result_t
{
    friend class data_collector_t;

    int m_read_pos;
    int m_write_pos;
    int m_size;

    probe_result_t(int read_pos, int write_pos, int size)
        : m_read_pos{read_pos}, m_write_pos{write_pos}, m_size{size}
    {}

public:
    [[nodiscard]] int size() const noexcept { return m_size; }
};

И вот у него в конструктор передаются параметры одного типа, что мне не нравится.

Но и не хочется превращать этот простой класс во что-то подобное:

class probe_result_t
{
    friend class data_collector_t;

    struct read_pos_t { int m_v; };
    struct write_pos_t { int m_v; };
    struct size_t { int m_v; };

    int m_read_pos;
    int m_write_pos;
    int m_size;

    probe_result_t(read_pos_t read_pos, write_pos_t write_pos, size_t size)
        : m_read_pos{read_pos.m_v}, m_write_pos{write_pos.m_v}, m_size{size.m_v}
    {}

public:
    [[nodiscard]] int size() const noexcept { return m_size; }
};

Как по мне, так отличным решением здесь могло бы стать использование вспомогательной структуры и добавленных в C++20 designated initializers:

class probe_result_t
{
    friend class data_collector_t;

    struct params_t
    {
        int m_read_pos;
        int m_write_pos;
        int m_size;
    };

    params_t m_v;

    probe_result_t(params_t params)
        : m_v{params}
    {}

public:
    [[nodiscard]] int size() const noexcept { return m_v.m_size; }
};

Создавать экземпляр probe_result_t можно было бы просто и наглядно:

probe_result_t data_collector_t::probe_collected_data()
{
    ...
    return { { .m_read_pos = rp, .m_write_pos = wp, .m_size = ds } };
}

Но вот беда... Нельзя в C++ указать, что экземпляр структуры можно проинициализировать только посредством designated initializers. Старый-добрый initializer list вполне себе будет работать:

probe_result_t data_collector_t::probe_collected_data()
{
    ...
    // Так можно написать, а хотелось бы, чтобы это было под запретом.
    return { { rp, wp, ds } };
}

Наверное, мне таки нужны именованные аргументы, которые есть в некоторых других языках программирования. Но в C++ именованных аргументов точно не будет. А вот designated initializers уже есть...

[prog.angriness] Простите, я о наболевшем на наглядном примере

Не будет большим преувеличением сказать, что каждый раз, когда мы рассказывали на профильных форумах о своих OpenSource разработках, то основной реакций было "да вы сделали никому не нужное говно". Складывалось ощущение, что вокруг они супер-пупер-монстры от программирования, которые могут написать что угодно за пару-тройку дней не отвлекаясь от LOR-овских или RSDN-овских срачей.

Но, блин, если все вокруг такие крутые спецы, которые могут на коленке слабать альтернативу SObjectizer-у или RESTinio, да еще и в 100 раз лучше, то откуда в реальной жизни возникают вопросы типа вот этого: как оптимизировать с++ код, чтобы 7000 бинарников не выедали всё cpu?

Вопрос риторический.

Просто если кто-то планирует делать свои инструменты для разработчиков и собирается рассказывать об этом на профильных ресурсах, то будьте готовы к тому, что вы неизбежно окажетесь в среде, где 95% высказавшихся будут знать больше и уметь лучше, чем вы.

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

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

четверг, 15 сентября 2022 г.

[prog.c++] Любопытная задачка с RSDN про гарантии вызова реализации виртуального метода из базового класса

На RSDN-е задали любопытный вопрос. Я этот вопрос понял так:

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

Грубо говоря, вот так нормально:

class A {
public:
   virtual void f() { std::cout << "A::f()" << std::endl; }
};

class B : public A {
public:
   void f() override {
      A::f();
      std::cout << "B::f()" << std::endl;
   }
};

а вот так уже нет, за такое нужно бить по рукам:

class A {
public:
   virtual void f() { std::cout << "A::f()" << std::endl; }
};

class C : public A {
public:
   void f() override {
      std::cout << "C::f()" << std::endl;
   }
};

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

понедельник, 12 сентября 2022 г.

[soft.dev.wtf] Это написано по-русски или по-английски, но русскими буквами?

Отличный абзац в статье на русском языке от представителя российской компании:

Каждой фича-команде завели папки в регресс- и смок-сьютах, а в них уже поместили необходимые кейсы. Ну а чтобы в красивый чистый регресс-набор не попадали драфт-кейсы, завели отдельное пространство с кодовым названием “Кандидаты в регресс”. Некий аналог develop-ветки в git’е. Кейсы лежат там до тех пор, пока не пройдут ревью, и не откроется фича-флаг в новом релизе приложения.

цинк.

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

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

С другой стороны, я уже старый, да и сильно оторванный от современных подходов к разработке ПО, особенно молодыми, динамичными коллективами. Возможно, это мне уже в силу старческого маразма написанное плохопонятно, а 20-летним синьор-КьюАрам все более чем очевидно? :(

среда, 7 сентября 2022 г.

[prog.flame] LOR-овского lovesan-а не взяли в Тинькофф и понеслось говно по трубам...

Есть на LOR-е специфический персонаж lovesan. Имел удовольствие несколько раз с ним сраться на LOR-е про C++. На меня он произвел впечатление рядового программиста, самомнение и наглость которого заставляет завидовать даже меня. При этом, не сильно вменяемого и способного воспринимать чужую точку зрения.

Как-то в одном из срачей всплыл его C++ный код, по которому я слегка прошелся. Код так себе, совершенно рядовой, его несложно было бы написать и получше. Но в сочетании с апломбом автора, который ведет себя как будто круче него только горы и яйца, получается эффект "на словах ты Лев Толстой, а на деле х*й простой". Желающие составить собственное мнение могут пройти по ссылке и полюбопытствовать. Ниже будет еще одна ссылка на lovesan-овский GitHub-репозиторий с .NET-кодом, можно заглянуть и туда, .NET разработчикам может быть интересно сделать собственную оценку.

Так вот давеча lovesan разразился большим постом в Facebook. Полагаю, дерьмо по трубам уже понеслось, поэтому если и я выскажусь по этому поводу, то сильно хуже не станет. Полный текст поста lovesan-а будет под катом, для истории и для тех, кто в FB без VPN зайти не может (ну и чтобы самому этот образчик изящной словестности искать проще было).

Мои симпатии в этой истории всецело на стороне Тинькофф. Технический косяк на собеседовании -- это, конечно, минус им в карму. Но общее решение не связываться с lovesan-ом только приветствую.

И надеюсь, что специалисту Тинькофф, который lovesan-а собеседовал, не прилетит по шапке.

понедельник, 5 сентября 2022 г.

[prog.c++] Давненько не сталкивался с неспособностью компилятора переварить наш C++ный код...

Готовлю к релизу небольшое обновление для RESTinio. Там суть в том, что в fmtlib есть возможность контроля за форматной строкой в compile-time. Для этого, когда мы находимся в рамках стандартов C++11/14/17, требуется помещать форматную строку внутрь макроса FMT_STRING:

fmt::print(FMT_STRING("The answer is {}\n"), 42);

Фокус в том, что макрос FMT_STRING должен применяться когда задан символ препроцессора FMT_ENFORCE_COMPILE_STRING. Если этот символ не задан, то форматная строка должна быть обычным строковым литералом.

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

Вроде как все сделал еще три недели назад, но приступить к подготовке релиза выдалась возможность только сейчас. Заодно оказалось, что fmtlib обновился до 9.1.0, поэтому я решил проверить RESTinio еще раз, уже с более свежей fmtlib.

И тут-то и оказалось, что в режиме C++20 и FMT_ENFORCE_COMPILE_STRING пара штатных тестов и один пример не компилируются clang-14.

Компилятор clang-14 как-то матерно ругался вот на такие строчки в одном из тестов (раз и два). Мол, какой-то из dependent type где-то в нутрях fmtlib не определен. А где и какой непонятно.

Пришлось несколько часов курить бамбук, пробовая и так, и сяк. Особенно удивляясь тому, что gcc-11 проглатывает этот же код нормально. Да и сам clang-14 похожий код в других местах вполне себе компилирует.

Лучик света забрежжил, когда я закомментировал вызов fmt::format на самом глубоком уровне вложенности (вот здесь).

Оказалось, что оставшийся вызов fmt::format после этого успешно скомпилировался, хотя до этого clang на него ругался.

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

Вынес часть функционала в отдельную вспомогательную функцию (делай раз, делай два) и...

Вуаля! Все скомпилировалось.

Морали не будет. Но будет озвучен вопрос, который меня серьезно озаботил: ну ладно, я-то давно люблюсь с C++ и C++ными компиляторами, падения с internal compiler error встречал неоднократно (к счастью, в последние годы все реже и реже)... А вот что было бы, если бы на моем месте был человек менее опытный? Который бы реально полез бы в потроха fmtlib чтобы разобраться что там за dependent type не определен... Вот сколько бы он времени на это убил бы?

четверг, 1 сентября 2022 г.

[life.cinema] Очередной кинообзор (2022/08)

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

Фильмы

Дневная смена (Day Shift, 2022). Треш и угар (хотя угара хотелось сильно побольше). Средней руки фильмец, я получил ровно то, чего и ожидал. Да, и мозги при просмотре нужно полностью отключать.

Киллер-хранитель (Deo killeo: jukeodo doeneun ai, 2022). Если кому-то нравятся корейские боевики со стрельбой и мордобоем, то можно глянуть. Хотя мне это кино показалось проходным и не то, чтобы халтурно сделанным, но высокого уровня в нем не чувствовалось. Ни в сценарии, ни в экшен сценах.

Город тайн (The Dry, 2020). Средней паршивости кино получилось. Как по мне, так авторы слишком уж увлеклись переплетением двух временных линий повествования из-за чего внимание зрителя рассеивается, происходящие на экране ощущается скучным и нудным, а развязка вызывает вопрос "И это все?"

Добыча (Prey, 2022). Очередная попытка заработать на "Хищнике". Получше, конечно, чем "Хищник" от 2018-го года (который был откровенным дном), но не дотягивает даже до "Хищников" от 2010 года. Можно даже глянуть, если больше смотреть нечего. Но, как по мне, так лучше еще раз пересмотреть гениальный фильм 1987-го года с Арни.

Топ Ган: Мэверик (Top Gun: Maverick, 2022). Заодно пересмотрел и первого Топ Гана. Редкой тупости кино. Причем оба фильма. Смотреть новый Топ Ган можно разве что если у вас, по какой-то причине, сохранились теплые впечатления от первого фильма и хочется понастольгировать.

Сериалы

Джек Ричер (Reacher, 2022, первый сезон). Посмотреть можно, но местами скучновато. Плюс главный герой изображен таким суперменом, что волноваться за него или сопереживать ему даже и не хочется.

Вечность (Forever, 2014-2015, два сезона). По началу интересно, но затем надоедает слишком уже динамичная подача и слишком уж выдающийся главный герой. Все настолько схематично и бодро (ради экономии экранного времени), что не успеваешь проникнуться к персонажам симпатией или антипатией, ни за кого не переживаешь. Главное достоинство -- много серий, которые особо не надоедают. Что позволяет смотреть сериал долго и хоть как-то компенсировать отсутствие нормального кино в последнее время.

Догоняя смерть (The Grave, 2019, первый сезон). Первые шесть серий смотрелись более-менее. Но заключительные две -- это какой-то сплошной фейспалм, да и развязка первого сезона оказалась вполне себе предсказуемой.

Правда о деле Гарри Квеберта (The Truth About the Harry Quebert Affair, 2018). Первые восемь серий откровенной тягомотины нужно просто перетерпеть. Хотя снято очень круто и как раз здесь есть то самое создание эмоциональной связи с героями, которой не хватало в "Вечности". Зато в последних двух сериях такая Санта-Барбара происходит, с таким невероятным количеством скелетов в шкафу и роялей в кустах, что можно разбить себе лицо фейспалмами. При этом итоговая версия произошедших событий представляется настолько фантастически-невероятной, что остается только сказать "Не верю!" Общее же впечатление от кино: можно не тратить свое время.

Начальник разведки (2022, первый сезон). Редкостная муть и халтура. Посмотрел только ради того, чтобы посмотреть сколько известной субстанции выплеснут на Л.П.Берия.

воскресенье, 28 августа 2022 г.

[life.photo] Несколько грустное воспоминание об увлечении фотографией

За последние несколько дней Фейсбук напомнил несколько (относительно) старых фотографий, которые были мной сделаны в период активного увлечения фотографией.

Этот период начался где-то в 2011-ом и продолжался до 2019-го. Начиная с 2020-го я уже практически не снимаю, особенно в своем любимом жанре репортажного портрета (если такой жанр вообще существует, конечно).

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

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

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

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

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

А вот репортажная фотография оказалась именно тем, что я и искал.

По сути, в репортаже все сводится к поиску места и момента.

Даже не так, наверное.

Все сводится к ощущению момента и поиску места.

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

Так что для меня фотография -- это именно что про ощущение момента. В этом суть.

Ну а две фотографии, которые зачем-то толкнули меня на написание этого текста, вот они.

Первый снимок сделан в Гомеле в 2017-ом году на "Дне Красного Носа". Это такой праздник для детей, который раньше ежегодно устраивало сообщество больничных клоунов Funny Nose.

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

Второй снимок сделан в Питере в 2018-ом году в магазине "Гитарный клуб" на Кирочной. Иллюстратор Юрий. В "Гитарном клубе" предпочитали называть своих сотрудников не продавцами, а иллюстраторами. Что, как мне кажется, было очень верно, т.к. нам показывали как инструмент способен звучать в умелых руках, т.е. иллюстрировали возможности гитары.

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

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


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

Зато хоть несколько хороших фотографий осталось на память. В конце-концов ведь все же ради этого. Наверное. В принципе.

среда, 24 августа 2022 г.

[prog.flame] Еще раз о сложности C++. Аналогия со сложностью высшей математики

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

Одним из регулярно встречающихся аргументов против C++ выступает "а вы видели, что криворукие программисты на плюсах вытворяют?"

Мол, язык плох тем, что недостаточно хороший программист легко может наговнякать на С++ лютый говнокод.

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

Сегодня хочется сказать про другое.

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

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

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

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

Наиболее яркими примерами в учебной программе стали функциональный анализ (+ частично затронутая в его рамках теория функций комплексной переменной) и уравнения матфизики. И если в матанализе я просто ничего не понимал, то в том же функциональном анализе уже ничего не понимал от слова совсем.

Но мне не приходит в голову говорить, что ТФКП -- это говно, потому что сильнасложна и нивазможнаасилить.

Нет. ТФКП -- это сложно, потому что это было разработано для решения сложных проблем. Просто моих мозгов на ТФКП не хватает.

Признаваться в собственной тупости, конечно, неприятно. Но вещи все-таки нужно называть своими именами.

C++ сложен. Так уж получилось.

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

И да, раз уж инструмент сложен, то не всем хватит мозгов осилить C++. Ну вот мне с высшей математикой же не хватило. И это нормально.

Причем то, что люди чего-то не могут освоить, в том же образовании известно давно. Не просто же так появились вступительные экзамены и экзаменационные сессии. Как раз для того, чтобы и заранее, и в процессе, отсеивать тех, кому тупо не хватает мозгов (и/или самодисциплины, и/или интереса) для изучения преподаваемых предметов. И как бы народ привык, что такая фильтрация -- это и нормально, и правильно. Лучше ничего еще не придумали вроде как.

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

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

Но, жизнь показывает, что далеко не всегда это так. Кому-то тупо не хватает мозгов освоить такой сложный язык, как C++. Это так же естественно, как и то, что у меня не хватило мозгов на изучение высшей математики. Неприятно, но естественно.

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

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


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

PPS. То, что человеку не хватило ума освоить C++ (или Haskell, или Agda, или SQL, или еще что-то) вовсе не означает, что он умственно отсталый. Он просто недостаточно хорош именно в этом. Но может быть чрезвычайно одарен и продвинут в других областях, в той же математике, например.

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

суббота, 13 августа 2022 г.

[prog.wow] Это высказывание достойно быть отлитым в граните

Нашел в ленте LinkedIn замечательную мудрость-афоризм, которая в моем вольном переводе звучит так:

Программисты недооценивают все на свете, за исключением своих собственных возможностей.

цынк

четверг, 11 августа 2022 г.

[prog.c++] Внезапное продолжение вчерашней темы и неожиданное для меня поведение компиляторов GCC и clang

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

Но вот поведение компиляторов GCC и clang при его использовании меня удивило. С VC++ не проверял, не знаю как бы он себя повел бы.

Под катом большой кусок кода и короткий рассказ о том, как же вели себя компиляторы.

среда, 10 августа 2022 г.

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

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

templatetypename 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. Тема получила неожиданное продолжение.