Комментарии 225
Более того, это плоское конфигурационное пространство – когда есть переменные, их надо называть большими буквами с подчеркиванием, и среди них нет иерархии; сложно понять, что происходит.

Не выглядит проблемой.
Решение #1. Указывать иерархию в названии переменных (KAFKA__SUPER__VARIABLE). Любая иерархия в каком-то смысле виртуальна, все равно под капотом k/v
Решение #2. Засунуть все в консул. Там уже по-настоящему — и acl, и иерархия. А имя окружения все равно передаём через переменные окружения. Таким образом у нас переменных становится 1, остальное в хранилище конфигурации.


особенно, если вы возьмете postgres-кластера на базе Patroni или Stallone.

Stolon?


Она полностью декларативна; все, что можно предусмотреть, авторы Helm Charts обычно предусматривают.

Если не заглядывать под капот ) там начинается ад с хуками, темплейтингом, функциями. А основная претензия к Хельм — ни один чарт без доработки не работает ( речь не про «подкинуть нужные values.yaml») Индустрия явно свернула куда-то не туда — генерирую тонны контента, который неприменим на практике. Но оно и понятно. То что работает — продаётся за деньги. Это становится «ноу-хау» консалтеров как из якобы бесплатного и доступного собрать рабочее решение


Операторы сейчас есть буквально для всего. Я

Только вот проблема. Как к любоум системному ПО — к операторам предъявляются ОЧЕНЬ ВЫСОКИЕ требования по качеству кода. Вряд ли условный пользователь будет счастлив потере данных в БД, вправляемой оператором, из-за того, что разработчики не рассмотрели все возможные граничные случаи. И я гарантирую, что нормальных операторов для production использование из всей массы — единицы. Даже не десятки.


Что такое SRA?

SRE? galimova_ruvds большая просьба — давать выверять текст изначальному докладчику (я так понял — это расшифровка доклада)

Решение #1. Указывать иерархию в названии переменных (KAFKA__SUPER__VARIABLE). Любая иерархия в каком-то смысле виртуальна, все равно под капотом k/v

Это решение основано на соглашении между людьми, и его исполнение сложно проверять.
Решение #2. Засунуть все в консул. Там уже по-настоящему — и acl, и иерархия. А имя окружения все равно передаём через переменные окружения. Таким образом у нас переменных становится 1, остальное в хранилище конфигурации.

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


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

И возникнет старая как мир проблема — как в тоннах говна найти алмаз. Ответом будет альтернативная платформа в которой сразу все есть.

Давайте пилить такую платформу поверх кубера (как стандарте де-факто для PaaS)
ОпенШифт точно идет не в ту сторону, потому что после покупки РедХата IBM'ом он мутирует в кусочек облака IBM Cloud со всеми вытекающими

Поверх k8s будет не интересно для бизнеса, который это будет спонсировать. Не удивлюсь если это будет MS через пару лет.

Что такое SRA?

О, боги! Я себе мозг ненадолго сломал на этом месте про каких-то новых и загадочных "SRA" .

Отличная статья. Она вкрывает очень много реальных насущных проблем. И не боится пойти против течения.


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


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


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

Большое количество переменных — это хорошо. А даже если плохо — то неизбежно. Сколько осталось ГНУ утилит у которых меньше 40 параметров? Изначально они должны были быть супер простыми.


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


Когда мы использует переменные окружения (.env) мы строим непрозрачные стены для ИДЕ. Она уже не знает что и как происходит этой переменной.


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


Потому что это не код, а чертов текст. В коде все эти проблемы уже решены.

Сейчас могли бы прибежать ребята и растолковать, что IDE — это для слабых духом, vi(m)/emacs и больше ничего не нужно, дебаг — это удел джуниоров, профессионалы пишут с первого раза и им всё-равно, они разобрались, не сложнее GNU Make, на самом деле же.

Но его забыли похоронить и поэтому на нём проросли разные automake, autoconf и прочие генераторы генераторов компоновщиков скриптов компоновки генераторов мейкфайла? :-)


ЗЫ. Пытался так разобраться, чтоб вкрутить поддержку нового формата в mpd, в итоге забил, захардкодил и оставил чисто форк для себя, кому приспичит — сами поправят...

Какие альтернативы?
Cmake? Qmake? Bazel? Другие системы сборки?


К мейкфайлам у меня всего две претензии :


  1. Дебильные табуляции, которые нужно очень аккуратно расставлять
  2. Необходимость создания фейковых флаг-файлов, если нужно собирать объекты вне фс. Те же докер образы

Это когда ты внутри мейкфайла при сборке докер образа делаешь что-то типа touch image.flag и далее по этому флаг-файлу мейк понимает, что образ уже собран и, например, пересобирать его не надо

Cmake, насколько я знаю, поверх GNU make работает (может работать, во всяком случае).
Если проводить параллель, то Cmake — альтернатива autoconf, а GNU make с ним можно заменить на Ninja.
Qmake и Bazel не щупал

Да его уже фиг похоронишь, несмотря на все его "достоинства", да и auto tools поверх него тот ещё зомби.
Так и живём теперь на костях былых проектов, с докером, видимо, та же история.

IDE — это для слабых духом,

отличная тема для еще одной отдельной статьи.


Я имел в виду не обязательно именно ИДЕ. А код, отвечающий за постоение AST. Такой код используется и в компиляторе и сборщике и статическом анализе. Да наверное, должен использоваться во всем.


Люди, которые говорят, что код можно (рационально) писать в блокноте — не разработчики. АСТ должен быть построен и валидирован. Если разработчик вместо валидации на лету (при написании кода) руками запускает консольную тулу (когда и если вспоминает) — то он теряет ценное время себя, команды и копмании, которая оплачивает банкет. Как именно происходит валидация на лету — в ИДЕ, или текстовом редакторе с подключенным language server, или еще чем — уже не важно для этого разговора.

Я регулярно встречаю разработчиков, которые пишут «в блокноте», что на статически типизированных языках, что на динамике.
И они реально крутят носом от этих ваших «language servers» и прочей валидации перед пушем. Это такой определённый склад ума и вид людей, их не переубедить ничем, они с детства в далёких 80-х/начале 90-х так привыкли и меняться не будут.
Специалисты, кстати, зачастую, очень хорошего уровня, но со своими тараканами. Адекватный менеджмент даёт подобным людям соответствующие роли и все довольны.

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


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


Точно так же, как ученые, которые разучились воспринимать критику в свой адресс — не ученые. Или которые заросли догматизмом — перестали быть учеными. Например, как лорд Кельвин.

Проблема в том, что они не отличные спецы.

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


  • Линус Торвальдс пишет код в https://github.com/torvalds/uemacs, очень простой текстовый редактор.
  • Walter Bright, создатель языка D, пишет код в https://github.com/DigitalMars/med.
  • Simon Peyton Jones, мой личный герой, пишет код в обычном Emacs. Аналогично поступают Andrei Alexandrescu, Richard Stallman, Donald Knuth, etc.

Я лично знаю очень талантливых и продуктивных разработчиков, которые пишут код в обычном Vim без LSP (для многих языков никакого LS и нету вовсе).


Я не против IDE. Я против предубеждений и громких, необоснованных высказываний.


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


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


заросли догматизмом

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


M-x projectile-compile-project

Если человек отличный спец с горой знаний и навыков (а главное – цепким вниманием и железной памятью) и способен держать в голове flow целого проекта, где какие определения лежат и куда переменные изменяются, и где какие баги могут возникать, — он сможет писать даже в блокноте, даже на динамике. Может, IDE его скорее отвлекать будет. Но к сожалению, не всем повезло такими сверхлюдьми быть v_v

ещё во времена, когда и слова IDE не было, а писали почти все на С и Паскале, я приметил, что программер способен удержать в голове код размером в 350к. Хороший программер. В среднем у человека можно сходу получать ответы по его коду, пока код не превысил 200к по объёму исходника. Дальше уже «сейчас посмотрю, уточню».

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

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


Вы считаете IDE абсолютно незаменимым инструментом для вашей продуктивности?

Не перекручивайте пожалуйста мои слова. Я сказал именно то, что сказал. Валидация АСТ дерева должна происходить на лету.


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


Моэтому перейдем на более простые темы. Знаете ли Вы, что говорил Кельвин на старости лет? Кельвин был выдающимся ученым, без скидок. Считаете ли Вы что Кельвин оставался ученым на старости лет?

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

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


Я сказал именно то, что сказал. Валидация АСТ дерева должна происходить на лету.

Почему именно должна? Я считаю, что у разных людей разные подходы к написанию кода, и это нормально.


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


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


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


Понимание уже написанного кода — это тоже другой режим работа мозга. Для этого важна быстрая навигация, и ctags/LANGUAGE-tags/codesearch вполне неплохо с этим справляются.


На некоторых языках очень сложно писать без IDE, в основном из-за того, что там доминируют порочные практики. К примеру, в Java принято разбивать проект на малюсенькие файлы, один класс — один файл. Это делает понимание структуры и навигацию настолько непосильным делом, что без специальных инструментов становится не обойтись. Ответ на вопрос "где происходит X" может занять пару часов, даже с IntelliJ IDEA.


Поэтому мне гораздо легче понимать проекты на C, чем на Java. Зачастую ответить на вопрос "где происходит X" в коде PostgreSQL или Redis или Emacs, который ты видишь первый раз, гораздо проще без всяких IDE, чем в Java-махине, над которой ты работаешь уже как 2 года.


Знаете ли Вы, что говорил Кельвин на старости лет?

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

Он не хотел серьёзно рассматривать данные, противоречащие его мировоззрению. Никого не напоминает?

что конкретно я не рассмотрел?


Мне лично докер никогда не нужен был… Почему знание докера вдруг становится критерием хорошего разработчика?

может быть для Вас — и не критерий. Для меня критерий. Моя работа связана с вебом, и следовательно облаками.


Почему именно должна?

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


Я считаю, что у разных людей разные подходы к написанию кода, и это нормально.

Где я говорю что использовать перфокарты для программирования — не нормально? Я говорю что это не эффективно.


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

Я тоже. Больше, чем многих людей. К сожалению эта проблема, которую должны были решить и забыть еще лет двадцать назад, волнует мало людей. Потому что я знаю только один проект, который с ней борется — https://github.com/xi-editor/xi-editor.


Я люблю написать...

и в чем проблема? Вы понимаете что отключить функцию всегда проще, чем агитировать за ее создание?


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

СОЛИД может не всем подходить. Но конечное качество кода должно быть не ниже, чем если он есть.


К примеру, в Java принято разбивать проект на малюсенькие файлы, один класс — один файл. Это делает понимание структуры и навигацию настолько непосильным делом

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

Мне есть что сказать о людях выше. Но хабр этого не хочет. Хабру интересны легкие разговоы, которые не задевают чуства читателей. Я получил по одному минусу в комментарии (и несколько плюсов) и минус в карму (без плюсов, если я правильно помню, сколько было голосов до этого).
Я поставил вам минус в карму. За то что вы сказали, что не считаете разработчиками людей, которые не используют IDE. И за то что затем сравнили их с «программистами на перфокартах», которые замедляют прогресс.

Я считаю такие сравнения не уместными, и что вам нужно научиться различать «я не понимаю как программировать без IDE» и «все люди, которые не используют IDE – идиоты».

1 я специально обьяснял что говорил не конкретно иде, а про конкретную фичу.
2 я остаюсь верен своему сравнению в следующей формулирове. Если человек не развивает свои инструменты — он похож на тех, кто хочет работать с перфокартами.
3 я умею программировать без иде. Я имел достаточно случаев починки серверов по ссш в карьере.
4 я не оскорблял людей, которые не хотят развивать свои инструменты. Я сказал, что они могут быть крайне уместны на своем месте. Но они уже не полноценные професионаллы. Это может быть неприятно, но это не оскорбление. И тем более не приуменьшение интеллекта.


Итого Вы увидели то, что хотели. А не то, что я написал.

они уже не полноценные професионалы

Адекватные люди профессионализм измеряют выхлопом, а не инструментами. Не думал, что мне захочется использовать заезженную до дыр максиму «вам шашечки, или ехать?» — но уместнее аллюзии тут не найти.


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


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


Давайте сравним профессионализм, раз уж вы начали этот разговор.

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


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


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

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

Это дискуссия из разряда, что считать "сильной", а что "слабой" связью. И честно говоря, я не готов начинать еще одну.


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


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


Или другой пример. Когда на собеседовании спрашивают про ACID и изоляцию. А в компании нет ни одной нагруженной БД, чтобы эти инструменты вообще пришлось применять. С одной стороны это "сильно связано" — интервьювер знает, что человек умеет в это напрвление тоже. С другой стороны "слабо", потому что эти знания исользованы не будут.


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

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


Почему нагруженной?
Это к любой БД имеет отношение.
А уж любая БД точно есть.
А уж любая БД точно есть.

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


Я вот библиотеки, к примеру, пишу. Микросервисы там всякие. Как и зачем мне общаться с базой — загадка. Причем, замечу, я выбросил persistent storage из двух микросервисов и заменил его на горизонтально масштабируемый пул supervised гринтредов как раз, чтобы не жертвовать ничем из CAD, и I туда само бесплатно при таком подходе влилось, ибо процессы в OTP полностью изолированы по определению.


Я, в принципе, согласен, что про теорему CAD знать хорошо, но вот «база есть везде» — это сродни «веб есть везде». Оно, может, и есть — но с ним можно десятилетиями не сталкиваться, если неохота.

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

Неправда. Я ни в чем вас не обвиняю. Вы все сделали сами:


[...] людей, которые не хотят развивать свои инструменты. [...] они уже не полноценные профессионалы

Я даже прямую цитату привел, чтобы избежать кривотолков.


На собеседованиях задают много вопросов [...]

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

Вы привели следующию цитату


они уже не полноценные професионалы

И первое предложение


Адекватные люди профессионализм измеряют выхлопом, а не инструментами.

И далее по комментарию видно, что вы спорите с утверждением "новомодные инструменты === профессионал".


1) Меня очень сильно раздражает что проверку AST дерева называют навомодной. Этому подходу более двух десятков лет.


Это как нызвать електрошуруповерт "новомодным".


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

далее по комментарию видно, что вы спорите с утверждением «новомодные инструменты ≡ профессионал».

Протрите очки, пожалуйста. Я спорю с утверждением «¬ новомодные инструменты ⇒ ¬ профессионал», которое вы высказали и которое ни разу не изоморфно вашему. Инверсия логического отрицания работает немного иначе.


Я говорю про необходимое, но не достаточное условие.

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


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


Но в актуальных задачах разработки (нагрузка, десятки тысяч гринтредов, распределенный горячий кэш, preemptive failover, настоящий zero downtime, и т. д.) — инструменты не помогут примерно никак. Даже отладчик, я не говорю про интеллисенс.


проверку AST дерева называют навомодной. Этому подходу более двух десятков лет.

Во-первых, более двух десятков — это 62, забавно вы округляете. Во-вторых, проверка AST в момент написания кода мне лично вообще никуда не вперлась, я умею компилятор запустить, когда надо. На лету она только путает, мерцает, отвлекает и мешает думать. В-третьих, «AST дерева» — это немного тавтология, «T» там и так уже дерево. В-четвертых, в мире существуют только четыре языка с полноценной поддержкой AST, и ни один из них не используется широко (у раста есть шансы, впрочем). В-пятых, наконец, в нашем ремесле — результат все-таки важен несоизмеримо больше процесса, о чем я и сообщил в предыдущем комментарии. Если код работает, не имеет никакого значения, написан он угольком на бересте, или в SuperASTBuildingAndSyntaxHighloadingTool.

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


Как много людей смогут Вас заменить? Как долго они будут разбираться? Как долго будет чинится система с "настоящим zero downtime" когда в ней обнаружат непонятный баг?


Шуруповерт можно производить используя уникальные пятигранные винты. Однако это негативно сказывается на поддержании этого продукта в рабочем состоянии.

С чем разбираться, с блокнотом? ) с IDE посложнее будет

С кодом.


Смысл инструментов в том, что с ними уже умеют работать. Если же это велосипеды — то их эффективность резко падает.

С кодом по любому придётся разбираться, хоть с суперкрутыми IDE, хоть с голой консолью. Обычно программисты имеют право выбирать в блокноте, редакторе или IDE они будут работать с кодом. В репозитории-то код идёт.

Конечно. Вопрос в том, как долго. Если надо потратить столько же времени, как написать фичу с нул — то в чем смысл?

Кто по вашему создает те инструменты, которые позволяют вам не городить велосипеды?

Как думаете, какую часть своего рабочего времени они тратят на валидацию AST?

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

Обжигатели горшков?


какую часть своего рабочего времени они тратят на валидацию AST

Зависит :)


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


[...] чинил код для построения AST

Контрибьюторы компиляторов 2 : 0 адепты IDE.

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


chapuza такой же вопрос, на Ваш комментарий.

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

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

В четвертый раз. Я не говрю про иде. Я говорю про фичу. Которая может быть и не в ИДЕ.


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


хм
Я запутался. Вы пишете:
Напоминаю, что дыроколы тоже писали самый сложный код своего времени. Без них современного программирования не было бы.
И это тоже написали вы:
Были люди, которые умели программировать на перфокартах. [...] Проблема в том, что они не отличные спецы. Если бы таких было большинство, мы бы никогда не перешли от машинного кода к асемблеру.
Один я вижу здесь прямое противоречие?

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

Уверен, что не только Вы. Противоречия тут нет. Часть людей, которые работают на Х, создали Y. Отсюда первое утверждение. Большинство со временем, стало использовать Y вместо X.


Однако, если бы большинство рассказывало, что Y ненужен и как у них все классно в X — Y бы де-факто был бы мертв. Отсюда второе утверждение.


Заблуждение в том, что я там и там описывают одних людей. Это нет так. Те и те люди писали код на перфокартах. Но первые создавали замену перфокартам, а вторые — рассказывали, что замена никому не нужна.

Я, наконец, понял, что за недопонимание тут приключилось.


Ни я, ни defuz (смею сказать от его имени), не против прогресса. Наоборот. Мы этот прогресс даже — в меру сил и умений — вперед двигаем: вот коллега парсинг AST в расте поправил, я понемногу компилятор эликсира рихтую надфилем.


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


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

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


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

вам шашечки, или ехать?

А можно мне и то, и то? Я хочу, чтобы у таксиста была бы и рабочая сертифицированная машина, и права на вождение, что не отменяет требования «доехать и пункта А в пункт Б».


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


Фраза выше — это отличный пример троллинга-манипуляции: вам в машине двигатель или коробку передач? В телевизоре должен работать звук или видео?

Я как-то не припомню, чтобы где-то выдавали сертификаты по владению IDE, и где-то их требовали. Как думаете, почему?
Я как-то не припомню, чтобы где-то выдавали сертификаты по владению IDE, и где-то их требовали. Как думаете, почему?

Я написал про некорректную фразу, не более. Она не является ни доказательством, ни обоснованием.


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


Если мы вернемся к теме ветки, то у меня нет своего мнения на этот счет (ни обоснованного, ни эмоционального). Иногда необходимо уметь работать без IDE, иногда это неэффективно. Лично я пишу 99% кода в IDE, а оставшийся процент — это либо однострочники, либо мелкие исправления в известном мне коде. Но это лично мой опыт, а исследований я не только не проводил, но и даже не читал. Навязывать что-то я тоже не хочу. Так что тут мне сказать нечего. Основной мой посыл — фраза про шашечки является некорректной, как и заезженная "исключение доказывает правило".

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

Если дальше проводить аналогии, то я сравнил бы IDE с автоматической коробкой передач – кому-то с ней удобнее, а кому-то она будет мешать, если человек хорошо ездит на механике. Но вряд ли вам прийдет в голову утверждать, что те кто ездят на механике – плохие водители. И, как и автоматическая коробка передач для водителей, IDE не расширяет фундаментально ваши возможности как разработчика.
Лично я пишу 99% кода в IDE, а оставшийся процент — это либо однострочники, либо мелкие исправления в известном мне коде


Аналогично, кэп.

Но ключевая польза IDE ровно одна — автодополнения названия функций/методов/классов.

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

Ну то есть тут нет какого профессионализма или непрофессионализма.
Просто ограничения человеческой памяти.

Или вы всерьез считает, что кто-то освоивший концепции программирования может при этом не понимать что такое autocomplete в IDE?
Но ключевая польза IDE ровно одна — автодополнения названия функций/методов/классов.

Ну да, ну да.


А как же семантическое переименование сущностей? Переход от объявления к реализации и наоборот? Поиск использований сущности? Подсказки типов? Визуальный мердж, в конце-концов?

Но ключевая польза IDE ровно одна — автодополнения названия функций/методов/классов.


А как же семантическое переименование сущностей? Переход от объявления к реализации и наоборот? Поиск использований сущности? Подсказки типов? Визуальный мердж, в конце-концов?


Я написал ключевая польза.
Вы же приводите пример пользы вообще.

То, что вы написали — вторично.

Если предложат на выбор — автокомплит или все остальное — что выберите?

Лично я рефакторинг и поиск использования/объявления

Лично я рефакторинг и поиск использования/объявления


Использовать/не использовать != ключевой или не ключевой фактор.

Я все это использую.
Но не считаю самой важной особенностью IDE.

Хотя, когда появилось функциональность рефакторинга в начале 20 века в Intellij — это было «вау».
Если предложат на выбор — автокомплит или все остальное — что выберите?

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

Автокомплит лишь немного экономит время при наборе кода


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

Использую потому что не помню 100500 названий функций.

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

Переход на объявление же :)

Переход на объявление же :)


Для начала нужно помнить название типа экземпляр которого ты объявляешь.

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

Она всегда нужна. Потому что у свойства/метода есть еще параметры, допустимые значения на входе и возможные варианты возврата. И IDE помогает только с названием метода и (иногда) с названиями параметров.
Только вот она вам вывалит сырцом все 254 метода, 130 полей и сверху, в поле выбора, будут внутренние методы, начинающиеся с подчеркиваний. И?

Она всегда нужна. Потому что у свойства/метода есть еще параметры, допустимые значения на входе и возможные варианты возврата. И IDE помогает только с названием метода и (иногда) с названиями параметров.


Моя Jetbrains IDE показывает и параметры.
Причем еще древняя Delphi это умела в начале веке.

Грамотно составленное API библиотеки имеет логично названные и функции и параметры.

В результате не нужно на каждый вызов идти в документацию. Документация нужна только «чтобы въехать в тему».

После чего достаточно подсказок автокомплита.

Только вот она вам вывалит сырцом все 254 метода, 130 полей и сверху, в поле выбора, будут внутренние методы, начинающиеся с подчеркиваний. И?


Дайте угадаю:

Вы пишете на языке с динамической типизацией? Это там такие простыни подсказок, видимо?

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

Собственно это одна из двух причин, почему я предпочитаю языки со статической типизацией.
Дайте угадаю:

Зачем гадать, когда можно прочитать процитированный фрагмент?


Хоть с автокомплитом, хоть без, если вы не знаете названия метода — вам в документацию. Если вы запомнили его неправильно — вам в документацию. Если вы не помните особенности метода — вам обратно в документацию. До тех пор, пока сигнатура функции и половина документации не отпечатаются у вас в памяти — вам в документацию; или при написании, или, если у вас синдром "прокатило", потом при отладке, когда "прокатило" не прокатит.


Дело в том, что языке со статической типизацией — подсказки IDE максимально уточнены

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


А когда вы помните сигнатуру, то допечатать обычно быстрее, чем ждать пока протупит подсказка автокомплита. Разве что у вас методы и поля по 30+ символов, но это уже проблема совершенно другого рода.


Емнип, у дельфи в 5 версии была самая лучшая IDE. Ее было очень удобно изучать автокомплитом.
И он был настолько шустр, что даже почти не мешал при написании…

Хоть с автокомплитом, хоть без, если вы не знаете названия метода — вам в документацию.


Странно, почему то у меня работает без простыней кода.
Наверное потому что IDE учитывает тип возвращаемого значения? Наверное потому что IDE умеет искать не с начала названия метода?
А возможно, IDE использует какой-то «нечеткий поиск»?

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

Ну лет 10 назад я бы с вами согласился.
Но на современном железе что-то тупит?

Наверное потому что IDE учитывает тип возвращаемого значения?

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


Наверное потому что IDE умеет искать не с начала названия метода?

Так это только увеличит количество вариантов


А возможно, IDE использует какой-то «нечеткий поиск»?

А это еще пропорционально домножит.


Ну лет 10 назад я бы с вами согласился.
Но на современном железе что-то тупит?

Да вот как-то современное железо еще купить надо бы.
А так пока что Sublime 3 — наше всё.

Наверное потому что IDE умеет искать не с начала названия метода?


Так это только увеличит количество вариантов


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

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

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


Вы из числа всевозможных комбинаций считаете что ли?

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

Чем больше вы даете подсказок IDE, хоть даже вы и делаете это отдельными буквами — тем меньше список, который IDE вам предлагает.

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


Ну здрасте.
Вы же сами написали «метод», то есть он привязан к классу.
В грамотно продуманном классе, как правило, методов не сотни.

Или у вас гиганские классы-боги только в ходу?
Тогда я понимаю откуда вы взяли портянки автокомплита.

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

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

Это у вас надо спросить. Вы же пишете:


Наверное потому что IDE умеет искать не с начала названия метода?

и


А возможно, IDE использует какой-то «нечеткий поиск»?

Без комментариев.


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

В идеально-продуманом классе, написанным сферическим сеньором в идеальной команде по идеальным гайдлайнам… не слишком ли мало идеального в требованиях?


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


У меня второе подозрение, что вы пишете на языке с динамической типизацией.

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

Я первым грешным делом подумал на vim у вашего оппонента, но и Sublime хрен редьки не слаще.

Плюс у него в классах
все 254 метода, 130 полей

Это не особенности языков с динамической типизацией. Тот же PHPStorm дает вполне вменяемый автокомплит на адекватном коде.

Это особенности того, как он (ваш оппонент) пишет свой код. Потому и страдает.

А PHPStorm (или любая другая идея) умеет Idris? Потому что на PHP можно и в блокноте писать, там IDE при наличии минимального интеллекта вообще не требуется.


А вот в Idris (ну в Агде тоже) без фидбека компилятора делать вообще нечего. Так как там? vim умеет, если что — и в case split, и в дырки, и во все остальное.

Вы плохо знаете php-экосистему.
Изучите ее, потом расскажете свои впечатления о виме в ней

Вы плохо знаете вим. Изучите его, потом рассказывайте о каких-то там экосистемах.

Когда хотел попробовать Idris, нагуглил, что плагина для IDE от JetBrains нет, но люди приспособили плагин Haskell и худо-бедно базовую поддержку Idris получили (для меня звучит дико :) ).

люди приспособили плагин Haskell и худо-бедно базовую поддержку Idris получили

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


Эти люди, которые «приспособили» — они вообще не понимают, зачем им идрис. Хаскель против идриса — ну если не сравнивать возраст и качество компилятора — пшик. В типах, как таковых, никакого смысла нет, а зависимые типы первого класса — это прямо глоток свежего воздуха в душном мире CS.


Если бы меня не тошнило от Idea, я бы сам, кстати, плагин написал бы: там ≈10 прямых вызовов API компилятора надо имплеметировать и ответ в редактор прокинуть; компилятор идриса сам себе language server.


Но мне с головой хватает вима и vscodium’а, а там с плагинами все в порядке.

Эти люди, которые «приспособили» — они вообще не понимают, зачем им идрис.

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


Или спросил где-нибудь "надоело по TDD писать, которое про тесты, хвалят на Хабре то, которое про типы. Какой язык сейчас самый перспективный считается?" и кто-то называет тот же Idris. Открываешь доку и там "create a file called hello.idr containing the following text". Ну не в блокноте же создавать, избалованы же MSами, JetBrainsами и прочими Borlandами, нам GUI подавай, автодополнения и рефакторинги. и вот не начав изучать языка начинаем настраивать среду разработки...

Idris — это совсем другой подход к программированию вообще просто. В отличие от того же хаскеля — там синтаксис бегло просмотрел — и ты уже на коне. Тут нет.


Если хотите, оставьте почту в личке, я скину «Type Driven Development» Эдвина Бради, автора языка. Смысл TDD в том, что в языке с настоящими зависимыми типами (которым хаскель не станет никогда) — тип такой же полноправный элемент языка, как все остальное. И пока вы инкрементально пишете код, компилятор вам выводит по типам, что тут может появиться, что — нет, и во многих случаях, получается так, что пишет код за вас.


P. S. что-то мне сложно представить себе ситуацию «пришел на проект, а там внезапно идрис» :)

В отличие от того же хаскеля — там синтаксис бегло просмотрел — и ты уже на коне.

Ну нет, синтаксис в Idris гораздо проще же. Сам Брэди об этом говорит (например, тут https://corecursive.com/006-type-driven-development-and-idris-with-edwin-brady/).
Haskell большой, сложный и постоянно расширяется. Зависимые типы делают язык более простым и однородным.


синтаксис бегло просмотрел — и ты уже на коне

Ага. От беглого осмотра синтаксиса сразу впечатывается в мозг вся Typeclassopedia и семантика GHC Runtime, начинаешь ориентироваться в сотнях расширений GHC и не задумываясь писать Хаскель-код который не тормозит и не течёт мемликами.


Idris — это совсем другой подход к программированию вообще просто.

Другой подход именно к процессу набора кода. Процесс дизайна программ не сильно меняется.


В типах, как таковых, никакого смысла нет, а зависимые типы первого класса — это прямо глоток свежего воздуха в душном мире CS.

У зависимых типов, конечно, много приятных применений (самый близкий мне пример, пожалуй, — схемы бд).


По мне так type inference + pure functions + ADTs + pattern matching + type classes дают 80% профита от ФП в принципе, и дальнейшее усложнение типов — diminishing returns, хоть и не лишено смысла.


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

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

синтаксис в Idris гораздо проще же

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


Haskell большой, сложный и постоянно расширяется.

И именно поэтому он — обреченная, тупиковая ветвь развития.


начинаешь ориентироваться в сотнях расширений GHC

Вы хвастаетесь неизлечимыми пороками языка, ради оправдания которых была даже выдумана максима «avoid success at all cost»? Это религиозное?


Процесс дизайна программ не сильно меняется.

Эмммм… Я вот некоторые критичные части нашего софта пишу на идрисе, а потом руками транспилирую куда надо (эрланг, джава, руби). Именно потому, что процесс дизайна программ вообще другой. А не потому, что мне нужны типы (не нужны).


type inference + pure functions + ADTs + pattern matching + type classes дают 80% профита от ФП

К ФП напрямую тут относятся только pure functions.


усложнение типов

Назвать зависимые типы — усложнением системы типов, это как назвать отрицательные числа — избыточным усложнением арифметики.


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

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

… а в документацию каждый раз лазать — не продуктивно.

Если документация удобная, наглядная и с поиском, то почему бы и нет?

Если документация удобная, наглядная и с поиском, то почему бы и нет?


а что есть без поиска?

Продуктивнее в неё вообще не лазать при наборе кода, когда уже с докой разобрался.

Лазать в доку только для составления концепции работы с той или иной библиотекой.

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

И вроде бы ты помнишь что тебе нужна такая функция и она есть. Но вот как она называется SignRSASHA или SignSHARSA — хоть убей не помнишь уже.
Фраза выше — это отличный пример троллинга-манипуляции [...]

Ничего подобного. Все перечисленное вами — гарантии на будущее, формальный сертификат, обучение заранее, «результат» не развалился через месяц — это про продукт.


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

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


"Шашечки или ехать" — это стандартный прием "выбор без выбора".


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

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

это стандартный прием «выбор без выбора»

Вы неверно понимаете, в каком значении там используется «или». Ну да ладно, у вас все равно наверняка найдется еще немало ссылок на умные статьи по психологии.


P. S. Иконки на торпеде:


Иконки на торпеде

После новости, что xi умер у меня упала всякое желание дальше продолжать дискусию. Потому что ваша (не лично Ваша, а множество людей) точка зрения, что писать в блоконте нормально — останется де-факто верной еще минимум 5 лет. Может быть кто-то через несколько лет опять поднимет знамя и займется системой для ввода, которое работает бытрее и блокнотов и ИДЕ. А может быть такого для клавиатуры уже не будет.


Но ради imanushin.


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


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

Какая ирония.

Между прочим, для токенизации кода и подсветки синтаксиса в xi-editor используется пакет syntect, который в свою очередь основан на моем заброшенном проекте sublimate по созданию open source клона Sublime Text 3 и на моем байндинге регулярных выражений oniguruma.

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

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

Следуя вашей логике, я, как человек, 7 лет назад отказавшийся от IDE в пользу «блокнота», либо развиваюсь в обратном направлении как специалист, либо вы пишете полную ахинею.

Это еще очень сильно от языка зависит. И от уровня владения этим самым языком.


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


А вот идрис (да и агда), например, в блокноте просто потеряют 95% своего очарования, потому что основной смысл языка в принципе — помощь в доказательстве лемм, которые без обратной связи с компилятором можно и в императивном языке доказывать, и на бумаге. Это очень значительная часть процесса написания кода (если не использовать их как хаскель, конечно) — и посредник между компилятором и человеком тут просто необходим, потому что далеко не каждый case-/with-сплит очевиден, я уж молчу про проверку тотальности.

А вот идрис (да и агда), например, в блокноте просто потеряют 95% своего очарования

+100500


Использовать языки вроде Coq без какого-нибудь Proof General — за пределами человеческих возможностей, как мне кажется.

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

«У нас много легаси на Coq» — это, наверное, самое козырное описание вакансии, которое вообще можно себе представить.

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

Это еще очень сильно от языка зависит. И от уровня владения этим самым языком.
А еще очень сильно зависит от класса решаемых задач.

В моем случае, приведение написанного кода в компилиреумый AST – дай бог если 5% работы, и это при том что я пишу в том числе на Rust, который славится придирчивостью компилятора.

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

Плюсы от «блокнота»:

1. Минималистичность, и, как следствие, 100% предсказумость рабочего окружения. Мне никогда не приходится бороться с моим инструментом, ждать перестроение индексов или убеждать окружение что то что я сделал на самом деле правильно. Мне никогда не нужно конфигурировать окружение – конфигурация одинакова для всех проектов. Я просто открываю файл и пишу код. Отклик окружения на мои действия всегда миллисекундный, и окружение никогда не мешает мне работать с той скоростью, которой я могу.

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

3. Я знаю, как писать правильный код. Когда цена написания ошибочного кода выше, начинаешь задумываться, как с первого раза писать код, который заработает. В итоге написание кода для меня – это не игра в кошки-мышки с компилятором, а именно процесс написания, с последующей верификацией компилятором. Я спокойно могу написать 500-1000 строк кода без помощи компилятора, и только затем с его помощью отловить пропущенные ошибки. Я не трачу время на исправление ошибок в коде, который будет несколько раз переписан по ходу изменения структуры решения.

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

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

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

7. Поскольку нет IDE – нет и деббагера. Лично я считаю, что дебаггеры делают разработчиков ленивыми и не способными писать одновременно понятный и работающий код (кроме случаев низкоуровневого системного программирования). Если мой код не работает, я думаю как написать тест, который проверит мои предположения о его работе. Или добавляю строку в лог, которая поможет лучше понимать происходящее. И если код трудно «отдебажить» без дебагера, скорее всего он плохо спроектирован, и стоит задуматься о его рефакторинге. Для меня код, который настолько запутан, что в нем трудно сразу увидеть ошибку, такой же проблемный, как и не работающий код.

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

А я вместо того, чтобы заучивать документацию на выходных погулял с детьми в ботаническом саду. А за 8 часов работы мне таски надо делать, а не дзен постигать, потому что скрам и надо делать быстро новые фичи.
П.С. Я все рано использую emacs + LSP, но вот без последнего пришлось бы действительно туго

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


И кроме тех языков, в которых я не чувствую себя свободно (java, python, R, haskell). Раст пока ходит мимо меня, но вот Julia внезапно зарекомендовала себя очень круто именно потому, что я со второго часа погружения выкинул LS и стал писать «в блокнот». Что характерно, с хаскелем этот вариант не пройдет, из-за ублюдочности дизайна Prelude и миллиарда функций в глобальном неймспейсе, подтянутых из квадриллиона сторонних пакетов, по сотне раз дублирующих одно и то же. Я просто не способен выучить это все наизусть (да и не хочу, и смысла не вижу).


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

Ну так Idris и его старшие коллеги не просто так называются proof assistant. Еще к «IDE oriented» языкам я бы добавил C# и Java. Их использование с MS Studio и IntelliJ оставило у меня исключительно приятные впечатления.

А вот для Python рекоммендации IDE меня только бесили, потому слишком часто ошибались. В конечном итоге меня интересует лишь мнение компилятора/интерпретатора о выполнимости моего кода, и если мнение IDE с ним расходится, то я начинаю отвлекаться на несущевствующие проблемы.

C Rust та же проблема, хоть он и статически типизирован. Там проблема в том, что пока не смогли сделать одновременно быстрый и корректный language server, из-за сложного выведения типов и навороченности макросов.
Это еще очень сильно от языка зависит. И от уровня владения этим самым языком.


Типа вы на память помните названия всех функций из 100500 библиотек — это великолепное знание языка?

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


Что касается X as a code — это вполне себе код. Разнца только в том, что это декларативный код, а не императивный, как большинство ЯП.


И IDE в этом случае делает то же, что и в любом другом — пытается эмулировать воспроизведение этого кода его интерпретатором/компилятором, обычно за счет анализа.


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


Если вопрос в том, что не все IDE пока умеют хорошо с этим справляться — вопрос времени и установки плагинов.


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


Скорее всего это исправится со временем, когда появятся стандарты для описания фасада контейнера в явном виде (сейчас можно только список ENV прописать, но это больше хороший тон, нежели стандарт).

Виноват, пропустил комментарий за срачем выше.


Разнца только в том, что это декларативный код, а не императивный.

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


Конечно, со временем ИДЕ научатся стирать эти границы. Первые попытки уже можно найти. Но есть все шансы, что к этому моменту уже и докера не будет. Может даже и ИДЕ уже не будет.

Концепция X as a code наверняка надолго переживет докер.


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


Вполне вероятно, что императивное программирование, про которое вы говорите


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

Excel и прочие электронные таблицы же

По своему опыту могу сказать, что сколько-нибудь нетривиальная обработка данных в Excel(-like) в какой-то момент вызывает острое желание переписать это всё на нормальный ЯП.

По своему опыту могу сказать, что сколько-нибудь нетривиальная обработка данных в Excel(-like) в какой-то момент вызывает острое желание переписать это всё на нормальный ЯП.


Там же есть встроенный Visual Basic?
Я же сказал нормальный ЯП.


С формальной точки зрения Visual Basic — вполне себе полноценный язык программирования. Там всё есть.

Ну а прямой доступ из него к объектам Excel позволяет легко писать «нетривиальные вещи» которые вам были нужны.

Это далеко не Basic, от которого только название. А вполне себе развитый по выразительным средствам язык.

Вам же не Kubernetes на нём писать.

Так что делать то? Докер умер, да здравствует кто? Судя по тексту Swarm сырой ещё. Вообще в статье все уг, не понятно куда простому разработчику двигаться. С докером хоть понятно все и инструкций полно.

Читайте https://m.habr.com/ru/post/467607/
Кратко — редхат завозит podman & buildah & skopeo для разработки
В опеншифт — докер ими заменяем на cri-O
В кубере — все нормальные люди уже выкидывают докер и ставят containerd/runc
Кто-то идёт дальше и заменяет runc на gVisor или kata.
Для изучения:
https://t.me/sre_hamster/70 (там две ссылки на серьёзные исследования)


Где докер пока ещё останется жить — это локальная разработка (но с тем же успехом можно вагрант машины использовать, тем более на виндовых или мак машинах))))

Это ты сам сказал ) но в целом — да, мне не нравятся универсальные решения именно тем, что у них очень большие амбиции по спасению человечества, а в результате они не решают никаких проблем, а сами становятся проблемой. В частности, в поддержке.
Вот пример — https://github.com/kubernetes-sigs/kubespray/pull/6814
Это настолько грустно, что уже не смешно

Докер никуда не делся. Он живет и здраствует в небольших инсталляциях, на машинах разрабов, в CI. Эта экосистема отлично поживает и никуда не делась. Если мне надо поднять какой-нить гитлаб для офиса, то я это буду делать в докере естественно, потому что все под него написано. А еще лучше docker compose.

Докладов по нему не так много, но они есть. Непонятно зачем-то тут говорить за всех на основе российского сообщества. Туториалов полно создается до сих пор именно по нему. У меня тут другое мнение. Докер очевидно перешел в стадию зрелой технологии — он просто есть и стал синонимом контейнеров. Все о нем знают, все им пользуются. Смысл о нем говорить. Говорят о том, что модно и развивается, что постоянно меняется. Много ли говорят про виртуальные машины, какой-нить виртуал бокс, esxi? Нет, но странно на основе этого делать вывод, что они мертвы. Они просто есть и неотъемлемая часть инструментария.

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

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

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

скорее — наши кормильцы, хлеб насущный нам дающие… vivat!

Судя по тексту Swarm сырой ещё.

Он уже не высохнет.
Его развитие официально прекращено.
Рискую нарваться на минусы со стороны «пряморуких» людей, но все же напишу. Я в прошлом системный администратор, сейчас разработчик, с докером дел особо не имел, пару раз чужой проект разворачивал локально, там да пришлось ставить docker compose и поднимать всю необходимую инфраструктуру, но это все с гуглением и чтением SOF, а также документации.

А вот недавно решил научится делать свои образы и вообще научится пользоваться Docker, сделал микроскопическое приложение на flask (несколько килобайт), создал Dockerfile прописал там все инструкции и ужаснулся введя docker build -t image_name, при сборке скачалась куча разных либ и файлов, суммарно чуть больше гигабайта, а если прикинуть сколько там кода, который возможно никто не проверял, откуда он качается? Как он будет влиять на работу хоста? А на работу приложения как будет влиять? А если что то заглючит где искать концы? В общем мне показалось все это не очень надежным и не безопасным, отчасти я нашел подтверждение своим подозрениям в статье, спасибо автору.
Ваши подозрения мало связаны со статьей, которая говорит о докере и оркестрации. Докер не виноват, что ваше приложение на фласке занимает гиг. Мои приложения на Go занимают несколько десятков мегабайт — это мое приложение + alpine контейнер. Все ясно и понятно. А уж откуда что качается, как влияет на что — ответы на все эти вопросы можно легко найти, если изучить матчасть немного, а не просто по случайному туториалу чего-то делать. Когда кажется, то это всегда исходит от непонимания.
alpine контейнер.

не надо про эльпайн ок? Если человек умный — он делает из scratch или distroless.
А с эльпайн — можно напороться на кучу проблем. И это только вершина айсберга:
https://habr.com/ru/post/415513/
https://habr.com/ru/company/flant/blog/452754/
https://habr.com/ru/post/486202/


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

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

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


А зачем Go контейнер, он же по умолчанию вкомпилирует в бинарник библиотеки и более не зависит от окружения, кроме ядра ОС?
От libc по умолчанию зависит (резолвинг DNS).
А вообще вот вывод ldd на гошный бинарник:
linux-vdso.so.1 (0x00007ffdced79000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fedff5ba000)
libc.so.6 => /usr/lib/libc.so.6 (0x00007fedff3f1000)
/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fedff9a7000)
Упомянутые библиотеки являются частью дефолтной инсталляции операционной системы.
более не зависит от окружения, кроме ядра ОС?

Я лишь указал, что приведённая цитата не совсем соответствует действительности. И продолжая далее: если мы завязаны на дефолтный резолвер, то нам уже могут понадобиться resolv.conf, hosts, а это уже NSS. И это только первое, что пришло в голову, так что цитата «небольшое окружение для правильной работы приложений...» остаётся актуальной.
несомненно, все так — нужно изучать матчасть. Проблема только лишь в том, что докер снижает планку настолько сильно, что можно получать результат без матчасти, а потом удивляться, что же все так плохо работает. С другой стороны — в быстром результате есть плюс. Главное, не останавливаться на нем, а продолжать процесс познания

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

Ну, все правильно — зачем нужен докер? Чтобы заметать этот мусор под ковер. Не держать его на хосте. Раньше же как — в первую очередь с интерпретируемыми языками вроде php, python, ruby — было целое приключение установить несколько версий на хост одновременно. Потом конфликты библиотек и окружений. Докер действительно эту проблему решил — изолировав эту "помойку" внутри контейнера. Но здесь появилась новая проблема. Разработчику решительно перестало быть нужно разбираться в этой "помойке" и как-то ее оптимизировать. Если это было необходимо, чтобы обеспечить стабильность работы системы (см. выше) и это было действительно сложно, практически ювелирной работой, бывали отказы из-за этого, то теперь все стало сильно проще и можно делать "как попало", т.к. это не дает немедленного манифестация каких-либо проблем. Эффект отложенный. А потом спустя недели, месяцы или годы проблема встает в полный рост, но уже поздно что-то менять. В результате мы обмазываемся принципами вроде того, что "контейнеры эфемерны" и "релизы должны релизиться максимально часто". Ну, ок — ТАК ТОЖЕ МОЖНО ЖИТЬ. И оно даже дает приемлемый результат для большинства задач… Но все равно нельзя говорить, что так нужно делать везде — например, в более консервативных средах или в средах требующих повышенной надежности.

Аргументация негативного опыта уровня "Я не разобрался в командной строке, ваш Linux — УГ!". У меня средний production-образ весит ~20-50mb, это я ещё туда системную обвязку для траблшутинга втаскиваю (всякие nc, dig, netstat, tcpdump и т.д.). Как же так?

Ну, здесь проблема ожиданий и реальности. Ожидания — докер решит все проблемы, все будет круто. Реальность — это инструмент со своими прибабахами и далеко не универсальный. Это не означает, что докер — абсолютное зло ) он вполне применим для определенного класса задач, но дело в том, что об этом ( как его правильно применять ) — никто не рассказывает. Например, amarao недавно рассказывал, что его спасло --network host, чтобы затащить докер в прод. И я с ним полностью согласен. Сколько мне понадобилось времени, чтобы дойти до такого же мнения — 1 месяц экспериментов. А сразу про это никто подсказать не мог :-/

Это что ж такое было, что network host нужен был? По опыту такое нужно всякому легаси и кривом уг вроде freeipa.

тем, что бриджованные сети на самом деле не нужны, они снижают быстродействие (минимум на 5%), дают сложноконтролируемые эффекты на файрволл (например, публикация приложения docker run -p 80:80… идет через цепочку NAT и сервис становится доступен НАРУЖУ вне зависимости от настроек цепочки INPUT, что было бы логично)

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

Да, благо что большая часть CNI в Kubernetes сделана более грамотно, чем сеть Docker.

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


А процессы бывают разные, и уютный очередной CRUD с веб-интерфейсом — это не единственный тип приложения, которые бывают в этом мире.

Дефолтный бридж (ну или руками созданный) позволяет делать то, для чего докер был создан — изоляция. Внутри контейнера может быть хоть миллион портов поднято быть. Я все равно смогу вытащить только то, что мне нужно и только на том интерфейсе, на котором мне нужно. При этом контейнеры могу общаться между собой в своем уютном мирке и никого не трогать.
Поэтому если какому-то приложению, которое ничего не делает хитрого с сетью вроде DHCP или еще чего, абсолютно требуется для работы --net=host, то ему мало оправданий.
Внутри контейнера может быть хоть миллион портов поднято быть. Я все равно смогу вытащить только то, что мне нужно и только на том интерфейсе, на котором мне нужно.

с какой целью должно быть поднято миллион портов? Извините, из Ваших суждений — Вы ничего не понимаете. На уровне разработки — уверен, у Вас все прекрасно, на уровне эксплуатации — именно то, что я говорю. Я уж не говорю о том, что ВНУТРИ БРИДЖА НИКАКОГО контроля взаимодействия контейнеров нет.


Дефолтный бридж

тем более — в котором и изоляции нет, и DNS не работает, ага-ага.

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

Я уж не говорю о том, что ВНУТРИ БРИДЖА НИКАКОГО контроля взаимодействия контейнеров нет.

Ну так не используйте дефолтный, кто вас заставляет. Зачем кричать сразу.

тем более — в котором и изоляции нет, и DNS не работает, ага-ага.

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

А если у приложения нет портов? Например, у меня zigbee стек, или ble?


Вам CRUD на TCP сожрал всё.

вы находитесь в каком-то уютном мирке мегабитных коннектов.


Если у меня приложение генерирует несколько гигабит/с ICMP на почти рандомные адреса, то следует ли мне его пропускать через iptables, или --net=host всё-таки более разумное решение? (Приложение полностью легитимное и конкретному IP достанется не больше 3-5 ping'ов за 5 минут, плюс мы уважаем abuse'ы и блеклистим IP, которые нам не нужны).


На самом деле есть ещё масса причин для net=host. Например, потому что проект не на k8s/docker, а docker используется только для запуска приложений в контейнерах (например, графаны).


Или потому, что кто-то должен мониторить хосты под k8s, и метрики лучше собирать oob методом (без участия контроллеров).


Причин много, и вы смотрите на свой продакшен и не видите их. Чужие продакшены другие.


Просто представьте себе, например, IoT, где надо слать сетевой трафик (например, zigbee) — и как вы это завернёте в докер без net=host?

Это большая проблема, и люди уже начали потихоньку решать её, используя DSL-и Kubernetes на языках Kotlin, даже Typescript. Есть такой проект Pulumi, есть Amazon-овский проект EKS – хотя он больше ориентирован на Amazon; Pulumi – это такой Terraform, только на Typescript.

Можно подробнее про EKS в этом аспекте?

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


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


Пока что мало нахожу отличий по функционалу от nomad (кроме красивой админки). Скорее наоборот, в nomad можно найти решений поболее (например с теми же базами данных которые не обязательно тулить в контейнер). Только вместо загадочного монстра (к8) для работы nomad нужно скопировать (именно скопировать) один исполняемый файл.

Что значит "начала разрушаться"? Работала, но не совсем?

Такая была странная ситуация. Я меняю записи в таблицах а из мнений нет. Как будто бы я работаю в транзакции и она не коммитится. Потом все вообще перестало работать. Перед этим был рестарт контейнеров. Я для себя это объявил тем что какие то файлы необходимые для восстановления после сбое находились не в файловой системе а внутри контейнера и разрушились. Либо еще вариант что слоеная файловая система использует не такие железобетонные операции сохранения как это делает постгрес на хвостовой машине в результате чего их вероятность разрешения существенно выше. Кстати аналогичное слышал от знакомого очень крутого DevOps только про MySQL

Ну, какая проблема реально есть — это почти 100% аварийное завершение постгреса на любой мало-мальски крупной базе внутри докера при stop контейнера. Оно обычно проходит бесследно, т.к. при следующем запуске происходит recovery, но приятного мало — факт.
Проблемы же с потерей данных на aufs вроде бы давным давно решены отказом от этого самого aufs в пользу более быстрого и стабильного overlay2 fs.

А еще есть простое правило: рутовая файловая система самого контейнера должна быть установлена в r/o при запуске.
И /tmp тогда — просто точка монтирования тома с хоста.

да, все так — софт в контейнерах должен быть


  1. независим от user id (потому что оркестратор всегда может айди перемаппить и мы должны быть готовы к этому)
  2. не гадить себе под ноги. Т.е. рассчитываем на R/O файловую систему. А то тот же пайтон — начинает компилять py в pyc, выкачивать ML модели на эфемерный слой, а потом ловишь веселые спецэффекты.
    и куча еще всяких нюансов, что описаны и не описаны в 12 факторах
Вот с моделям мы наоборот намеренно пошли на такое решение и все нравится. Модели очень большие, класть их в контейнер нереально. Положили на S3, при старте под закачивает их себе в ФС, загружает в память и удаляет. Сейчас поднимем хранилище для подов, может будем монтировать эти модели прямо в под, что уберет копирование.
Модели очень большие, класть их в контейнер нереально

до 5ГиБ — реально класть в образ. Продакшн опыт. По крайней мере софт работает в этом случае бинарно — либо запустился и работает, либо нет (если образ не выкачался на ноду) — и не зависит от качества сети.
Единственное, я все-таки так и не проверил — как там mmap() работает и экономит ли память (грузить каждую модель в ОЗУ — очень расточительно на больших вычислительных узлах с сотнями подов)

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

либо запустился и работает, либо нет

Readiness пробы все решают.

У Вас более чем странные аргументы.
А рединес пробы — это вообще из другой оперы. Жаль, что Вы не распарсили, что я имел в виду.

Ничем они не странные. Когда держишь свой bare-metal кластер, то место на диске тратить на бесполезные копии моделей в каждом контейнере не хочется.
А рединес пробы именно из той самой оперы. Вы говорили про бинарность работы подов — либо запустился, либо нет. Так вот рединес проб эту бинарность дает. Пока модель не выкачалась под не запустился, все просто и понятно. Мне сложно распарсить еще что-то, если этого не было в вашем посте.
то место на диске тратить на бесполезные копии моделей в каждом контейнере не хочется.

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


так вот рединес проб эту бинарность дает.

только Вы еще добавляете еще зависимость от ненадежной сети :-/ И если делать скачивание c S3, как Вы предлагаете:


Положили на S3, при старте под закачивает их себе в ФС, загружает в память и удаляет.

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

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

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

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

это не так. Хотя бы потому что kubelet делает garbage collection на неиспользуемые по определенному набору критериев

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

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

Облачным сервисам в конечном счете интересна скорее не продажа Kubernetes как такового, а готовых managed-сервисов для более «конечных» (ориентированных на облачных пользователей) приложений: СУБД, очереди сообщений и т.п. — и сразу со всеми интегрированными, собранными в одном месте удобствами (метрики, мониторинг и т.п.). При этом пользователям вообще мало дела до того, как оно там устроено у облака внутри (K8s там или что-то другое), если он на выходе получает функциональный и стабильный сервис.

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

Пользователь хочет k8s, потому что он обеспечивает "единый язык описания" вне зависимости от нижележащей инфраструктура. Кубер в целом одинаковый и в amazon, и в google, и в azure, и в он-прем. Могут быть детали, какие-то дополнительные фишки, но это не критично

Вот буквально прямо сейчас пытаюсь сделать blue/green deployment на базе nginx с помощью ansible… И не хочу k8s — он слишком сложный, слишком избыточный для таких простых задач. А в Docker Swarm не хватает буквально нескольких фич. Потому старые добрые дедики или вдски, в которых создаёшь ющеров, ставишь пакеты, льешь апки и конфиги, просто вместо старого доброго баша модный ansible. С ужасом представляю, что бизнес рано или поздно поставит мне задачу перевести всё на куб.


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

Никакой трагедии. Ну, будет кубер вместо ансибла. Зато бизнесу выгода — не кастомные плейбуки, а вроде «стандартный» кубер....

Ну так и начинайте играться с кубером в свободное время. Когда-нибудь попросят, почему нет. Он не такой уж сложный. Да, избыточный, но вас не только не заставляют изучать половину его фич, но даже знать о них. Не нужно хранилище под поды — можно даже не открывать доки про CSI, pv, pvc. Не надо масштабирование — про HPA можно не вспоминать. И так со многими вещами.

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

  1. Простота обманчива.
  2. Развернуть долго? “rke up” и через 10 минут получаешь кластер ) здесь скорее больше времени правильное проектирование внедрения займет
  3. Насчёт эксплуатационной сложности — поддерживаю. Тем более, если там ещё навернуто хранение данных и куча всего другого. На самом деле с кубером сейчас ситуация как пару десятков лет назад с дистрибутивами линукса — полный «Дикий запад». И самое главное, что пользователю не «голый» кубер нужен… а платформенное решение для деплоя ( о чем выше shurup и пишет) — со всякой обвязкой, безопасное и удобное

По поводу rancher исходя из устаревшего сравнения https://dvps.blog/minimalnoie-sravnieniie-swarm-kubernetes-mesos-nomad-rancher/ там не все так ванильного. В частности сеть тормозная. Сам не разворачивал его. Но по отзыву одного человека который пробовал его два года назад глюки начинались еще на этапе разработки в результате чего взяли кубер от ДО

По поводу rancher исходя из устаревшего сравнения https://dvps.blog/minimalnoie-sravnieniie-swarm-kubernetes-mesos-nomad-rancher/ там не все так ванильного.

чушь. Они там сравнивают rancher 1.x. Rancher 2.0 — это просто панель к кубернетесу. А сетевой плагин можно выбрать любой — calico, canal, flannel. Т.е. ранчер — точно такой же кубер как и остальные куберы

Всё же не просто панель. Он вводит свои сущности, которых в кубере нет. И даже особо проигнорировать их не получится.

Там все сложно. Есть rke. Это дистрибутив куба, сделанный ранчером. Но не ранчер. В принципе, штука неплохая и достаточно беспроблемная sn00p может подробно рассказать. Никаких «левых» сущностей не тащит.
Ранчер же сам — это в первую очередь панель для централизованного управления кластера. И как Вы правильно заметили, тащит некие свои сущности в кластер (проекты, например, свою ролевую модель). В принципе, не выглядит как что-то совсем невменяемое, но специфика имеется. Мониторинг в ранчере тоже очень своеобразный. Плюс, что он есть. Минус, что они его сделали не самым прямолинейным образом. Интеграция с магазином приложений ( и там тоже есть как стандартные Хельм чарты, так и допиленные ранчером).
Я хотел бы, чтобы потенциальные пользователи этого решения сами его пробовали и осознанно выбирали нужно ли оно им. Есть строгие подозрения, что вместо ранчера лучше брать ОКД (бесплатный опеншифт), но в нем специфики ещё больше. Что с точки зрения разраба, что с точки зрения эксплуатации.

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

По поводу просто ота обманчива. С этим сталкиваюсь постоянно. Есть вроде бы тривиальная задача обновление бесплатных сертификатов letencrypt. Поначалу были пляски с бубном так как обновление не работает при включенном проксипротокол. Потом letencrypt начал менять свои алгоритмы и нужно было обновлять контейнер чтобы заработало. Потом это просто перестало работать и нужно обращаться к опытному девопса чтобы он сделал магию. В результате еще один проект на еще одной модной технологии которая там не была нужна. До этого был такой же та такой же можно aws ellastic container. Следующий подощреахваю будет на лямбда или на чем то от гугла. Мода она птица непостоянная

Развернуть долго? “rke up” и через 10 минут получаешь кластер )

А потом пару часов пытаешься понять почему по ряду задач у тебя 2 tps кладут твой магический кластер на k8s…

В общем, когда я слышу, что k8s поднимается за 5-10-15 минут и даже часов… То я понимаю, что либо проекту оно было незачем. Абсолютно незачем. Либо передо мной стоит очередной балабол евангелист/воссторженный юноша, который не работал с реальными прикладными системами, но начитался статеек и покрутил у себя на RaspberryPI minicube/rancher и иже с ними.

Вот последних лчень хочется зажарить на медленном огне.
А потом пару часов пытаешься понять почему по ряду задач у тебя 2 tps кладут твой магический кластер на k8s…

не принимается — это сертифицированный дистрибутив CNCF. А как известно… сломать можно что угодно :-)


В общем, когда я слышу, что k8s поднимается за 5-10-15 минут и даже часов…

в облаке тем более поднимается за 5-10-15 минут :-) Повторю тезис, что основные решения типовые, но если требуется что-то особенное — проектирование и согласование может занять времени существенно больше, чем фактическое разворачивание.

Есть ещё промежуточный вариант: вроде админы есть, но им нужна чёткая задача. Не "нам надо как-то файлы хранить доступными для всех ноды", а "сделайте динамические тома на базе nfs v4"

Мы пользуемся своим bare-metal кластером. Ни сложности самого кубера, ни сложности его поддержки пока не замечали. Единственный, по сути, сложный элемент кубера это etcd. Как обычно с кворумными системами это пляски с тем, чтобы оно собралось в кластер правильно. Он очень требовательный к дискам и может тормозить всю остальную систему.

Возможно у вас система и/или нефункциональные требования к неё (отказоустойчивость, автомасштабирование и т. п.) настолько сложные, что на её фоне сложность кубера теряется. Если же вам годами хватало docker-compose и небольшой обвязки и никакой кворум вообще не нужен был, только-только начали задумываться, а не принесёт ли пользу "апгрейд" до docker swarm и какие проблемы это может принести, а тут вам говорят перевести всё на кубер, просто потому что хотят для маркетинга продукта использовать "мы на k8s"

Есть упрощенные варианты кубернетеса, которые можно устанавливать на единичные отдельные ноды. Те же K3s, microk8ss, Minikube etc. Цель — унификация процесса разработки, доставки приложений, управления приложениями и эксплуатацией…

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

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

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

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

Подсказка: попробуйте microk8s.io. Эта фиговина с командной строкой (что ввести, чтобы получить миникубер прямо здесь и сейчас) сейчас встречает меня в banner на всех популярных vps cloud. И не зря, оно хорошо подходит для старта. Потом, чтобы перенести ваш деплоймент в настоящий кубер понадобится максимум с волюмами разобраться сетевыми, но все конфиги останутся те же самые.

Те несколько фич которых не хватает в сварме — это примерно половина всего кубера) Как только распробуете нормальные хелсчеки, сетевые политики, возможность подключать разные типы сетевых накопителей, init-контейнеры для миграций, логирование со множества контейнеров в одну консоль, и тд — будете вспоминать сварм как страшный сон. Я знаю, я строил кластер на сварме, и если бы не консул — точно ничего бы не получилось.
Кстати, а как это вы делаете blue/green deployment без консула и consul-template (consul-template позволяет на ходу переписывать nginx-конфиг, когда вы выкидываете очередную ноду с балансировщика)?

Да я распробовал всё это. Собственно сильно не хватает только инит-контейнеров и крон-джобов. Ну и чего-то типа helm3 в плане применения шаблонов.


Просто делаю blue-green: после раскатывания новой версии в конфиге nginx рут меняется ансиблем или башем и релоад. Это сейчас, когда даже докера нет на проекте. А когда сварм поднимал (тот что docker swarm mode, а не Docker Swarm), то docker flow proxy использовал: он слушал докер сокет и по меткам перегенерировал конфиги haproxy

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


Это очень полезно; это еще и сильно проредит ряды сисадминов и devops-инженеров.

О чем это он вообще? Ну если проредит, то ЗП станут больше, тогда конечно полезно.

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

Это шутка в тему того что программирование это про алгоритмы и не важно на каком языке? Или это на серьёзных щах? Просто интересно что будет если такое на собеседовании сказать, мол я не знаю вашего X с его библиотеками и фреймворками и прочей экосистемой, но алгоритмов знаю — просто тьма!

Говорю иногда. Обычно упирается в ЗП в крупных компаниях, типа мы верим в ваши способности изучать языки и фреймворки, но на испыталку в 3 месяца 50% от желаемой суммы только. Это если с улицы приходить на вакансии, где ищут разработчика X(Y)

но на испыталку в 3 месяца 50% от желаемой суммы только

Для меня это не звучит как подтверждение того что «конкретные языки не важны».

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

я не понял что хотел сказать автор, есть ещё кто-то такой?

Автор действительно поднял много важных вопросов, но он немного нарк… немного странный, поэтому важные вопросы смешались с неважными, с философией, с личным ИМХО в подходах.
Устроили сходку в Питере — и решили что они и есть DevOps всея России, смешно) Еще профсоюз организуйте с членскими взносами лично чистякову и лицензиями на работу с командной строкой докера.


PS VolCh рекомендую попробовать microk8s, не требует полной кубер инфраструктуры, все конфиги потом заработают в полноценном кубере, ну может придется волюмы поправить на другой тип.

тоже не понял.
Есть DockerCon, целая конференция о контейнерах в Docker-ах.
— «Так вот, Red Hat выкинули Docker вообще» — сомнительное утверждение. Мы активно используем OpenShift, и там до сих пор, даже в последних версиях используется Docker в качестве основного инструмента контейнеризации.
Можно хотя бы несколько обзорных статей, где RedHat подтверждает это или планирует хотя бы.
Мы активно используем OpenShift, и там до сих пор, даже в последних версиях используется Docker в качестве основного инструмента контейнеризации.

информация недостоверна. В новых версиях OpenShift — CRI-O.

Ещё и эта страшная физиономия с улыбкой отвращения…
Нафига здесь эта статья?
И они очень быстро переполняются; когда у тебя 80 различных переменных, 81-ю уже сложно воткнуть. Более того, это плоское конфигурационное пространство – когда есть переменные, их надо называть большими буквами с подчеркиванием, и среди них нет иерархии; сложно понять, что происходит. Я еще не придумал, как с этим быть, и мне не с кем это обсудить – нет группы энтузиастов, которые были бы против подобного подхода. Если это вдруг кого-то тоже не устраивает – напишите мне (demeliorator в Telegram), буду знать, что я не одинок. Мне это категорически не нравится. Этим трудно управлять, трудно передавать иерархические данные; получается, что работа современного инженера состоит в том, чтобы знать, где какие переменные, что они значат, правильно ли они заведены, насколько легко их изменять.


Практикую конфигурирование в кластере Consul/Vault.
А в переменных среды окружения передаются параметры для доступа к этим самым кластерам Consul/Vault — токены, адреса, префиксы веток конфигурации (prod/dev и т.п.)
Уже тогда можно было собрать высокопроизводительный вычислительный кластер из своего ноутбука и десктопа – так делали студенты в общежитии Санкт-Петербургского политеха году в 97-м.

В 1997 в общежитиях, даже Санкт-Петербургского политеха, не было ноутбуков :)

В 1997 в общежитиях, даже Санкт-Петербургского политеха, не было ноутбуков :)

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

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

Статью написал конкретный человек.
С чего это вы за официальную позицию компании считаете.
Деньги и личные предпочтения — это не всегда одно и то ж

Никогда не задумывались как на конференцию попадают топовые спикеры которых один перелет из США стоит больше чем все бабки которые собрали с присутствующих для создания ощущения некоторой независимости мнений (я ж плачу сам)

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

Если не задумывались могу высказать предположение что топовых спикеров финансируют заинтересованные в продвижении своих продуктов корпорации.
Или вы думаете что топовые спикеры реально мечтают за интерес приехать в Москву Питер или Свердловск. Узнав что там будет мега-интересная конференция.
Возможно выглядит это не так конкретно. То есть спикеру платят за консультации. Типа как политикам за чтение лекций в каких-то там университетах.
Если говорить о спикерах среднего уровня. То там проще. Человека конкретно нанимают спикером и платят за это без как говорится обиняков.

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


Может и такое быть. Но:

Нормальные фирмы оплачивают посещение конференций (полностью или частично) посещение своим сотрудникам в качестве слушателей.

Ничем принципиальным тут оплата тебе будь ты спикер или будь ты слушатель не отличается.

Причем слушателю даже больше приходится потратить ибо «приезд, проживание, отъезд + взнос». Чтобы спикеры делали взносы?

Или вы думаете что топовые спикеры реально мечтают за интерес приехать в Москву Питер или Свердловск. Узнав что там будет мега-интересная конференция.


Почему нет?

Что до меня: если интересная конференция — то отчего бы и не поехать и не выступить в каком нибудь Детройте или Марселе. Плюс мир посмотреть.

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

Если говорить о серверах среднего уровня. То там проще. Человека конкретно нанимают спикером и платят за это без как говорится обиняков.

О чем простите? О серверах?
Видимо вы имели ввиду о мелких конференциях, на которых оказывается неожиданно топовые спикеры — этим конференция может оплачивать, да.

Однако каким боком все эти измышления касательно данного спикера?

Он никуда не ездил — это онлайн-конференция.
Даже если бы и ездил — это же локально Питер-Москва, там недорого.

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

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


Посылать «живую легенду» по миру рекламировать что-то на региональных конференциях — совершенно тупо в смысле сливания денег маркетингового бюджета. Неэффективно.

Да и обидно «живой легенде». Подпишется ли на это «легенда» (если не деградировала)?

«Легенда» потому и легенда, что занимается реальным делом, а не подобной фигней.

Мне представляется вы выдумываете.
Посмотреть на медведей хотят многие. Нормальная мотивация.

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

Ну например чтобы далеко не ходить конференция по тому же DevOps и статья на этом же Хабре https://habr.com/ru/company/jugru/blog/415159/
Я не хочу сказать что все так примитивно. Живая легенда кладет баксы в карман и топит за k8. Но живая легенда будет выступать там где будут топить за k8. Для простых спикеров все проще. Либо ты топишь за k8 либы ты не интересен.
https://www.it-world.ru/events/conferences/153772.html
В частности на последней Daniel Stenberg: автор легендарной библиотеки cURL, активно работает с IETF над разработкой стандартов для HTTPbis и сетевого протокола транспортного уровня QUIC;

Это не захолустье.
В Питер-Москву приехать не проблема для иностранца.
Конференция по сути не принципиально отличается от любой европейской в любом крупном городе.
Я еще не придумал, как с этим быть, и мне не с кем это обсудить – нет группы энтузиастов, которые были бы против подобного подхода. Если это вдруг кого-то тоже не устраивает – напишите мне (demeliorator в Telegram), буду знать, что я не одинок. Мне это категорически не нравится.

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


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

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

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

С конфетами в файлах много проблем. Если запекать их в образа — конфиг получается 100% статичным. Кубер же предлагает ConfigMap. Неудобство в том, что во многих приложениях нет хотреалоада конфига — приходится костылять сбоку. И получается два процесса (независимых) — доставка конфига и доставка новой версии приложения.


Поэтому мой выбор — пара переменных для определения окружения (prod|dev|test) и все остальное в иерархии в консуле. И это мы еще не затрагивали доставку секретов (oh, shi~..)


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

было уже. Кубер пишет переменные окружения, иногда они пересекаются с конфигурацией приложения… Потом — закономерный ба-бах. Как здесь: https://habr.com/ru/company/flant/blog/510486/

так или иначе — приложение должно уметь в сигналы и перезагрузку конфигурации на лету. а где хранить уже вкусовщина и удобство тулинга.

Кстати о рекламе и о mikrok8s
Только что зашел на один сервер с ubuntu с ходу прямо в командной строке на меня свалилась реклама:



То есть canonical начала продвигать mikrok8s (не путать с minikube) как решение HA и для прода. Хотя сам факт такой рекламы сам по себе оригинален.

ну надо ж им продавать. и обидно что k3s так давно делает, а их всегда как позиционировали как «minikube от canonical» и часто путали

Спасибо за инфу про https://k3s.io. В этом информационном шквале легко пропустить что-то интересное. А это интересное.

Это восхитительно! Они собрались в Питере на конфу и промеж себя решили что Docker умер потому что ни у кого из присутствующих не нашлось что об этом рассказать. Интересно что еще умерло во время этой незабываемой конференции?


Пиши еще

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.
Информация
Дата основания

27 августа 2015

Местоположение

Россия

Сайт

ruvds.com

Численность

11–30 человек

Дата регистрации

18 марта 2016

Блог на Хабре