Здравствуйте, Sheridan, Вы писали:
S>Сначала были монолиты. Чтобы решить проблему используемых при разработке либ (не всем дано вовремя обновляться, да и лень) — придумали микросервисы.
Микросервисы придумали, чтобы разбить большую систему на небольшие части, связанные интерфейсами, но не доступом ко внутренностям. Собственно, это — та же идея, что и ООП, но на новый лад.
Разбиение большой системы на малые части в очень значительной степени снижает сложность системы, и делает ее подвластной человеческому разуму.
S>Спустя какоето время поняли что микросервисы решили только проблему разработки и переместили проблему зависимостей на deploy-time. Поэтому придумали изоляцию (докер)
Докер, скорее, решает проблему "быстро свинтить для программы привычное ей окружение из общедоступных запчастей".
S>А теперь и докер перестал устраивать. Поэтому с одной стороны появляются языки, где секут плетями за "не такой" код и либы вкомпиливаются в бинарник (сабж). А с другой стороны пилят кубернетес чтобы хоть както управлять контейнерами и их версиями.
В Go развелось статических анализаторов не потому, что мир Go — это царство фашизма, а потому, что могут. Go настолько простой язык, что его легко статически анализировать. Плюс, полноценный синтаксический анализатор Go является частью системной библиотеки, причем это не какой-то там анализатор для пользователей, а ровно тот же самый, который использует компилятор. Поэтому и анализируют. C++ тоже бы анализировали, но это в разы сложнее, и анализаторы плохо работают.
S>А казалось бы — обновляйтесь вовремя и никаких проблем.
Народ не обновляется не потому, что лень, а потому, что неизвестно, какие проблемы принесет новое обновление. Увы, интерфейс остается синтаксически тем же, а поведение под капотом меняется. И иногда эти изменения неожиданным образом просачиваются на поверхность. Причем это всегда происходит не вовремя.
Здравствуйте, vsb, Вы писали:
Pzz>>Я так рассказываю, как будто это то, что есть. А хорошее оно или плохое, пусть каждый решает в меру своих потребностей.
vsb>Забавный факт. В жаве кажется до 8 версии substring работал именно так: был один общий массив символов и offset/length. Т.е. маленькая строка могла внутри держать массив на мегабайт, к примеру. Но потом поменяли на копирование.
Это очень такое Сишное поведение. Т.е., человек, для которого привычен Си, другого бы и не ждал. Но Си вырабатывает привычку следить за памятью, если для человека это непривычно, и для него строка — это строка, т.е., последовательность символов, а не место в памяти, ему очень трудно это понять.
Здравствуйте, night beast, Вы писали:
S>>Это тоже способ уйти от необходимости обновлять у себя используемое. NB>макс, давай ты не будешь фантазировать о том, почему ушли от монолитов.
Ну расскажи ты.
S>>А казалось бы — обновляйтесь вовремя и никаких проблем. NB>не просто обновляйся, но и заставь всех клиентов обновляться. причем на ту версию, что поставилась в твоей системе. NB>в реальной жизни это почему-то не работает
Причины я уже назвал
Здравствуйте, Sheridan, Вы писали:
S>>>Это тоже способ уйти от необходимости обновлять у себя используемое. NB>>макс, давай ты не будешь фантазировать о том, почему ушли от монолитов. S>Ну расскажи ты.
Здравствуйте, Pzz, Вы писали: S>>Сначала были монолиты. Чтобы решить проблему используемых при разработке либ (не всем дано вовремя обновляться, да и лень) — придумали микросервисы. Pzz>Микросервисы придумали, чтобы разбить большую систему на небольшие части, связанные интерфейсами, но не доступом ко внутренностям. Собственно, это — та же идея, что и ООП, но на новый лад.
Такое себе оправдание. Тот же private в плюсах замечательно ограничивает.
Pzz>Разбиение большой системы на малые части в очень значительной степени снижает сложность системы, и делает ее подвластной человеческому разуму.
Шило на мыло. Сложность проекта в целом от этого только возросла.
S>>Спустя какоето время поняли что микросервисы решили только проблему разработки и переместили проблему зависимостей на deploy-time. Поэтому придумали изоляцию (докер) Pzz>Докер, скорее, решает проблему "быстро свинтить для программы привычное ей окружение из общедоступных запчастей".
Не опровергает моё высказывание а скорее подтверждает.
S>>А теперь и докер перестал устраивать. Поэтому с одной стороны появляются языки, где секут плетями за "не такой" код и либы вкомпиливаются в бинарник (сабж). А с другой стороны пилят кубернетес чтобы хоть както управлять контейнерами и их версиями. Pzz>В Go развелось статических анализаторов не потому, что мир Go — это царство фашизма, а потому, что могут. Go настолько простой язык, что его легко статически анализировать. Плюс, полноценный синтаксический анализатор Go является частью системной библиотеки, причем это не какой-то там анализатор для пользователей, а ровно тот же самый, который использует компилятор. Поэтому и анализируют. C++ тоже бы анализировали, но это в разы сложнее, и анализаторы плохо работают.
Опять же, не опровергает то что я написал.
S>>А казалось бы — обновляйтесь вовремя и никаких проблем. Pzz>Народ не обновляется не потому, что лень, а потому, что неизвестно, какие проблемы принесет новое обновление. Увы, интерфейс остается синтаксически тем же, а поведение под капотом меняется. И иногда эти изменения неожиданным образом просачиваются на поверхность. Причем это всегда происходит не вовремя.
Я гдето писал "обновляйте сразу прод!"?
К тому же:
1. Дистрибутивы без тестов не выпускаются.
2. Проект тоже без тестов релизиться не должен. В том числе и без тестов на обновлённом дистрибутиве.
В итоге у кастомера всё должно работать сразу. Но из-за того что на второй пункт разработчики считают приемлемым забить — и возникают проблемы.
Здравствуйте, night beast, Вы писали:
S>>>>Это тоже способ уйти от необходимости обновлять у себя используемое. NB>>>макс, давай ты не будешь фантазировать о том, почему ушли от монолитов. S>>Ну расскажи ты. NB>Pzz уже изложил
Ни разу не опроверг а местами даже подтвердил.
Здравствуйте, Sheridan, Вы писали:
CC>>Ага, ага. Это примерно как люди изобрели туалетную бумагу и всякие там биде потому что не хватает опыта/знаний/желания уметь пальцем жопу вытирать. S>Нет.
Да, Шеридан, да.
S>Нет упоминания гитлера, геноцида и человекоедения. Ну чтобы нагнетать так нагнетать.
Ты сам справился
S>Нууу вообщето чаще всего да.
У тебя на машине только одна единственная прога стоит?
Здравствуйте, Sheridan, Вы писали:
Pzz>>Микросервисы придумали, чтобы разбить большую систему на небольшие части, связанные интерфейсами, но не доступом ко внутренностям. Собственно, это — та же идея, что и ООП, но на новый лад. S>Такое себе оправдание. Тот же private в плюсах замечательно ограничивает.
В C++ к тебе придет мененджер и скажет, "твой private мешает выпустить завтра релиз, который мы должны были выпустить месяц назад", и ты поморщишься, и заменишь его на public. А поди попробуй сделай такое в микросервисе.
Pzz>>Разбиение большой системы на малые части в очень значительной степени снижает сложность системы, и делает ее подвластной человеческому разуму. S>Шило на мыло. Сложность проекта в целом от этого только возросла.
Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними.
S>>>Спустя какоето время поняли что микросервисы решили только проблему разработки и переместили проблему зависимостей на deploy-time. Поэтому придумали изоляцию (докер) Pzz>>Докер, скорее, решает проблему "быстро свинтить для программы привычное ей окружение из общедоступных запчастей". S>Не опровергает моё высказывание а скорее подтверждает.
Из того, что яйцами можно закидывать плохих артистов и политиков не следует, что изначальное предназначение яиц какое-либо другое, чем делать яичницу и омлет.
S>1. Дистрибутивы без тестов не выпускаются. S>2. Проект тоже без тестов релизиться не должен. В том числе и без тестов на обновлённом дистрибутиве. S>В итоге у кастомера всё должно работать сразу. Но из-за того что на второй пункт разработчики считают приемлемым забить — и возникают проблемы.
Сколько раз я видел, как во вполне оттестированном дистрибутиве линуха обновление какой-нибудь библиотеки ломало чего-нибудь в какой-нибудь программе.
Здравствуйте, CreatorCray, Вы писали:
S>>Нууу вообщето чаще всего да. CC>У тебя на машине только одна единственная прога стоит?
Все которые стоят — все работают. Некоторые на гошечке, некоторые на плюсах, нектороые на питоне ну и на других языках тоже куча. И с либами и вкомпиленое. Думаю, все варианты есть.
ЧСХ, всё работает. Наверное потому что код пишут и сопровождают те, кто видит пользу в отслеживании того, что они используют в своём коде.
Pzz>>>Микросервисы придумали, чтобы разбить большую систему на небольшие части, связанные интерфейсами, но не доступом ко внутренностям. Собственно, это — та же идея, что и ООП, но на новый лад. S>>Такое себе оправдание. Тот же private в плюсах замечательно ограничивает.
Pzz>В C++ к тебе придет мененджер и скажет, "твой private мешает выпустить завтра релиз, который мы должны были выпустить месяц назад", и ты поморщишься, и заменишь его на public. А поди попробуй сделай такое в микросервисе.
И что мне помешает сделать интерфейс? Законы физики? Ровно также вытащу наружу, раз пришол руководитель и просит меня сделать свою работу. Узнаю конечно причины и если они существенны/справедливы — вытащу.
Pzz>>>Разбиение большой системы на малые части в очень значительной степени снижает сложность системы, и делает ее подвластной человеческому разуму. S>>Шило на мыло. Сложность проекта в целом от этого только возросла. Pzz>Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними.
Связи не изменились. Изменяется принцип установки связей. Этот новый принцип требует бОльших телодвижений. Например при переходе от вызова метода объекта к вызову метода об http api сервиса нужно встроить вдобавок обработку ошибок (та-же 404), поддержать версионность API. Как минимум!
S>>>>Спустя какоето время поняли что микросервисы решили только проблему разработки и переместили проблему зависимостей на deploy-time. Поэтому придумали изоляцию (докер) Pzz>>>Докер, скорее, решает проблему "быстро свинтить для программы привычное ей окружение из общедоступных запчастей". S>>Не опровергает моё высказывание а скорее подтверждает. Pzz>Из того, что яйцами можно закидывать плохих артистов и политиков не следует, что изначальное предназначение яиц какое-либо другое, чем делать яичницу и омлет.
Ты прав, докер решает много "проблем". Но родился он именно для необходимости изоляции процессов. А изоляция понадобилась потому что каждый пляшет как хочет. Потому что два соседних отдела могут в каждый в своём микросервисе пользовать разные версии одной и той же либы. И чем больше контора тем больше именно эта причина выходит на первое место.
S>>1. Дистрибутивы без тестов не выпускаются. S>>2. Проект тоже без тестов релизиться не должен. В том числе и без тестов на обновлённом дистрибутиве. S>>В итоге у кастомера всё должно работать сразу. Но из-за того что на второй пункт разработчики считают приемлемым забить — и возникают проблемы. Pzz>Сколько раз я видел, как во вполне оттестированном дистрибутиве линуха обновление какой-нибудь библиотеки ломало чего-нибудь в какой-нибудь программе.
Вспомни хотя бы два раза и озвучь период воспоминаний.
Здравствуйте, Pzz, Вы писали:
Pzz>Это очень такое Сишное поведение. Т.е., человек, для которого привычен Си, другого бы и не ждал. Но Си вырабатывает привычку следить за памятью, если для человека это непривычно, и для него строка — это строка, т.е., последовательность символов, а не место в памяти, ему очень трудно это понять.
Странно бвло бы слышать о программиста что он не понимает что для строки нужен кусочек памяти где она хранится. Более того, человек, который хотя бы немного интересуется чуть больше, не понимал хотя бы на начальном уровне как по идее должна храниться строка. Это простая задача на декомпозицию.
Здравствуйте, Sheridan, Вы писали:
Pzz>>В C++ к тебе придет мененджер и скажет, "твой private мешает выпустить завтра релиз, который мы должны были выпустить месяц назад", и ты поморщишься, и заменишь его на public. А поди попробуй сделай такое в микросервисе. S>И что мне помешает сделать интерфейс? Законы физики? Ровно также вытащу наружу, раз пришол руководитель и просит меня сделать свою работу. Узнаю конечно причины и если они существенны/справедливы — вытащу.
Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.
Pzz>>Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними. S>Связи не изменились. Изменяется принцип установки связей. Этот новый принцип требует бОльших телодвижений. Например при переходе от вызова метода объекта к вызову метода об http api сервиса нужно встроить вдобавок обработку ошибок (та-же 404), поддержать версионность API. Как минимум!
Программисты очень любят делать лишние связи и очень не любят думать головой. Если есть выбор, сделать 3 лишние связи или полчаса подумать головой, как без этих лишних связей обойтись, в программе появятся 3 лишние связи.
В то же время, программисты ленивы, как коты, страдающие ожирением. Если для того, чтобы сделать связь, надо сделать интерфейс и обложить его тестами, программист скорее обойдется без лишних связей.
Поэтому одной только инкапсуляции недостаточно, чтобы сложность проекта не разрасталась. Надо еще, чтобы превращение приватного в публичное было действительно муторным и трудоемким мероприятием.
S>Ты прав, докер решает много "проблем". Но родился он именно для необходимости изоляции процессов. А изоляция понадобилась потому что каждый пляшет как хочет. Потому что два соседних отдела могут в каждый в своём микросервисе пользовать разные версии одной и той же либы. И чем больше контора тем больше именно эта причина выходит на первое место.
С изоляцией процессов прекрасно справлялся chroot, придуманный еще в библейские времена. Докер решает проблему, как заполнить то место, куда chroot, тем, что процессу надо для жизни, и при этом не умереть от натуги.
Pzz>>Сколько раз я видел, как во вполне оттестированном дистрибутиве линуха обновление какой-нибудь библиотеки ломало чего-нибудь в какой-нибудь программе. S>Вспомни хотя бы два раза и озвучь период воспоминаний.
Слушай, я в полном соответствии с теорией Фрейда эти травмирующие воспоминание немедленно вытесняю после того, как они перестают быть актуальными.
Здравствуйте, Sheridan, Вы писали:
S>Странно бвло бы слышать о программиста что он не понимает что для строки нужен кусочек памяти где она хранится. Более того, человек, который хотя бы немного интересуется чуть больше, не понимал хотя бы на начальном уровне как по идее должна храниться строка. Это простая задача на декомпозицию.
Ну при всем при том, большинство программистов вряд ли понимают, как устроен внутри float. Чем строка-то хуже?
Строка — это очень фундаментальный тип данных, значение которой очень удобно считать тем словом (возможно неприличным), которое туда записано, а не указателем на какой-то кусок памяти, в которую можно и сбоку подлезть, и прямо перед носом изменить значение некоторых байт.
Возможность относиться к строкам, как к указателю на память, очень, конечно, помогает немного локально оптимизировать кодогенерацию, но очень при том усложняет понимание кода в целом. Который, если уж он работает со строками, и, например, синтаксически их разбирает, скорее всего и без того сложный.
Здравствуйте, Sheridan, Вы писали:
Pzz>>Сколько раз я видел, как во вполне оттестированном дистрибутиве линуха обновление какой-нибудь библиотеки ломало чего-нибудь в какой-нибудь программе. S>Вспомни хотя бы два раза и озвучь период воспоминаний.
О, вспомнил! Ты, таки, заставил меня пережить эту травму еще один раз.
Федора, как известно, выдристала из дистрибутива Питон 2.x. Вернее, не то, чтобы совсем выдристала, но он теперь deprecated, и поддерживается так, чтобы никому не захотелось им пользоваться.
В результате, они сломали мой любимий плагин hg-git, который превращает mercurial в git, но с пользовательским интерфейсом mercurial'а, гораздо более гуманным, чем у git'а, и сломали проприетериальный (я правильно сказал?) драйвер от принтеров kyocera, который теперь не печатает, а о чем-то вечно думает, на 100% загружая доставшееся ему ядро процессора).
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Sheridan, Вы писали:
Pzz>>>В C++ к тебе придет мененджер и скажет, "твой private мешает выпустить завтра релиз, который мы должны были выпустить месяц назад", и ты поморщишься, и заменишь его на public. А поди попробуй сделай такое в микросервисе. S>>И что мне помешает сделать интерфейс? Законы физики? Ровно также вытащу наружу, раз пришол руководитель и просит меня сделать свою работу. Узнаю конечно причины и если они существенны/справедливы — вытащу. Pzz>Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.
Твои слова подтверждают твою мысль что и там и там сменить доступ к интерфейсу можно, если есть доступ к исходникам. А делать ли это прямо сейчас зависит от подвешенности языка а не от ограничений языка/мотодологии.
Pzz>>>Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними. S>>Связи не изменились. Изменяется принцип установки связей. Этот новый принцип требует бОльших телодвижений. Например при переходе от вызова метода объекта к вызову метода об http api сервиса нужно встроить вдобавок обработку ошибок (та-же 404), поддержать версионность API. Как минимум! Pzz>Программисты очень любят делать лишние связи и очень не любят думать головой. Если есть выбор, сделать 3 лишние связи или полчаса подумать головой, как без этих лишних связей обойтись, в программе появятся 3 лишние связи.
Это справедливо и при работе с библиотекой и при работе с http api. Зачем это тут? Меня заболтать?
Pzz>В то же время, программисты ленивы, как коты, страдающие ожирением.
Я так и сказал сразу. Ты опять подтвердил мои слова.
Pzz>Поэтому одной только инкапсуляции недостаточно, чтобы сложность проекта не разрасталась. Надо еще, чтобы превращение приватного в публичное было действительно муторным и трудоемким мероприятием.
Это тоже не спасёт от дурака. Правильно делать так: не пускать туда дурака.
S>>Ты прав, докер решает много "проблем". Но родился он именно для необходимости изоляции процессов. А изоляция понадобилась потому что каждый пляшет как хочет. Потому что два соседних отдела могут в каждый в своём микросервисе пользовать разные версии одной и той же либы. И чем больше контора тем больше именно эта причина выходит на первое место. Pzz>С изоляцией процессов прекрасно справлялся chroot, придуманный еще в библейские времена. Докер решает проблему, как заполнить то место, куда chroot, тем, что процессу надо для жизни, и при этом не умереть от натуги.
Это както противоречит тому что докер появился после микросервисов и туда начали запихивать микросервисы для изоляции?
Pzz>>>Сколько раз я видел, как во вполне оттестированном дистрибутиве линуха обновление какой-нибудь библиотеки ломало чего-нибудь в какой-нибудь программе. S>>Вспомни хотя бы два раза и озвучь период воспоминаний. Pzz>Слушай, я в полном соответствии с теорией Фрейда эти травмирующие воспоминание немедленно вытесняю после того, как они перестают быть актуальными.
Скажу тогда тебе я: подобное случается достаточно редко при правильном управлении жизнью ОС. Настолько редко что считается форсмажором.
Здравствуйте, Pzz, Вы писали:
Pzz>Ну при всем при том, большинство программистов вряд ли понимают, как устроен внутри float.
Я про некомпетентность и лень как раз тут и пишу.
Здравствуйте, Pzz, Вы писали:
Pzz>В результате, они сломали мой любимий плагин hg-git, который превращает mercurial в git, но с пользовательским интерфейсом mercurial'а, гораздо более гуманным, чем у git'а, и сломали проприетериальный (я правильно сказал?) драйвер от принтеров kyocera, который теперь не печатает, а о чем-то вечно думает, на 100% загружая доставшееся ему ядро процессора).
Как и следовало ожидать:
1. Довольно странная тулза, которой пользуются два с половиной человека и ты.
2. Проприетарный драйвер, у которого нет исходников и на обновление которого забили программисты этого драйвера.
Здравствуйте, Shmj, Вы писали:
S>Вот, кстати, что на счет Go?
S>Из коробки компилится под множество платформ. Какие минусы в сравнении с тем же C++?
Почему бы тебе просто не попробовать его как и раст? Напиши пару простых вещей и всё. Зачем плодить одни и те же темы?
Здравствуйте, Sheridan, Вы писали:
S>Как и следовало ожидать: S>1. Довольно странная тулза, которой пользуются два с половиной человека и ты. S>2. Проприетарный драйвер, у которого нет исходников и на обновление которого забили программисты этого драйвера.
Не, ну в изначальном условии не было требования выбирать из числа программ, которые ты лично одобрил.
Надо сказать, что опенсорсный CUPS пытается опознать мой принтер и на нем печатать. Только у него это не очень-то получается. Вернее, получается печатать белые листы. Что, конечно, очень полезно в плане экологии, экономии бумаги и повышения секретности в делопроизводстве, но не совсем совпадает с целями, с которыми я этот принтер купил.
Помогает руками сочетать опенсорсный CUPS с неопенсорсным PDL-файлом, который можно, при некоторой сноровке, выдернуть из инсталлятора неопенсорсного драйвера. Что само по себе удивительно, потому, что мой принтер прекрасно поддерживает совершенно стандартные IPP, PDF и PostScript, и, казалось бы, CUPS'у больше ничего не должно быть нужно.
Здравствуйте, Sheridan, Вы писали:
Pzz>>Ну при всем при том, большинство программистов вряд ли понимают, как устроен внутри float. S>Я про некомпетентность и лень как раз тут и пишу.
Это не некомпетентность. Просто float — это очень хорошо инкапсулированный тип. Никому особо и не надо знать, как он внутри устроен, он прекрасно реализует заявленный интерфейс, независимо от своего внутреннего устройства.
