Так в том и проблема, что для пользовательских запросов нет надёжного способа сказать, какой будет план, пока уже жареные петухи не начнут прицеливаться. Там уже анализ идёт на боевых данных и серверах, благо индексы не меняют сути запроса. Даже на каждом сервере в итоге могут быть немного разное индексирование, как раз из-за конкретного распределения данных на шарде.
Но вон индексацию по блобам jsonb у нас внутри как-то исследовали и выпустили внутреннюю ноту, чтоб ни-ни — jsonb только в проекцию, но не в предикаты. Подробности найти тяжело, но видимо тогда совсем там плохо было.
Я говорил чуть про другое — когда из десяти слоёв undo при добавлении ещё одного слоя получается снова десять (или меньше), просто в каком-нибудь слое N будет лежат результат объединения слоёв N и N-m. Именно такая операция будет деструктивна к undo, зато позволит сэкономить на вычислениях.
"Почему" — видимо, потому, что действует Спираль молчания, помноженная на желание переплюнуть остальных.
Как-то так: Alice: я усыновила трёх африканских детей! Bob: пфф-ф, а я усыновил уже четырёх, и собираюсь усыновить пятого Alice идёт оформлять ещё три свидетельства на усыновление
А чем принципиально та ситуация вверху отличается от "вот у нас есть WHERE по этим колонкам"? И то, и другое, с точки зрения базы, одинаковой важности запросы. Ну может один чаще повторяется — и то не уверен. Полностью статичный WHERE чаще всего используются внутренним кодом, а намного чаще кому-то "просто спроситьпосмотреть", и во многих системах с RDBMS фильтрация позволяет добавлять свои критерии в некоторых пределах.
Да, реальное распределение данных в создании индекса — не единственный момент, который нужно учитывать, его всегда нужно умножать на условный вес запросов по таким данным.
Я против этой идеи и возражал — там в цитате "по пользовательским данным", а надо — "по пользовательским запросам". Такой вариант точнее, но даже если запросы динамически делают пользователи, лучший индекс будет учитывать не просто по каким полям фильтруют, но ещё и как данные реально лежат, и по каким критериям их дискриминировать.
Ломка данных опциональна, на самом деле. Например для того же рисования есть порог, при котором несколько "слоёв" имеет смысл объединить, чтобы не гонять доступ к пикселям через совсем уж толстые слои обёрток — потому что каждый слой будет требовать вычислительных расходов на каждую операцию доступа.
Если у вас индексы внезапно начинают формироваться динамически на основнаии пользовательских данных
Позвольте, но на основании чего ещё их формировать? Цель создания индекса — это ускорить некоторый класс запросов. И если после создания индекса оказывается, что на реальных данных дискриминатор индекса производит такие же вложенные циклы, как если бы этого индекса совсем не было — то индекс не нужен, совсем — даже если с точки зрения логики для этого типа фактов индексирование именно по этому полю выглядит логично. Например, если у вас в таблице события есть индекс по типу события — ну, логично ведь? Потом оказывается, что все сто миллионов событий на практике имеют тип "день рождения" (и других событий там вообще нет) — то вы с этого индекса поимеете только небольшое замедление при добавлении новой строки события (на пересчёт индекса).
ну смотрите, у вас есть копирование. Причем картинки, тяжеловесного объекта. Вы всерьез считаете, что это всегда хорошо?
Так ведь никто и не заставляет сразу же делать копирование. Для широкого класса операций (в том числе на картинках) можно результатом mirrored() вернуть нечnо, что ведёт себя как отзеркаленная картинка, но на деле просто осуществляет трансляцию координат из оригинального изображения при доступе. А например image.mirrored().mirrored() вообще вернёт image. Да даже с рисованием поверх этой картинки можно такие фокусы проворачивать, если операция рисования на самом деле создаёт только слой поверх оригинального изображения, а основной массив пикселей остаётся лежать как был.
Более того — в первой редакции этого кода можно и пожрать память, получить уже какой-то рабочий код, который умеет что-то делать с картинками, а потом начинать без изменения API его оптимизировать введением лени, отображений, трансляторов, определять когда нужно спекать эти отображения вместе, а когда не стоит, и прочую "магию".
Это только пока. Достаточно всего лишь одной удачной pr-кампании, и dark станет синонимом black, и да начнётся новый виток балета.
Вон с символом ОК получилось, и тут получится.
Продолжайте проводить параллели. 100 лет те буржуи наверняка что-то делали, чтобы защищать угнетённых. Что делают белые профессора, когда вопят о рассизмусе? Насколько это сопоставимо?
Но тогда у хороших учителей пропадает стимул делать из плохой школы хорошую — ведь если школа больше не плохая, они могут потерять до двух третей дохода.
Ну как-то вроде 60 лет назад и призывы съесть всех белых не звучали так громко — там больше было что-то на тему "мы все человеческая раса, мы все равны". Потому именно сейчас, именно в этой ветке — речь именно про 2020-й.
Необязательно именно хуже. Ещё требуется показать, как именно попытки белых профессоров говорить всем в округе, что технические термины оскорбляют угнетённых — действительно приносят самим угнетённым хоть какое-то благо.
Я лично считаю, что, в ряде случаев, с такими союзниками и враги не требуются.
Слышал недавно притчу об одном районе в американском городке. Там в каждой витрине магазина висит флаг движения BLM с соответствующими лозунгами. Знаете, почему? Как говорят владельцы витрин: если флага нет, то витрину разбивают.
Подробностей сходу представить не могу, но если будет нужно — попробую поискать и дам ссылку, где слышал саму притчу.
Да. Но если некая свинья, что называется, happens to be black, то выселить её наверняка не получится, так как любые попытки можно истолковать в том числе как расизм — и именно такое истолкование будет в интересах самих выселяемых, к примеру.
Вы как-то по-прежнему смотрите только с позиции владельца процесса, даже когда я явно предложил смотреть с позиции пользователя.
Tight feedback loop — это благо для вас как пользователя процесса собеседования, и практики собеседования из статьи выше направлены на его затягивание потуже. С точки зрения разработчика IDE тоже может быть невыгодно делать демона-компилятора, ведь программист, который его напишет, потом попросит зарплату или даже премию.
Если вам так удобнее — смотрите на исходную статью тоже как на попытку Додо "залочить как можно больше" людей на своих технологиях собеседования — ведь если их способ понравится кандидатам больше, у Додо будет преимущество в назначении собеседований, при прочих равных.
Приведите конкретные кейсы в которых static без const приведет к ошибкам.
Мы же про настройки? Тогда смена настроек пользователем во время пока приложение что-то выполняет в фоне. Состояние-то вроде одно, но вот один поток читает оттуда одно значение, а соседний — уже другое. Далее в зависимости от важности настройки, вплоть до порчи данных.
если я вообще не обращаюсь к глобальным состояниям из фоновых потоков.
А откуда обращаетесь? Глобальное состояние — оно на то и глобальное, что к нему обращаются из любого места в приложении.
Вы тестируете сущность А, которая работает с моком B. Вы так не поймаете ошибки, специфичные для связки сущности A и реального UI.
Чтобы тестировать связь А с реальным UI — для начала нужно быть уверенным, что А в принципе работает верно. А как это сделать, если любой тест проверяет только UI-специфичные связки? У меня вот для этого есть мок реального UI, с ожиданиями определённой реакции от А на раздражители заданной формы. А у вас?
вся логика на беке
Если так, то откуда берётся необходимость иметь настройки и хранилище? Грузите по проводу и показывайте, грузите и показывайте. А всё о чём мы тут говорили будет применимо к беку без изменений (кроме UI).
И большая часть приложения — взаимодейтсвие с этими api. В итоге вам даже с clean architecture придется переписать всю реализации, за исключением кода который предназначен для связки этих реализаций.
Если типичное приложение всего лишь связывает несколько реализаций вместе и ничего при этом не приносит — то такое приложение не нужно, IMHO. А вот если приносит — то именно то, что оно в себе приносит нового и является ценностью для пользователя, которую имеет смысл сохранить при переезде.
Справедливости ради, с работы нынче действительно выгоняют за мысли. Но разумеется не любые, а только неугодные правильным людям. Кому-то можно пропагандировать геноцид правильных геномов, а кого-то другого уволят и за то, что на расслабленной руке он держал согнутый указательный палец при помощи большого пальца и в результате получился знак "ОК".
К сожалению, тоже не поможет. При желании доберутся и до хостера, а некоторые хостеры ещё и отработают в упреждение, и потом отчитаются в твиттере, как отловили и ликвидировали опасного -иста.
Поясните, пожалуйста, как вы это видите на основе примера. Что значит это «ничего».
А то и значит. Когда люди полоскали Activision Blizzard за решение поддержать иностранную политику Китая, компания сделала ровно ничего, чтобы как-то исправить положение. И было ей за это в итоге тоже ничего.
Так в том и проблема, что для пользовательских запросов нет надёжного способа сказать, какой будет план, пока уже жареные петухи не начнут прицеливаться. Там уже анализ идёт на боевых данных и серверах, благо индексы не меняют сути запроса. Даже на каждом сервере в итоге могут быть немного разное индексирование, как раз из-за конкретного распределения данных на шарде.
Но вон индексацию по блобам jsonb у нас внутри как-то исследовали и выпустили внутреннюю ноту, чтоб ни-ни — jsonb только в проекцию, но не в предикаты. Подробности найти тяжело, но видимо тогда совсем там плохо было.
Я говорил чуть про другое — когда из десяти слоёв undo при добавлении ещё одного слоя получается снова десять (или меньше), просто в каком-нибудь слое N будет лежат результат объединения слоёв N и N-m. Именно такая операция будет деструктивна к undo, зато позволит сэкономить на вычислениях.
"Почему" — видимо, потому, что действует Спираль молчания, помноженная на желание переплюнуть остальных.
Как-то так:
Alice: я усыновила трёх африканских детей!
Bob: пфф-ф, а я усыновил уже четырёх, и собираюсь усыновить пятого
Alice идёт оформлять ещё три свидетельства на усыновление
А чем принципиально та ситуация вверху отличается от "вот у нас есть WHERE по этим колонкам"? И то, и другое, с точки зрения базы, одинаковой важности запросы. Ну может один чаще повторяется — и то не уверен. Полностью статичный WHERE чаще всего используются внутренним кодом, а намного чаще кому-то "просто
спроситьпосмотреть", и во многих системах с RDBMS фильтрация позволяет добавлять свои критерии в некоторых пределах.Да, реальное распределение данных в создании индекса — не единственный момент, который нужно учитывать, его всегда нужно умножать на условный вес запросов по таким данным.
Я против этой идеи и возражал — там в цитате "по пользовательским данным", а надо — "по пользовательским запросам". Такой вариант точнее, но даже если запросы динамически делают пользователи, лучший индекс будет учитывать не просто по каким полям фильтруют, но ещё и как данные реально лежат, и по каким критериям их дискриминировать.
Ломка данных опциональна, на самом деле. Например для того же рисования есть порог, при котором несколько "слоёв" имеет смысл объединить, чтобы не гонять доступ к пикселям через совсем уж толстые слои обёрток — потому что каждый слой будет требовать вычислительных расходов на каждую операцию доступа.
Позвольте, но на основании чего ещё их формировать? Цель создания индекса — это ускорить некоторый класс запросов. И если после создания индекса оказывается, что на реальных данных дискриминатор индекса производит такие же вложенные циклы, как если бы этого индекса совсем не было — то индекс не нужен, совсем — даже если с точки зрения логики для этого типа фактов индексирование именно по этому полю выглядит логично. Например, если у вас в таблице события есть индекс по типу события — ну, логично ведь? Потом оказывается, что все сто миллионов событий на практике имеют тип "день рождения" (и других событий там вообще нет) — то вы с этого индекса поимеете только небольшое замедление при добавлении новой строки события (на пересчёт индекса).
Так ведь никто и не заставляет сразу же делать копирование. Для широкого класса операций (в том числе на картинках) можно результатом
mirrored()вернуть нечnо, что ведёт себя как отзеркаленная картинка, но на деле просто осуществляет трансляцию координат из оригинального изображения при доступе. А напримерimage.mirrored().mirrored()вообще вернётimage. Да даже с рисованием поверх этой картинки можно такие фокусы проворачивать, если операция рисования на самом деле создаёт только слой поверх оригинального изображения, а основной массив пикселей остаётся лежать как был.Более того — в первой редакции этого кода можно и пожрать память, получить уже какой-то рабочий код, который умеет что-то делать с картинками, а потом начинать без изменения API его оптимизировать введением лени, отображений, трансляторов, определять когда нужно спекать эти отображения вместе, а когда не стоит, и прочую "магию".
Это только пока. Достаточно всего лишь одной удачной pr-кампании, и dark станет синонимом black, и да начнётся новый виток балета.
Вон с символом ОК получилось, и тут получится.
Продолжайте проводить параллели. 100 лет те буржуи наверняка что-то делали, чтобы защищать угнетённых. Что делают белые профессора, когда вопят о рассизмусе? Насколько это сопоставимо?
Но тогда у хороших учителей пропадает стимул делать из плохой школы хорошую — ведь если школа больше не плохая, они могут потерять до двух третей дохода.
Ну как-то вроде 60 лет назад и призывы съесть всех белых не звучали так громко — там больше было что-то на тему "мы все человеческая раса, мы все равны". Потому именно сейчас, именно в этой ветке — речь именно про 2020-й.
Необязательно именно хуже. Ещё требуется показать, как именно попытки белых профессоров говорить всем в округе, что технические термины оскорбляют угнетённых — действительно приносят самим угнетённым хоть какое-то благо.
Я лично считаю, что, в ряде случаев, с такими союзниками и враги не требуются.
Слышал недавно притчу об одном районе в американском городке. Там в каждой витрине магазина висит флаг движения BLM с соответствующими лозунгами. Знаете, почему? Как говорят владельцы витрин: если флага нет, то витрину разбивают.
Подробностей сходу представить не могу, но если будет нужно — попробую поискать и дам ссылку, где слышал саму притчу.
Да. Но если некая свинья, что называется, happens to be black, то выселить её наверняка не получится, так как любые попытки можно истолковать в том числе как расизм — и именно такое истолкование будет в интересах самих выселяемых, к примеру.
Вы как-то по-прежнему смотрите только с позиции владельца процесса, даже когда я явно предложил смотреть с позиции пользователя.
Tight feedback loop — это благо для вас как пользователя процесса собеседования, и практики собеседования из статьи выше направлены на его затягивание потуже. С точки зрения разработчика IDE тоже может быть невыгодно делать демона-компилятора, ведь программист, который его напишет, потом попросит зарплату или даже премию.
Если вам так удобнее — смотрите на исходную статью тоже как на попытку Додо "залочить как можно больше" людей на своих технологиях собеседования — ведь если их способ понравится кандидатам больше, у Додо будет преимущество в назначении собеседований, при прочих равных.
Мы же про настройки? Тогда смена настроек пользователем во время пока приложение что-то выполняет в фоне. Состояние-то вроде одно, но вот один поток читает оттуда одно значение, а соседний — уже другое. Далее в зависимости от важности настройки, вплоть до порчи данных.
А откуда обращаетесь? Глобальное состояние — оно на то и глобальное, что к нему обращаются из любого места в приложении.
Чтобы тестировать связь А с реальным UI — для начала нужно быть уверенным, что А в принципе работает верно. А как это сделать, если любой тест проверяет только UI-специфичные связки? У меня вот для этого есть мок реального UI, с ожиданиями определённой реакции от А на раздражители заданной формы. А у вас?
Если так, то откуда берётся необходимость иметь настройки и хранилище? Грузите по проводу и показывайте, грузите и показывайте. А всё о чём мы тут говорили будет применимо к беку без изменений (кроме UI).
Если типичное приложение всего лишь связывает несколько реализаций вместе и ничего при этом не приносит — то такое приложение не нужно, IMHO. А вот если приносит — то именно то, что оно в себе приносит нового и является ценностью для пользователя, которую имеет смысл сохранить при переезде.
Справедливости ради, с работы нынче действительно выгоняют за мысли. Но разумеется не любые, а только неугодные правильным людям. Кому-то можно пропагандировать геноцид правильных геномов, а кого-то другого уволят и за то, что на расслабленной руке он держал согнутый указательный палец при помощи большого пальца и в результате получился знак "ОК".
Уж не знаю, как это изменить, зато точно знаю — если съесть всех белых, то ничего не поменяется.
К сожалению, тоже не поможет. При желании доберутся и до хостера, а некоторые хостеры ещё и отработают в упреждение, и потом отчитаются в твиттере, как отловили и ликвидировали опасного -иста.
А то и значит. Когда люди полоскали Activision Blizzard за решение поддержать иностранную политику Китая, компания сделала ровно ничего, чтобы как-то исправить положение. И было ей за это в итоге тоже ничего.