Ну так тут же дело не в каких-то неправильных алгоритмах, а в нарушение принципов работы с БД, что все выборки и расчеты максимально должны выносится в БД.
Сколько не работал с кодом, обычно существует одно место, которое тормозит больше всего, и это место отвечает за какую-то io работу в духе "сходи забери из базы что-то с кривым запросом". Переписываешь запрос и все работает :)
Даже во всяких cpu-bound задачах довольно часто спасает кеширование или исправление конкретного места.
Зависит от контекста. Всегда люблю приводить в пример перемножение матриц)
Обычно сделать более быстрый (асимптотически) код ничего не стоит.
Зависит от контекста. В вашем примере — не стоит. В каком-то случае это ухудшение читаемости и поддерживаемости кода. В каком-то случае это написание своего более оптимального велосипеда, который потом надо поддерживать.
Я не спорю, что в каких-то случаях вы просто улучшаете точность и все работает, но это явно не 100% и, скорее всего, даже не 50% случаев.
А потом такие "вот сайт тормозит, пользоваться невозможно!!!". Или у людей игра грузится по 10 минут на пустом месте. При чем там наверняка такая же мысль была: Ну насрать, что там в чтении одного мелкого конфига O(n^2), клиент все стерпит. А потом n, внезапно, выросло и все стало плохо.
Нет, "потом" такого не будет. Вы просто взяли и пропустили фразы про бенчмарки, SLA и так далее. Если в SLA не было оговорено условное время загрузки сайта, то что там оговорено было вообще?
Просто обычно программный код имеет столько внутренних нюансов, что замена алгоритма с O(n^2) на более оптимальный может замедлить скорость работы, если это делать в слепую.
Вы игнорируете константу, вы игнорируете наиболее полулярные N и так далее.
Что лучше, что бы у большинства пользователей корзина покупок грузилось секунду, а у кого-то 5 или что бы у всех грузилась по 3 секунды?
Мозги в отрасли работают у всех более-менее, чего-то сверхвыдающегося, в чём нельзя разобраться самому за какое-то время, вообще нет.
Тут секрет кроется в "за какое-то время". Иногда это время это недели или даже месяцы простоя, на что бизнес не может пойти.
У меня на прошлом проекте мой друг был такой "звездой" и когда он уходил, он где-то недели две передавал знания конкретному сотруднику и тот его потом еще месяц-второй дергал по вопросам.
А почему вас это удивляет? Ну, я подозреваю, что данными пользовались, но всяких злобных людей, которые чисто "будем творить зло" на самом деле практически не существует, как эксплотуатировать такие уязвимости то?
Самая страшная идея, которую я подчерпнул из статьи — это тот факт, что вам нужно убить кучу времени на внедрение сложных и правильных KPI, которые по итогу вы даже не сможете как-то внятно отдельно применять, а сможете отслеживать по ним только симптомы.
Причем предлагается это делать для малого бизнеса, где там сидит 2-4 человека и все свои проблемы они и так обычно знают, и для крупного, где симптоматика будет тонуть в формализме и слишком сложной структуре организации.
То есть эта штука, которую очень сложно правильно сделать, которая не дает вам особо никаких важных данных (ведь их можно получить другим способом), и которая с большой долей вероятности будет работать не правильно.
О времени перехода на новую версию influx или docker решение принимает сама компания. Может если оно "работает", то и переходить не будут.
О решении замены API принимает решение поставщик в одномоментном порядке и шансов отказатся у вас нет. Просто вот через полгода сервиса, который вы пользуетесь больше не будет или он будет работать кардинально по другому API.
Представьте, если бы у amazon s3 апи обратно несоместимо менялся каждые 2 года.
В нашем мире никто никому ничего не должен, если не сказано обратное.
Ну так и в статье не написано "GKE ты должен поддерживать обратную совместивость", в статье написано, что вот без обратной совместимости серьезные клиенты не лезут в GKE, а те, что лезут, испытывают вот такие страдания и профита не испытывают.
Просто поддержка стабильного api только год означает, что у вас должен быть выделен человек (а возможно и несколько), который будет постоянно работать с этим API, следить за его изменениями и так далее и работа с этим API будет практически перманентно находится в состоянии модернизации.
Вы не говорите почему он не подходит для бизнес логики, вы говорите, что в нем нельзя использовать инструменты и методы, к которым лично вы привыкли для написания БЛ.
Это не является принципиальным препятствием к написанию БЛ быстро и легко.
Это какая-то странная демагогия. Существуют общепринятые методы и подходы написания бизнес-логики, которые не зависят от языка. Подходы, которые строятся на абстракциях, изолировании бизнес и технической логики, кастомизируемости, SOLID и всех вот этих полезных штуках. Посмотрите сколько паттернов проектирования не получается нормально реализовать на go)
В go у вас сразу бизнес-логика начинает протекать в техническую, для поддержки ряда абстракций приходится городить сторонную кодогенерацию, изолирование не достаточно гибкое и так далее.
А еще go довольно низкоуровневый, среди высокоуровневых.
Разговоры про go-way мне кажутся довольно ироничными, потому что в итоге и ошибки им приходится двигать в нормальную сторону (ведь наступить на проблему с/с++ было необходимо) и зависимости (опять наступили на проблему с/с++).
Идея в том, чтобы отказаться от глобального списка зависимостей на весь проект. Чтобы вместо одного большого package.json у вас в каждом вашем модуле/файле был свой, независимый список зависимостей. Я вижу в этом несколько плюсов.
В этом просто нет ни одного плюса, если у вас одно приложение — у него должен быть список зависимостей. В противном случае появляется хаос в месте, в котором, казалось, наступить на грабли нельзя, но люди (тот же Go) регулярно умудряются.
Как конструктор, в котором можно создавать всякие восьмибитные компьютеры и ваять статуи Иллиданов — безусловно МК вне конкуренции. Как многопользовательская игра — МК рядом не стоял с обалденнейшими социальными механиками Эко.
Ну так это ровно то же, что вы пишите. Выборка данных + расчет производных данных на их основе (преобразование функциями, сумма, вот этот весь треш).
Если вы фильтруете или преобразовываете данные потом на бекенде, то тут что-то немного не так. Иногда это ваша вина, иногда бд.
Ну так тут же дело не в каких-то неправильных алгоритмах, а в нарушение принципов работы с БД, что все выборки и расчеты максимально должны выносится в БД.
Сколько не работал с кодом, обычно существует одно место, которое тормозит больше всего, и это место отвечает за какую-то io работу в духе "сходи забери из базы что-то с кривым запросом". Переписываешь запрос и все работает :)
Даже во всяких cpu-bound задачах довольно часто спасает кеширование или исправление конкретного места.
Зависит от контекста. Всегда люблю приводить в пример перемножение матриц)
Зависит от контекста. В вашем примере — не стоит. В каком-то случае это ухудшение читаемости и поддерживаемости кода. В каком-то случае это написание своего более оптимального велосипеда, который потом надо поддерживать.
Я не спорю, что в каких-то случаях вы просто улучшаете точность и все работает, но это явно не 100% и, скорее всего, даже не 50% случаев.
Нет, "потом" такого не будет. Вы просто взяли и пропустили фразы про бенчмарки, SLA и так далее. Если в SLA не было оговорено условное время загрузки сайта, то что там оговорено было вообще?
Просто обычно программный код имеет столько внутренних нюансов, что замена алгоритма с O(n^2) на более оптимальный может замедлить скорость работы, если это делать в слепую.
Вы игнорируете константу, вы игнорируете наиболее полулярные N и так далее.
Что лучше, что бы у большинства пользователей корзина покупок грузилось секунду, а у кого-то 5 или что бы у всех грузилась по 3 секунды?
Тут секрет кроется в "за какое-то время". Иногда это время это недели или даже месяцы простоя, на что бизнес не может пойти.
У меня на прошлом проекте мой друг был такой "звездой" и когда он уходил, он где-то недели две передавал знания конкретному сотруднику и тот его потом еще месяц-второй дергал по вопросам.
И спишь спокойно ровно до того момента, пока автор либы не впилил во внутрь panic :)
Статья классная, но в ней, к сожалению и опасности автора, слишком много деталей :(
А почему вас это удивляет? Ну, я подозреваю, что данными пользовались, но всяких злобных людей, которые чисто "будем творить зло" на самом деле практически не существует, как эксплотуатировать такие уязвимости то?
У вас есть SLA для команды. Одного разработчика практически невозможно оценить нормально, если он разрабатывает общее ПО, а не собственное.
По идее, самый хороший сборник KPI это SLA, разве нет?
Самая страшная идея, которую я подчерпнул из статьи — это тот факт, что вам нужно убить кучу времени на внедрение сложных и правильных KPI, которые по итогу вы даже не сможете как-то внятно отдельно применять, а сможете отслеживать по ним только симптомы.
Причем предлагается это делать для малого бизнеса, где там сидит 2-4 человека и все свои проблемы они и так обычно знают, и для крупного, где симптоматика будет тонуть в формализме и слишком сложной структуре организации.
То есть эта штука, которую очень сложно правильно сделать, которая не дает вам особо никаких важных данных (ведь их можно получить другим способом), и которая с большой долей вероятности будет работать не правильно.
Так зачем она нужна?
Вы приводите немного некорректные сравнения.
О времени перехода на новую версию influx или docker решение принимает сама компания. Может если оно "работает", то и переходить не будут.
О решении замены API принимает решение поставщик в одномоментном порядке и шансов отказатся у вас нет. Просто вот через полгода сервиса, который вы пользуетесь больше не будет или он будет работать кардинально по другому API.
Представьте, если бы у amazon s3 апи обратно несоместимо менялся каждые 2 года.
Ну так и в статье не написано "GKE ты должен поддерживать обратную совместивость", в статье написано, что вот без обратной совместимости серьезные клиенты не лезут в GKE, а те, что лезут, испытывают вот такие страдания и профита не испытывают.
Просто поддержка стабильного api только год означает, что у вас должен быть выделен человек (а возможно и несколько), который будет постоянно работать с этим API, следить за его изменениями и так далее и работа с этим API будет практически перманентно находится в состоянии модернизации.
Это какая-то странная демагогия. Существуют общепринятые методы и подходы написания бизнес-логики, которые не зависят от языка. Подходы, которые строятся на абстракциях, изолировании бизнес и технической логики, кастомизируемости, SOLID и всех вот этих полезных штуках. Посмотрите сколько паттернов проектирования не получается нормально реализовать на go)
В go у вас сразу бизнес-логика начинает протекать в техническую, для поддержки ряда абстракций приходится городить сторонную кодогенерацию, изолирование не достаточно гибкое и так далее.
А еще go довольно низкоуровневый, среди высокоуровневых.
Разговоры про go-way мне кажутся довольно ироничными, потому что в итоге и ошибки им приходится двигать в нормальную сторону (ведь наступить на проблему с/с++ было необходимо) и зависимости (опять наступили на проблему с/с++).
Я, конечно, все понимаю, но сейчас уже 2020 год и как бы отсутствие менеджмента зависимостей это как отсутствие, например, типа bool в языке.
В этом просто нет ни одного плюса, если у вас одно приложение — у него должен быть список зависимостей. В противном случае появляется хаос в месте, в котором, казалось, наступить на грабли нельзя, но люди (тот же Go) регулярно умудряются.
Ну вот постоянно так, ведь исключительно скриптовые языки старадают от таких проблем? :) Как там борьба с NullPointerException, потомки?
В стиме Эко только для винды. Как так?
Хм… сомнительное утверждения, учитывая моды :)