пятница, 2 июня 2017 г.

[prog.thoughts] Пара докладов про управление зависимостями в C++ и небольшое послесловие к ним

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

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

Мне же, однако, подходы на базе централизованых хранилищ пакетов, будь то conan.io (в ближайшем будущем conan-central), hunter или cppan.org не очень нравятся. Точнее говоря, я не верю, что это окажется достаточно жизнеспособным из-за разных причин. Во-первых, в C++ все очень разобщено, поэтому слабо верится в то, что народ массово начнет концентироваться вокруг какого-то одного центрального репозитория C++ных проектов. Во-вторых, кто и с какой радости должен будет оплачивать сей банкет? Хостинг 100500 непонятных проектов и кучи версий для них -- это накладные расходы, которые кто-то должен оплачивать. Что-то в мире C++ мне не видится организации, которая взяла бы на себя бремя этих накладных расходов. Тем более, что почти что все уже живет на ресурсах типа GitHub, BitBucket или SourceForge.

Кроме того, те же Conan и Hunter работают по принципу организации центрального хранилища загруженных пакетов на машине разработчика. Т.е., если разработчик однажды скачал себе Boost-1.64 для проекта A, а затем захотел использовать Boost-1.64 для проекта B, то пакетный менеджер будет переиспользовать уже загруженный ранее Boost.

Как по мне, то этот подход хорош для быстрой разработки какой-нибудь мелкой программулины. Ну, например, прочитал я на Хабре какую-то статью и захотелось мне проверить один из ее тезисов. Или задали на LOR-е вопрос, для поиска ответа на который нужно написать программку на 50 строк. В этих случаях хочется приложить минимум усилий: где-то просто перечислить список нужных мне внешних зависимостей (например, таких, как Boost, ICU, zlib) и потратить минимум времени на подгрузку и сборку этих зависимостей. Поскольку, если я пишу программу на 50 строк "на выброс", то мне вряд ли захочется ждать, пока Boost еще раз скачается и скомпилируется. Поэтому переиспользование того, что было загружено ранее, в таких условиях -- это вполне себе разумный подход.

С другой стороны, когда я делаю какой-то внутренний проект (или же работаю с какой-то приватной веткой), то у меня могут возникать ситуации, когда мне нужно взять не просто библиотеку X, а конкретный ее слепок. Скажем, библиотека X разрабатывается моим коллегой и он добавил в X новый нужный мне функционал, но еще не зафиксировал ее стабильную версию. Поэтому я на свой страх и риск хочу взять X от ревизии (коммита) R1. С большой долей вероятности я могу наткнуться в X@R1 на какую-то проблему. Из-за чего мне потребуется перейти на X от ревизии R2 (может быть даже эту ревизию я создам сам для того, чтобы исправить проблему, а потом вернуть правки в основную ветку разработки X).

В этих случаях, как мне кажется, плохо работают обе составляющие централизованного подхода (положенного в основу canon/hunter/cppan):

  1. Центральное хранилище опубликованных пакетов. Поскольку для работы с X@R1 кто-то должен быть создать соответствующий пакет и опубликовать его в этом хранилище. Потом это же нужно будет проделать с X@R2 и т.д. При том, что вряд ли хорошо засирать центральное хранилище промежуточными пакетами. Как и делать собственное зекало этого центрального хранилища для того, чтобы засирать его локально.
  2. Централизованное хранилище загруженных на локальную машину пакетов. Поскольку если X@R1 и X@R2 мне нужны только для проекта Y, да и то в какой-то временной ветке Y, то не есть хорошо сохранять X@R1 и X@R2 там же, где хранятся нормальные стабильные версии чего-то вроде Boost-а или ICU.

Имхо, для таких случаев хорошо работает подход, который мы используем в своем MxxRu::externals:

  • во-первых, MxxRu::externals сам забирает исходники стороннего компонента оттуда, где эти исходники лежат. Например, лежит Boost в tar.bz2 на SourceForge -- оттуда его и заберем. А исходники spdlog от конкретного коммита есть в git-е на GitHub-е -- ну значит вытянем их через git с GitHub-а. Таким образом для того, чтобы сделать свой пакет доступным для пользователей, не нужно предпринимать каких-то серьезных усилий. Можно даже свой тарбол не делать, если кроме GitHub-а ни на что мозгов не хватает, то достаточно просто теги в своем репозитории создавать, GitHub сам для них тарбол доступным для загрузки сделает. Ну а если нужно забирать какие-то промежуточные версии собственных компонентов из закрытых репозиториев внутри своей организации, то тут вообще никаких проблем нет, ничего дополнительно поднимать не нужно (речь про локальный инстанс того же Conan-а);
  • во-вторых, загруженные зависимости кладутся только в локальный рабочий каталог. Поэтому, если моему проекту Y потребовался сперва X@R1, а затем X@R2, то исходники X@R1 и X@R2 никуда за пределы рабочего каталога Y не уйдут. И, соответственно, когда я удалю этот рабочий каталог, то автоматически исчезнет и весь "мусор" , который был с этим связан.

Однако, поскольку мир сходит с ума и куча народа с удовольствием жрут тот же самый CMake, то есть серьезные подозрения, что CMake в качестве системы сборки и пакетные менеджеры на его основе (вроде Conan-а и Hunter-а) таки станут де-факто стандартом в мире C++. Ну что тут поделать, количество разума -- величина постоянная, а население-то растет.

ЗЫ. Отдельно хочется помянуть незлым тихим словом красноглазых Linux-оидов, которые всерьез считают, что для управления C++зависимостями нужно пользоваться штатным пакетным менеджером вашего любимого дистрибутива Linux-а. Этих сторойными рядами прямо направляю в жопу. Ибо ваше мнение не интересно. Ну вот от слова совсем. По крайней мере пока не поймете, что "кроссплатформенность" -- это "переносимость между разными платформами", а не "переносимость между разными дистрибутивами Linux-а".

четверг, 1 июня 2017 г.

[prog] Очередная статья про SObjectizer для Хабра: будет ли интересен разбор примера machine_control?

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

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

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

В общем, если кому-то интересна такая статья, то дайте об этом знать: либо в комментариях, либо через +1 в G+, либо через лайки в FB и LinkedIn (где я размещу ссылки на этот пост).

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

среда, 31 мая 2017 г.

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

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

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

Пираты Карибского моря: Мертвецы не рассказывают сказки (Pirates of the Caribbean: Dead Men Tell No Tales, 2017). Прекрасный образец того, как нужно делать развлекательный киноаттракцион: выключаешь мозги, откидываешься в кресле и понеслась! Ну и да, все деньги на экране, и это видно.

Перестрелка (Free Fire, 2016). Фильм специфический, наверняка понравится не всем. Но я получил большое удовольствие от просмотра.

Берлинский синдром (Berlin Syndrome, 2017). Ну очень неторопливо. Иногда хочется включить его на 1.25 или 1.5 скорости. Однако, именно неторопливость помноженная на предельную обыденность и составляет в итоге уникальную, тягостную, но сильную атмосферу этой картины.

Три для до весны (2017). Понравилось, как снято. Для российского кинематографа более чем достойно. Хотя в сюжетной линии с главным злодеем НКВД-шником авторы перестарались.

Без тормозов (À fond, 2016). Незамысловато, местами туповато, но смешно и весело.

Столик №19 (Table 19, 2017). Хорошая смесь специфического юмора, из-за которого нужно внимательно ловить каждую реплику, и сентиментальной драмы. Сдобренной отличной актерской игрой и работой оператора.

Похищение (Kidnap, 2017). Добротно. Хороший напряженный триллер.

Ирис (Iris, 2016). В целом неплохо. Но правда не понял, за счет чего: сюжета или присутствия красивой актрисы в главной роли ;)

Семейное ограбление (Mes trésors, 2017). Нормальная французская комедия. Не шедевр, но и потраченного времени не жалко.

Комик (The Comedian, 2016). Фильм можно смотреть, если нет неприятия стендапа вообще и жесткого пошлого юмора в частности.

Время псов (The Hunter's Prayer, 2017). Странная картина. Вроде бы актеров подобрали. Вроде как динамику создали. Вроде как и постреляли вдоволь. А вот не торкает особо.

Мелкие преступления (Small Crimes, 2017). Ждал большего. Фильм оставил впечатление какого-то сумбура, в котором события активно переплетаются, но непонятно почему и из-за чего. Хотя нужно начислить дополнительные очки за отсутствие хэппи-энда.

Пробуждение Зодиака (Awakening the Zodiac, 2017). Довольно посредственно. Хотя посмотреть можно, только не нужно ждать ничего, хотя бы отдаленно напоминающего замечательный "Зодиак" Дэвида Финчера от 2007-го года.

Лжец, Великий и Ужасный (The Wizard of Lies, 2017). Пример того, как авторы взяли потенциально очень крутую тему, но не смогли донести до зрителя ощущение того, что главный герой фильма повинен в создании самой большой финансовой пирамиде в истории.

Кухня. Последняя битва (2017). Средней руки российская комедия. Местами смешная. С отличной картинкой. Белорусской аудитории отдельно сильно понравится маленький проезд по "Коленьке".


Ну а эти две картины находятся просто вне всякой критики, т.к. днище было пробито с огромной силой и на невероятную глубину.

Чужой: Завет (Alien: Covenant, 2017). Это так плохо и маразматично, что я даже не могу увязать этот фильм с первыми тремя "Чужими". Ну вот есть уникальная вселенная "Чужих", показанная в первых трех фильмах. Ее даже не смогли испортить странной четвертой частью. А "Прометей" и "Чужой: Завет", особенно "Чужой: Завет", ну никак у меня не увязываются со знаменитой серией. Это какое-то совсем другое кино, совсем про других монстров и совсем про других людей. Можно было бы о "Чужом: Завет" порассуждать именно как о совершенно другой истории. Но происходящее на экране настолько тупо и неинтересно, что нет смысла это делать.

Форсаж 8 (The Fate of the Furious, 2017). Это какой-то красочный киноаттракцион, но непонятно для какой аудитории. Может быть для 10-летних детей. Как это можно всерьез смотреть взрослым людям просто не представляю.

вторник, 30 мая 2017 г.

[flame] Образ современного ИТ-шника в РБ: "это молодой человек, владеющий иностранным языком, ..."

Цитата из официоза про встречу руководства моей альма-матер с представителями ИТ-шных компаний города:

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

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

Пожалуй, это все, что нужно знать про развитие ИТ в РБ.

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

  1. Отсутствие своей продуктовой разработки как класса. Т.е. единичные примеры как были, так и будут. Но именно что единичные.
  2. Уровень зарплат аутсорсеров на глобальном мировом рынке будут определяться не столько уровнем зарплат в странах, откуда идет заказ на аутсорс, сколько уровнем зарплат в развивающихся странах, которые уже пытаются урвать свою долю пирога, а так же тех, которые только собираются это сделать. Имхо, глупо ожидать, что желающие "войти-в-Ойти" на Филиппинах, во Вьетнаме или в Индонезии будут знать английский хуже, чем студенты провинциальных белорусских ВУЗов.

Итого, как мне видится дальнейшее развитие истории:

  • хорошо, если государство будет заинтересовано в экспорте жопочасов местных ИТ-шников. Ну, такая же статья экспорта, как и калийные удобрения. Только ресурсы здесь остаются и, благодаря своим деньгам, хоть как-то оживляют внутренний рынок товаров и услуг. Как-то страшно думать, во что это все превратится, если государство таки решит зарезать курочку, ибо кушать ну очень хочется, а ее и так слишком долго жалели;
  • поскольку основной вид деятельности в местном ИТ -- это аутсорс, то желающим "войти-в-Ойти" и чувствовать себя там нормально, прежде всего нужно делать упор на изучение иностранных языков (лучше нескольких). А так же на развитие soft skills и грамотной продажи самого себя. Умение программировать из года в год будет становиться все менее и менее важным профилирующим навыком. В том числе и потому, что само массовое программирование все больше и больше требует умения быстро склеить что-то из уже готовых компонентов, нежели знаний и способностей создать что-то новое и нетривиальное. Кроме того, в аутсорс же отдается не только программирование, но и куча сопутствующих активностей: бизнес-аналитика, тестирование, управление проектами, техническая документация, как минимум. Тут умение программировать вообще не обязательно;
  • уровень привлекательности ИТ-отрасти в плане доходов будет определяться коньюктурой мирового рынка. Не хочу сказать, что ЗП в отрасли упадут вот прямо завтра или послезавтра. Но то, что когда-нибудь это произойдет, поскольку ту же самую работу вполне себе хорошо будут делать юноши и девушки из Вьетнама или Венесуэлы, но стоить это будет в 10 раз дешевле, и тогда никакие способности, установившиеся связи и имеющийся опыт не сделают белорусских ИТ-шников настолько ценными, чтобы платить нам в 10 раз больше. На глобальном-то рынке. Так что современным молодым людям, владеющим иностранными языками, и зарабатывающим по паре-тройки тысяч долларов в месяц, полезно помнить, что этот уровень зарплат обеспечивается не какими-то их уникальными особенностями. А вот такой нынешней ситуацией на рынке.

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