Здравствуйте, Sheridan, Вы писали:
Pzz>>Поменяли системную инсталляцию Питона, и старые скрипты на Питоне загнулись. S>Очевидно что не все.
Ну внешний, киосеровский, скрипт загнулся. hg-git, который приходит, как стандартный федоровский пакет, тоже загнулся. Так что, скорее все, чем не все.
Здравствуйте, Vetal_ca, Вы писали:
V_>Все надо обосновать. А если есть экономически или технические необоснованные ритуалы, то тут большая вероятность ОКР
Если ты считаешь что оновлять — нецелесообразно то о чом можено вообще разговаривать? Ты ждёшь петуха. Твой выбор. Я предупредил.
V_>>>В стартапе это не работает, пока будут вылизывать, конкуренты перехватят инициативу. S>>Потом стартап становится на ноги, эти проблемы всётаки всплывают и встают стеной и их приходится решать. Один раз, второй... А потом планировать обновления начинают когда два раза штаны уже сгорели. V_>Или не приходится.
Тем которые я видел — приходилось.
V_>У тебя есть хоть приблизительный порядок цифр, сколько ты выиграл и сколько затратил своего и чужого времени? Я уверен, что нет, ибо это вразрез с твоими ритуалами.
Трачу гдето пару недель в год. Выиграл, думаю около месяца аврала "срочногоритнадоделатьаааААА!!11". Сложно посчитать время затраченное на исправление ошибок, которые не случились.
Здравствуйте, Sheridan, Вы писали:
I>> Алё — на этапе разработки ты и представить не можешь, что куда кому взбредет в голову задеплоить. Как ты собираешься проанализировать тысячу-другую возможных комбинаций? S>Достаточно нескольких (2-5) популярных дистрибутивов поддерживать. Всё остальное — "мы не поддерживаем данный дистрибутив но готовы помочь за допплату"
Ты сам то понял что сказал? Вот именно по этому all-in-one предпочтительнее. Кроме того, ты забыл, что вместе с твои софтом будей и другой, у которого могут быть совсем другие предпочтения по версиям.
I>>1. кто куда чего может задеплоить S>В рекомендованные вами дистрибутивы. Почемуто считается нормальным указываать версию мака и виндов для которых приложение работает. Но с линупсом надо обязательно вообще всё!!11.
Неинтересно. Чет заказчик на такое не жаждет соглашаться. Что предложишь, оскорбить его, обмануть, кинуть?
I>>2. какие новые неизвестные баги могут быть привнесеные в какую из десятков или сотен зависимостей? S>Вот это и есть — "закостеневание". Это когда "нетнет, обновляться нинада, уже и так хорошо, а вдруг там монстры??7"
А ты похоже не понял, что такое новый неизвестный баг. Для тебя это может быть известная проблема, типа "чтото не работает", а вот конкретные причины далеко не факт, что сможешь сам выяснить. И соответсвенно баг у тебя булькает, но в багтрекер он не попадёт.
I>>Бинго! И автор либы через месяц сообщает, что он пофиксит, но возможно после того, как выкатит две версии. S>Автор общается, отвечает — ждём. А пока работаем со старой версией.
Похоже, ты уже начал кое что понимать.
I>>А потом заходишь ты в гитхаб либы, и видишь, что эта проблема булькает уже три последних года. S>Два варианта: S>1. Сменить библиотеку.
При смене библиотеки тебе гарантирован длиный-длинный хвост из багов, и сама эта активность мягко говоря не быстрая. И далеко не факт, что есть другая библиотека, которая подходит под твои цели.
S>2. Форкнуть и пофиксить.
Смешно. У тебя похоже экономическая составляющая вообще в рассуждениях не присутствует. С чего ты взял, что влегкую фиксанешь произвольную либу?
S>Почему так? Потому что де-факто эта либа уже не поддерживается никем.
Наоборот.
I>>Похоже, что ты не различаешь "новые известные" и "новые неизвестные". Первые — в баклоге. А вот остальные булькают то тут то там и возможно не скоро попадут в баклог. S>Я про новые неизвестные и пишу. Нашол такой — в багтрекер его.
У тебя багтрекер это синоним "магия". Ну есть баг в том трекере, только например описан он совсем не так, как тебя проявляется. Что дальше?
I>>Это какие то общие слова вида "хорошее лучше плохого". S>В противовес твоему "старое лучше свежего" звучат более логично, не находишь ли?
У тебя в основном "разрабы некомпетентны" и "хорошее лучше плохого". "старое лучше свежего" — это ты забрало поднять забыл. Смотри мой пример про OutOfMemory.
I>>Что бы баг попал в багтрекер, его ктото должен обнаружить, идентифицировать, подготовить описание, стабильную последовательность. До того этот баг будет просто булькать тут и там и подламывать разработку. S>Ты и твоя команда это будут делать. Ты и твоя команда. В рабочем порядке во время запланированного обновления используемых либ на этапе тестирования свежего перед принятием решения "обновляться можно уже сейчас или ещо подождать?".
Выглядит как юношеский максимализм. Я и моя команда и без тебя все это делаем. Зато факт в том, что большинство долгоиграющих проектов такой роскоши позволить себе не могут. Причины самые разные. И только ты один обвиняешь разрабов в некометентности. Тут похоже весь мир живет не по твоим правилам
I>Больше всего проблем доставляют шаред и транзитивные зависимости. Например — обновил ты либу, упали тесты А. Фиксанул. Обновил другую — упали тесты Б. Фиксанул — снова упали А. Фиксанул — упали тесты Б. Обычно здесь надо засаживаться за глубокую отладку что не всегда возможно, писать тикеты и ждать фиксов, искать версии, которые хоть как то совместимы, или гуглить до посинения, пока кто нибудь не подскажет тебе комбинацию. I>Такое, во первых, требует высокой квалификации, во вторых, огромных трудозатрат, и часто абсолютно непредсказуемо по продолжительности. I>И что получаем — высококвалифицированый специалист за конскую зп 100% времени занимается мелочовочкой.
Я так и не понял, как статическая линковка библиотек спасает от сложностей с обновлениями библиотек по сравнению с динамической линковкой. В обоих случаях: обновляешь библиотеки — получаешь сложности, не обновляешь — все хорошо.
P.S. В случае деплоя микросервисов вообще пофиг статическая или динамическая линковка (кроме exe'шника все равно будут файлы и пофиг сколько их копировать, да и делается это скриптом). Грубо говоря
./configure
make
make install DSTDIR=../dst
отработают одинаково независимо от --static у ./configure
IMHO, в таком случае динамическая линковка не дает никаких преимуществ — поэтому используют статику (а вовсе не потому, что это сильно проще).
Pzz>Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними.
Что тебе мешает в монолите поддерживать минимум связей? Более того, разделение на модули придумали еще когда термин микросервисы не существовал (да и сетей почти не было).
Микросервисы решают 2 задачи: делают возможным реализацию приложения, которому не хватает ресурсов одной машины (гугл/фейскнига) и делают возможным разработку приложения, которым занимаются разные команды с разными дедлайнами, задачам и приоритетами (тут достаточно договориться о протоколе обмена данными и времени реализации изменений, а также поддержки легаси — остальное в каждой команде решают независимо, а вот запихать это в один монолит — возникнет неразруливаемый срач с выяснением у кого длиннее).
Здравствуйте, Ikemefula, Вы писали:
S>>Достаточно нескольких (2-5) популярных дистрибутивов поддерживать. Всё остальное — "мы не поддерживаем данный дистрибутив но готовы помочь за допплату" I> Ты сам то понял что сказал?
Не только понял но и даже знаю что в таких ситуациях делать.
I>Вот именно по этому all-in-one предпочтительнее. Кроме того, ты забыл, что вместе с твои софтом будей и другой, у которого могут быть совсем другие предпочтения по версиям.
Решение подсказать? Нужно свой софт писать так, чтобы использовал те версии либ, которые есть в дистрибутиве. А если нет такой либы вообще, то в свой репозиторий складывать в виде зависимости к пакету с твоим софтом. А заказчику давать линк на свою репу, которую надо подключить ему к дистрибутиву чтобы потом стандартными средствами установить ваш софт.
I>>>1. кто куда чего может задеплоить S>>В рекомендованные вами дистрибутивы. Почемуто считается нормальным указываать версию мака и виндов для которых приложение работает. Но с линупсом надо обязательно вообще всё!!11. I>Неинтересно. Чет заказчик на такое не жаждет соглашаться. Что предложишь, оскорбить его, обмануть, кинуть?
Если заказчик платит деньги чтобы ваш софт появился в его дистрибутиве то вам нужно опакетить ваш софт для того дистрибутива.
I>>>2. какие новые неизвестные баги могут быть привнесеные в какую из десятков или сотен зависимостей? S>>Вот это и есть — "закостеневание". Это когда "нетнет, обновляться нинада, уже и так хорошо, а вдруг там монстры??7" I>А ты похоже не понял, что такое новый неизвестный баг. Для тебя это может быть известная проблема, типа "чтото не работает", а вот конкретные причины далеко не факт, что сможешь сам выяснить. И соответсвенно баг у тебя булькает, но в багтрекер он не попадёт.
У меня значит получалось выяснить что и почему не работает (и это включало в себя например сборку подправленного постгреса с дополнительным дебаг-логом). А у настоящих тру-программистов-профессионалов лапки.
I>>>Бинго! И автор либы через месяц сообщает, что он пофиксит, но возможно после того, как выкатит две версии. S>>Автор общается, отвечает — ждём. А пока работаем со старой версией. I>Похоже, ты уже начал кое что понимать.
Я изначально к этому вёл, но у тебя закостенение "шеридан-долбоклюй-непрофессионал" и это мешает тебе воспринимать то что я пишу.
I>>>А потом заходишь ты в гитхаб либы, и видишь, что эта проблема булькает уже три последних года. S>>Два варианта: S>>1. Сменить библиотеку. I> При смене библиотеки тебе гарантирован длиный-длинный хвост из багов, и сама эта активность мягко говоря не быстрая. И далеко не факт, что есть другая библиотека, которая подходит под твои цели. S>>2. Форкнуть и пофиксить. I> Смешно. У тебя похоже экономическая составляющая вообще в рассуждениях не присутствует. С чего ты взял, что влегкую фиксанешь произвольную либу?
А я говорил что это будет легко? Я сказал что если либа не поддерживается больше, то выполнить один из этих двух пунктов тупо придётся. Ты будешь с этим спорить? Ты правда программист?
S>>Почему так? Потому что де-факто эта либа уже не поддерживается никем. I>Наоборот.
Ну то есть никто на протяжениии нескольких лет не чинит баги означает что либа полностью и адекватно поддерживается автором?
Г — лоГика.
I>>>Похоже, что ты не различаешь "новые известные" и "новые неизвестные". Первые — в баклоге. А вот остальные булькают то тут то там и возможно не скоро попадут в баклог. S>>Я про новые неизвестные и пишу. Нашол такой — в багтрекер его. I>У тебя багтрекер это синоним "магия". Ну есть баг в том трекере, только например описан он совсем не так, как тебя проявляется. Что дальше?
Опиши так как у тебя проявляется. Надеюсь ты сам понимаешь, что это поможет автору баг исправить.
I>>>Это какие то общие слова вида "хорошее лучше плохого". S>>В противовес твоему "старое лучше свежего" звучат более логично, не находишь ли? I>У тебя в основном "разрабы некомпетентны" и "хорошее лучше плохого". "старое лучше свежего" — это ты забрало поднять забыл. Смотри мой пример про OutOfMemory.
А как ещо назвать разрабов, которые говорят "если на баг никто не отвечает, то ты неправ что либа не поддерживается автором а наоборот."?
I>>>Что бы баг попал в багтрекер, его ктото должен обнаружить, идентифицировать, подготовить описание, стабильную последовательность. До того этот баг будет просто булькать тут и там и подламывать разработку. S>>Ты и твоя команда это будут делать. Ты и твоя команда. В рабочем порядке во время запланированного обновления используемых либ на этапе тестирования свежего перед принятием решения "обновляться можно уже сейчас или ещо подождать?". I>Выглядит как юношеский максимализм. Я и моя команда и без тебя все это делаем.
Если вы и так это всё делаете, то какого Иакова вы мне тут мозги полоскаете? Так и напиши "да, мы этим занимаемся, но по мере возможностей". И вопросов не будет. Срач ради срача?
I>Зато факт в том, что большинство долгоиграющих проектов такой роскоши позволить себе не могут. Причины самые разные. И только ты один обвиняешь разрабов в некометентности. Тут похоже весь мир живет не по твоим правилам
Причин две: лень и некомпетентность. Я бы добавил третью: недальновидность. Но программисту бизнес-бабки-платит-я-кодю этого не понять.
Здравствуйте, CreatorCray, Вы писали:
S>>Нууу вообщето чаще всего да. CC>У тебя на машине только одна единственная прога стоит?
А если ты про то где я щас работаю, то у нас стандартная установка продукта — шесть машин. Точнее, одна, три или шесть и больше. Как правило это виртуалки.
Здравствуйте, Reset, Вы писали:
R>Микросервисы решают 2 задачи: делают возможным реализацию приложения, которому не хватает ресурсов одной машины (гугл/фейскнига) и делают возможным разработку приложения, которым занимаются разные команды с разными дедлайнами, задачам и приоритетами (тут достаточно договориться о протоколе обмена данными и времени реализации изменений, а также поддержки легаси — остальное в каждой команде решают независимо, а вот запихать это в один монолит — возникнет неразруливаемый срач с выяснением у кого длиннее).
Бывает например одна команда разработчиков пишет код для разных дочек компании. Причем часть компании может быть публичной. Тут микросервисы хорошо ложаться. Монолит конечно попроще начинать.
Здравствуйте, Pzz, Вы писали:
Pzz>>>Поменяли системную инсталляцию Питона, и старые скрипты на Питоне загнулись. S>>Очевидно что не все. Pzz>Ну внешний, киосеровский, скрипт загнулся. hg-git, который приходит,
Так он ещё и установлен был мимо федоровских репозиториев что ли? Чего ты тогда ждал в таком случае, на что надеялся?
Pzz>как стандартный федоровский пакет, тоже загнулся. Так что, скорее все, чем не все.
2 != все.
Здравствуйте, Hobbes, Вы писали:
H>Каких непостижимых фич? Итераторы блин непостижимые? Перегрузка оператора сравнения это непостижимо? Без перегрузки оператора сравнения зачастую нельзя использовать тип для индексирования map.
ЧСХ, я сразу написал что в гошечке нет ООП и потому надо закапывать. Но пытаются из-за этого закопать меня
Здравствуйте, Sheridan, Вы писали:
I>>Бывает трудозатратно и на одну версию перейти. Что выберешь — либа кидает OutOfMemory на DrawLine, если координаты слишком близко, или загрузка ядер на 5% при параллельной загрузке? S>Написать баг авторам либы и не переходить пока он не будет починен.
Вот примерно так мы от буста отказались в своё время. Оказалось что быстрее самим написать то, что нам оттуда надо было чем дождаться когда они починят не сломав что нить другое. Своя имплементация ещё и заметно быстрее получилась.
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Reset, Вы писали:
R>Я так и не понял, как статическая линковка библиотек спасает от сложностей с обновлениями библиотек по сравнению с динамической линковкой. В обоих случаях: обновляешь библиотеки — получаешь сложности, не обновляешь — все хорошо.
При динамической линковке у тебя либы (или часть либ) могут вместе с дистрибутивом обновиться. И ты этим не очень-то управляешь.
Здравствуйте, CreatorCray, Вы писали:
S>> Когда в команде раздрай и разные участки проекта требуют разных версий одной и той же библиотеки. CC>Ну а кроме твоего проекта на машине у кастомера вообще больше ничего не присутствует, да?
Здравствуйте, CreatorCray, Вы писали:
НС>>Да. Про контейнеры слышал? CC>Предлагаешь каждую софтину запихивать в контейнер? CC>А не дороговато ли выйдет?
Ты штооооа!11 Это же новомодный тренд!!11 Всё в контейнеры, в кубы!
Как по мне — контейнеры нужны в паре случаев всего:
1. Для разработки, чтобы не захламлять рабочую машину всевозможными кроликами, постгрями, мускулями итд
2. Когда нужно уметь разворачивать мощности при возрастании нагрузки и сворачивать обратно потом (aws тотже)
В остальных случаях нужно критически подходить к идее контейниризации.
Здравствуйте, Pzz, Вы писали:
Pzz>Я не историк, мне трудно сказать, кто появился раньше.
О микросервисах всерьез заговорили в 2011, первые оисания реальных архитектур появились в 2012. Первый релиз докера — 2013. Формально, конечно, позже, но интервал слишком мал чтобы именно микросервисы послужили причиной его появления, на что усиленно намекает Шеридан, по обыкновению своему слишком картину примитивизируя.
Pzz>Но в принципе, "микросервисы" — это модное слово для давно известной идеи.
Не совсем. Именно микросервисы как идея — довольно свежая вещь. Другое дело что в реальности обычно идеальных микросервисов нет, и выстраивается вполне классическая SOA архитектура с некоторыми нюансами.
Тут еще надо понимать, что микросервисы сейчас стали популярны не столько из-за исходной идеи, сколько из-за того что вокруг них сформировалась экосистема, т.н. cloud native решения, которые позволяют разумными услилиями строить очень сложные high load решения.
А проблема тут в том, что вокруг микросервисов развелось огромное количество мифов и ритуалов, а по сути многие просто не понимают в чем их суть. Тут рядом эпичный топик
Здравствуйте, Reset, Вы писали:
R>Микросервисы решают 2 задачи: делают возможным реализацию приложения, которому не хватает ресурсов одной машины (гугл/фейскнига)
И чем мешает это сделать не микросервисам?
R> и делают возможным разработку приложения, которым занимаются разные команды с разными дедлайнами, задачам и приоритетами
А делают возможным это они за счет того, что ...
Разбиение большой системы на малые части в очень значительной степени снижает сложность системы
Алё — на этапе разработки ты и представить не можешь, что куда кому взбредет в голову задеплоить. Как ты собираешься проанализировать тысячу-другую возможных комбинаций?
