[prog;work;wow] Марко Арена завершил свою серию статей про SObjectizer

Марко Арена сегодня завершил свою серию статей "SObjectizer Tales", начатую в октябре прошлого года. Полный список статей из этой серии я приведу ниже.

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

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

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

Как по мне, так Марко написал целую книгу. Что по объему, что по глубине и качеству материала.

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

Более того, я бы даже назвал выход серии "SObjectizer Tales" целой вехой в истории развития SObjectizer-а. Важной и значимой лично для меня.

Так что, да, я шокирован. В хорошем смысле этого слова.

---

Вот как в итоге выглядит вся серия.

• Prelude (зеркало на dev.to).
• 1. Producing Images (зеркало на dev.to).
• 2. Can you call me back? (зеркало на dev.to).
• 3. Acquisition loop revisited (зеркало на dev.to).
• 4. Handling commands (зеркало на dev.to).
• 5. Sending commands (зеркало на dev.to).
• 6. Is the stream still in progress? (зеркало на dev.to).
• 7. Agent composition (зеркало на dev.to).
• 8. Representing errors (зеркало на dev.to).
• 9. Splitting work (зеркало на dev.to).
• 10. Handling GUI from main (зеркало на dev.to).
• 11. Interlude: testing (зеркало на dev.to).
• 12. Receiving commands from the network (зеркало на dev.to).
• 13. Routing images across the network (зеркало на dev.to).
• 14. Triggering agent shutdown (зеркало на dev.to).
• 15. Monitoring disconnections (зеркало на dev.to).
• 16. Interrupting work (зеркало на dev.to).
• 17. Limiting message flow (зеркало на dev.to).
• 18. Limiting message chains (зеркало на dev.to).
• 19. Thread-safe handlers (зеркало на dev.to).
• 20. Performance, part 1 (зеркало на dev.to).
• 21. Performance, part 2 (зеркало на dev.to).
• 22. Performance, part 3 (зеркало на dev.to).
• 23. Mutable messages (зеркало на dev.to).
• 24. Delivering messages at shutdown (зеркало на dev.to).
• 25. Runtime telemetry (зеркало на dev.to).
• 26. Dispatcher selection (зеркало на dev.to).
• 27. Design ideas (зеркало на dev.to).
• 28. If I had a magic wand… (зеркало на dev.to).
• Epilogue (зеркало на dev.to).

---

PS. Что доставляет отдельно, так это слоган, который Марко выбрал для своей серии: Concurrent C++, made simple. Таки да, для этого все когда-то и затевалось. Но я бы насколько лаконично и емко выразить бы не смог.

[prog.c++.wtf] Публичный член приватного вложенного типа?

Еще одно открытие для меня в языке C++, которым пользуюсь уже больше 30 лет:

class Outer {     struct Inner {         int m_a{};         int m_b{};     }; public:     Inner m_i; }; int main() {     Outer o;     o.m_i.m_a = 3;     o.m_i.m_b = 4; }

Оказывается, так можно. Цынк.

Что меня выморозило в этом примере: мы же класс Inner сделали закрытым вложенным классом для Outer. Т.е. вроде как, по логике вещей, классом Inner могут пользоваться только сам Outer и его друзья.

Но ничего нам не запрещает объявить в Outer публичный член Outer::m_i приватного, вроде бы, типа Outer::Inner. И любой желающий может работать с таким объектом приватного типа Outer::Inner.

Впервые с таким столкнулся. Я, честно говоря, ожидал, что компилятор не должен позволить объявить публичный Outer::m_i. Но, в очередной раз, ошибся 🥴

---

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

[prog.c++] Оказывается, в современном C++ нельзя взять и сложить std::string с std::string_view...

На пятый год работы с C++17, в котором std::string_view появился, "Зоркий глаз" (т.е. я) заметил, что в C++ пока нет версии operator+ для случая std::string и std::string_view :(

Поэтому ни в C++17, ни в C++20, ни, подозреваю, в C++23, не получится написать так:

std::string f(std::string_view a, std::string_view b) {
  using namespace std::string_view_literals;
  return std::string{"Expected value: "} + a + ", actual value: "sv + b;
}

Но есть пропозал. И, может быть, нам повезет и в C++26 эта фича в языке таки появится. А может только в C++29...

Если честно, то я, мягко говоря, в шоке.

---

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

[prog.c++] Оказывается, std::enable_shared_from_this можно применять и с неполным типом

Увидел неожиданное для себя в статье "On detecting improper use of std::enable_shared_from_this":

#include <memory>

struct D;

struct B : std::enable_shared_from_this<D>
{
};

struct D : B
{
};

int main() {
    auto p = std::make_shared<D>();
    auto q = p->shared_from_this();
}

И это спокойно компилируется.

Другими словами, std::enable_shared_from_this можно использовать и для типов, которые не были еще полностью определены.

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

[prog.c++.kill-them-all] Во что обходится это дерьмо, CMake?

Сегодня наткнулся на блог пост "The road to hell is paved with good intentions and C++ modules", создателя Meason-а. А в этом блог посте ссылку на вот эту презентацию: "A new CMake Scripting Language?". Из которой можно узнать интересные цифры. Например, перевод некого проекта Trilinos с GNU Autotools на CMake обошелся Sandia National Laboratories (SNL) более чем в миллион долларов -- около $500K составила стоимость рабочего времени сотрудников SNL и еще около $700K было потрачено на контракты с Kitware по доработкам CMake/CTest/CDash.

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

Но вот после знакомства с вышеупомянутой презентацией я вообще в шоке.

Это как же у Kitware получилось сперва выкатить откровенное дерьмо в мир, затем убедить кучу народа это жрать не просто причмокивая, а еще и доплачивая Kitware?

Снимаю шляпу.

Пару лет назад я был готов добавить в RESTinio поддержку HTTP-клиента за $3.5K (что на тот момент не превышало одной месячной ЗП C++ разработчика моего уровня, причем просто чистой ЗП, без налогов на ФОТ и прочих издержек). А тут создатели CMake не стесняются озвучивать сумму в миллион долларов для того, чтобы сделать улучшенный CMake.

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

---

Отдельно мне доставила фраза со слайда #11 в упомянутой презентации:

The book “Professional CMake” largely solves the CMake Documentation problem.

Вот нет! Эта книга, возможно, как-то решает вопрос получения денег с пользователей CMake. Но не решает проблему качества CMake-овской документации.

---

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

---

Говорил раньше и повторю еще раз: если собрать список причин по которым стоило бы распрощаться с C++, то CMake там был бы на одном из первых мест.

И не потому, что CMake плохой. Плохого софта не так уж и мало.

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

[prog.c++] Пример того, как NRVO(RVO) оптимизация может к вам в код UB подсадить

В процессе одного из споров на RSDN-е родился пример того, как компилятор, применив NRVO, приводит к неожиданному поведению.

Под катом полный код примера. Пока же пару слов о том, на что смотреть.

Есть простой класс entity, который содержит внутри себя целочисленное значение. Изменить это целочисленное значение можно только вызывав метод entity::update. Но это не const-метод, т.е. для константного entity его вызывать нельзя.

Фокус с entity в том, что есть еще и entity_registry, т.е. реестр объектов entity. Если в конструктор entity передать ссылку на entity_registry, то entity себя в реестре зарегистрирует. А в деструкторе -- вычеркнет.

Пока объект находится в реестре, его можно изменить через реестр: вызываем метод entity_registry::update и реестр вызывает update для всех зарегистрированных в нем объектов.

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

void check() {    entity_registry registry;    entity e1{registry};    entity e2; // Не в реестре.    entity e3{e1}; // Не в реестре.    registry.update(25);    std::cout << e1.value() << ", " << e2.value() << ", " << e3.value() << std::endl; }

Мы получим вполне ожидаемое:

add to registry: 0x7ffd7b567c18
25, 0, 0
removed from registry: 0x7ffd7b567c18

Т.е. объект e1 добавил себя в реестр, потом мы получили три предсказуемых значения (два нулевых, т.к. никто не менял e2 и e3), затем e1 изъял себя из реестра.

А теперь внимание, вопрос: что будет во в таком случае?

entity make_entity(entity_registry & registry) {    entity ent{registry};    ent.update(42);    return ent; } void demo() {    entity_registry registry;    const entity ent = make_entity(registry);    registry.update(100);    std::cout << ent.value() << std::endl; }

Можем ли мы изменть значение константного ent внутри функции demo через вызов update у реестра?

[prog.c++.wtf] Голый владеющий указатель на shared_ptr?

Чего только в жизни не бывает! Похоже, что я оказываюсь в ситуации, когда потребуется поиметь голый владеющий указатель на std::shared_ptr. Что-то вроде (псевдокод для иллюстрации, не претендует на production readyness):

void ready_handler(const mg_connection * conn, void *) {
   auto shared_conn_data = std::make_shared<connection_data_t>(...);
   auto * owning_ptr = new std::shared_ptr<connection_data_t>{shared_conn_data};

   mg_set_user_connection_data(conn, owning_ptr); // Только за этим onwing_ptr и нужен был.
                                                  // Нельзя таким образом сохранить весь shared_ptr.

   send_to_external_thread(shared_conn_data);
}
...
void close_handler(const mg_connection * conn, void *) {
   auto * owning_ptr = reinterpret_cast<std::shared_ptr<connection_data_t>>(
         mg_get_user_connection_data(conn));
   // Этот экземпляр больше не нужен.
   // Если где-то на внешней нити остался свой shared_ptr, то connection_data_t продолжит
   // свое существование и после выхода из close_handler.
   // Если нет, то connection_data_t умрет прямо сейчас.
   delete owning_ptr;
}

Интеграция с написанным на чистом Си коде. Ничего лучшего пока не придумывается :)

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

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

цинк

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

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

[prog.c++;blog;wow] Интересно, это уже успех или ещё нет? :)))

Посмотрел сегодя откуда ко мне в блог люди приходят. А тут такое:

Не меньне, не больше, а "быстрый ответ" в выдаче Яндекса по запросу "виртуальный деструктор C++ зачем нужен". Однако! :)

Если (а скорее когда) придется проходить собеседование по C++, то на вопрос о виртуальном деструкторе в C++ нужно будет показать этот скриншот.

[prog.wow] Век живи, век учись: с указателем после освобождения ничего нельзя делать

Иногда флеймы на профильных ресурсах оказываются очень полезны. Вот свежий пример с LOR-а: "Навеяно свежей дырой в Xorg".

В двух словах: после освобождения указателя (через free в C или delete в C++) с указателем ничего нельзя делать (кроме как присвоить ему новое валидное значение).

Т.е. не то, что разыменовывать нельзя (это-то как раз понятно), но и вообще ничего нельзя: ни распечатать, ни сравнить с чем-нибудь (пусть даже и с NULL/nullptr), ни преобразовать в uintptr_t. НИЧЕГО. Любые попытки сделать что-то подобное есть UB.

Говорят, что у этого есть даже какое-то логическое обоснование. Но мне осознать сие не получается :)

Вышесказанное означает, что если у вас написано что-то подобное:

void data_cleanup(data * ptr) {   if(ptr != NULL) {     ... // Какие-то действия по очистке.     free(ptr);   }   else {     ... // Какие-то другие действия. Допустим, просто         // печать в лог о том, что data_cleanup был вызван.   }   ... // Еще какие-то действия, которые не зависят от       // значения ptr.   // А здесь нужно еще что-то сделать если ptr не был NULL.   if(ptr != NULL) { // (1)     ...    } }

то поздравляю, у вас в коде UB. И, судя по тому, как безжалостно компиляторостроители начинают UB эксплуатировать, рано или поздно случится какая-нибудь бяка.

Полагаю, что выйти из ситуации можно вот так:

void data_cleanup(data * ptr) {   int not_null = ptr != NULL;   if(not_null) {     ... // Какие-то действия по очистке.     free(ptr);   }   else {     ... // Какие-то другие действия. Допустим, просто         // печать в лог о том, что data_cleanup был вызван.   }   ... // Еще какие-то действия, которые не зависят от       // значения ptr.   // А здесь нужно еще что-то сделать если ptr не был NULL.   if(not_null) {     ...    } }

Но это же нужно быть очень внимательным, чтобы не наступать на подобные грабли.

К счастью, в C++ при использовании умных указателей вроде shared_ptr и unique_ptr все не так страшно. Но вот если нужно записать что-то на чистой ламповой Сишечке или на старых плюсах, в которых умных указателей нет... То грустно.

---

Данное обсуждение заставило вспомнить еще про одну засаду с голыми указателями. Еще, если кто-то не знал или забыл, в Си и C++ нельзя просто так сравнивать на больше/меньше указатели одного типа. Грубо говоря, если у нас есть указатели a и b одного типа, то выражение (a<b) будет определено, только если a и b указывают на элементы одного массива (либо на элемент за последним элементом этого массива).

Правда, в C++, насколько я понимаю, можно воспользоваться std::less или std::greater из стандартной библиотеки. Поскольку для подобных компараторов определены специализации для указателей. Например, по поводу std::less на cppreference сказано буквально следующее: "A specialization of std::less for any pointer type yields the implementation-defined strict total order, even if the built-in < operator does not."

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

[prog.wow] Это настолько прекрасно про "маргинальщину", что невозможно не утащить в анналы :)

Найдено на RSDN. Такой сгусток боли невозможно не утащить в склерозник, ибо вряд ли когда-нибудь еще встретится столь мощно сформулированное:

IMHO, упоминание маргинальщины (D, Haskel, Erlang, SVN, FreeBSD) — это диагноз. Разумные люди от нее избавляются и переходят на более популярные инструменты, потому что так удобнее. С маргинальщиной живут только полные фанатики. И параноики, которым постоянно кажется, что D — центр вселенной и оттуда кто-то что-то тырит. Работают такие фанатики исключительно в одиночку. Ни один разумный человек с маргинальщиной работать не будет, даже при зарплате в разы выше рынка.

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

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

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

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

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

[prog.c++] Встретил проект на C++98 в котором непонятно чем могут помочь более свежие стандарты C++

Заглянул сегодня в один C++ный проект, в который есть шанс вляпаться или поучаствовать (пока не знаю, положительную или отрицательную конотацию применять). Проект на C++98. Ага, в 2022-ом году.

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

Разве что enum class вместо обычных enum-ов. А то в применяющихся enum-ах настолько корявые префиксы для избежания совпадения имен, что просто атас.

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

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

Вот, пожалуй, и все. Даже удивительно.

Проект написан на, по сути, "Си с классами". Хотя исключения применяются. Местами даже простенькие шаблоны.

Давненько ни с чем подобным не сталкивался.

PS. На закуску одна строчка из этого проекта. Просто для развлечения ;)

COperator *pop = (*((*((*pexpr)[1]))[0]))[0]->Pop();

[business.wow] Поиск клиентов через секс?

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

На моменте рассказа о том, как искать клиентов звучит следующее:

"... Как я еще нахожу? Это через сферу досуга, наслаждения. Для меня это искусство, это секс, путешествия..."

Секс?

Для поиска клиентов?

Чего-то я явно не знаю о бизнесе :(

---

Комментариев под видео с лекцией нет, поэтому даже не знаю, заметил ли вообще это слово в лекции кто-то кроме меня :)

[work] Не, я так себя продать бы не смог

Сегодняшнее из LinkedIn-овской ленты:

Я бы так сам про себя не смог.

Тем более, что своего YouTube-канала у меня-то и нет :(

Да и 100% покрытие юнит-тестами не считаю ни достоинством, ни самоцелью.

В общем, продажник из меня еще тот. OpenSource проекты продать не смог. Вряд ли и самого себя продам. Тем более в такой красочной обертке ;)

Хотя в связи с проблемами прохождения платежей из EU в BY вопрос продажи собственных могзов в РБ/РФ становится все более актуальным. Но, если все продолжит идти по плохому сценарию, то будет отдельный рекламный пост (проплаченный мной, естественно).

[kubuntu] Мне кажется или в Kubuntu таки 20.04 заметно улучшился рендеринг шрифтов?

Только что обновил свой основной рабочий ноубук с Kubuntu 18.04 до 20.04. И мне показалось, что в 20.04 рендеринг шрифтов заметно улучшился. Текст на экране (14", FullHD) стал выглядеть более четким.

Это только мне так кажется или кто-то из читателей блога пересаживался на Ubuntu/Kubuntu 20.04 и наблюдал такой же эффект?

Заодно еще такой вопрос: если мне не изменяет склероз, то в этом апреле должна выйти следующая LTS для Ubuntu/Kubuntu, 22.04. Насколько разумно обновляться с 20.04 на 22.04 в течении месяца-двух после выхода 22.04? Может имеет смысл подождать полгодика-год?

А то я тут, похоже, на 18.04 слишком долго просидел, надо было, наверное, на 20.04 переходить пораньше. Но мешали старые воспоминания о Linux-ах, в которых было стремно обновляться до свежих релизов из-за сырости оных.

[wow] Wargaming сворачивает бизнесы в РФ и РБ, закрывает свою студию в Минске

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

Новость на русском на сайте sputnik: тыц.

Подозреваю, что рынок труда в РБ начнет тясти (если уже не, просто я тут закуклился в своей провинции, не имею представления как оно там, у центре-то).

Отдельно доставляет количество лайков на этой новости в LinkedIn (скриншот как раз оттуда). Доставляет, но не удивляет.

[wow] Хочешь попасть в Лабораторию Касперского? Изучай SObjectizer! :)

Сам офигел когда увидел:

Цинк (не знаю, как долго будет актуальным).

[work] Наткнулся тут на невероятное...

В поисках информации о "спиральной динамике" нашел такого автора на vc.ru: Максим Цепков. А среди его статей ознакомился вот с этой: "Реальность цифрового мира: проекты делает некомпетентная команда". И вот в этой статье практически сходу споткнулся о пару-тройку моментов, которые заставили всерьез задуматься о том, а не сказочный ли пишет все эти буквы? Уж простите мне мой французский, но запись в блог сразу после прочтения, еще под свежими впечатлениями.

Итак, цитата:

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

Оказывается, для этого уже давно есть методы. Первые из них появились, естественно, в IT как раз тогда, когда было осознанно, что регламенты и правила не работают, а ключевым фактором успеха является человеческий фактор. Об этом есть классическая книга Тома ДеМарко «Peopleware» (1987), которая в русском переводе так и называется «Человеческий фактор».

И как ответ на эту ситуацию появился Agile. Он взлетел именно поэтому, что появился во время прихода персоналок. Персоналки ведь пришли не домой, они сделали компьютеры доступными для мелких и средних компаний. И потребовалось массово автоматизировать бизнес, возник дефицит разработчиков. Их не было, выпуск институтов не увеличился. И именно Scrum и Agile обеспечили решение этой проблемы, позволив успешно делать проекты некомпетентной командой. Это был один из ключевых факторов их успеха и широкого распространения. В России, кстати, мы это не очень ощутили, потому что именно тогда, в период появления персоналок, развалилась оборонка и много квалифицированных инженеров ушли в айтишники, они демпфировали этот кризис.

Что меня здесь смущает?

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

Далее, период развития интереса к Agile, начиная с появления Agile Manifesto -- это уже нулевые годы. Когда у персоналок был не то, чтобы приход. Они уже давно пришли. А приход тогда как раз был у Web-а. И именно в конце 1990-х и начале нулевых стартовал и нарастал массовый переход от десктопа к Web-у. В условиях когда не было ни толком развитых Web-технологий, ни опытных Web-разработчиков, зато спрос на Web-разработку был сумасшедший. Так если уж благодаря чему-то Agile и взлетел, так это благодаря Web-разработке.

Второе. Что-то мне трудно припомнить, чтобы в 1990-е в России после распада оборонки квалифицированные инженеры массово уходили в айтишники. При том, что как раз в оборонке до 1990-х огромное количество разработчиков и трудилось. А потом осталось без куска хлеба. В прямом смысле. И поэтому уже существующие профессиональные кадры разбегались и выживали кто как может: кто-то уехал, кто-то переквалифицировался на бух- и складской учет (dBase/FoxBase/Clarion, а затем и 1C с Галактикой и Ко), кто-то ушел в преподавание, кто-то смог уйти в сисадмины (в банках в то время был большой спрос), кто-то тупо торговал широпотребом на рынке.

Так что как-то с моими воспоминаниями ну никак не бьется. Но я и не из России. Поэтому опять же, вопрос к более знающим людям: действительно ли в 1990-х квалифицированные инженеры из оборонки в РФ уходили в айтишники?

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

[life] Осенью в Гомеле зацвел каштан

Нынешний 2020 год продолжает удивлять и подкидывать вещи, которые раньше видеть не доводилось.

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

Просто афигеть.

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

А тут второе цветение дерева, с которого еще не осыпались созревшие каштаны.

Просто афигеть.

PS. Еще на местном рынке бабульки продают свежую малину и даже клубнику. Вот только-только с огородов. В октябре, блин.

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