какой темой вы пользуетесь? (я поставил себе base16 eighties, чтобы чёрный не выжигал глаза. Редактор выглядит лучше, но, например, окошки поиска/замены выглядят странно, что я даже не пойму, что там кнопки, а что нет)
как в VS Code заменить табы на пробелы? (я нашел через Ctrl-P, и потом >, как заменить ведущие табы на пробелы. А я хочу заменить все)
Про хинты у меня противоположный опыт. Единственные проекты, где запросы всегда работали нормально – это где все запросы приложения были захинтованы. А те проекты, которые считали хинты злом, регулярно ловили большие проблемы с производительностью. При этом налицо была корреляция, что у тех команд, которые не использовали хинты, было множество других проблем с пониманием, как всё работает под капотом. Там и разбиение на сущности неправильное было, и типы данных, и все остальные ошибки из этого поста.
Всё, что сейчас добавляют в Джаву, сделано позже, чем в Котлине, но при этом лучше, чем в Котлине. Целая команда крутых архитекторов сильно продумывает фичи, и как правило, делает несколько PoC, прежде, чем выпустить фичу. И получается очень хорошо: и с записями, и с value-типами, и проектом Loom, и много с чем ещё. Loom вообще хороший пример, как надо делать фичи. В Котлине корутины сделаны раньше, но далеко не так элегантно, приходится размечать асинхронный код.
Да, но смысл тот же, что контраст должен быть не зашкаливающим. А то при отведении взгляда от монитора вы будете видеть полоски текста, потому что буквы выжгли глаза. И лично я прелюдпочитаю не тёмно-серый, а тёмно-коричневый, вроде такого Серый мне навевает тоску. Кстати, для VS Code я так и не нашел подходящей для себя темы. Они или слишком контрастные, или серые.
Не подскажете, какие есть подходы к тому, что в PostgreSQL нет глобальных индексов? Я пока вижу только вариант иметь «глобальную» таблицу вместо индекса, и поддерживать её из кода. Есть ли ещё какие-то опции?
Да, я же и говорю, что он выдает уже агрегированные метрики. А нам нужны были индивидуальные, чтобы агрегировать самим. А то, например, из персентилей по минуте чисто математически не получить персентили по часу, кроме минимума и максимума.
Коридор же не так работает. Пусть мы пишем простой селект. Тогда слово select будет начинаться прямо с начала строки, перед from будет два пробела, перед where – один, перед having – ни одного, перед left – два, и так далее. То есть от замены join на left join ничего не поползёт. Поползти может только если будет ключевое слово больше шести букв длиной, но это достаточно редко бывает.
select t1.a,
t2.b,
count(1) as cnt
from t1
left join t2
on (t1.my_key = t2.my_key)
where t1.city = 'CHICAGO'
having count(1) > 1
Когда мы хотели прикрутить к приложению Micrometer-метрики, то упёрлись в то, что он сбрасывает уже сагрегированные значения, например: за минуту было 38 реквестов, среднее время 100мс, худшее 800мс. А мы хотели иметь каждую метрику отдельно, и агрегировать уже самим. В итоге пришлось остаться на своих собственных метриках, а не на Micrometer-ных.
Правда это было пару лет назад, и, возможно, сейчас Micrometer умеет то, что нам нужно.
Вот эта часть из статьи как раз подходит к битмап-индексам: "Селективность колонки мала, но селективность набора многих колонок высока. Если все эти колонки используются в WHERE, то такой индекс будет полезен."
Сила битмап-индексов в том, что они хорошо сочетаются друг с другом (а маски нулей и единиц, соответсвенно, накладываются). А недостаток – слишком много строк блокируется при модификации данных, поэтому такие индексы, как правило, не используют в OLTP-системах, а только в хранилищах.
В последний раз, когда я у вас заказывал лампочки, эта система матчинга была сломана для них.
Я выбираю нужные мне лампочки, например GU10 220В. На их карточке есть переключалка, сколько в упаковке. Я, например, переключаю с 5 на 10, и получаю лампы другого вольтажа и другого размера (например 12-Вольтовые, больше размером, который не влезет в мои светильники). Обычно я успевал это заметить до заказа, но один раз мне привезли не те лампочки, и пришлось их возвращать.
Или, например, кувшины-фильтры для воды. Смотришь оценку, отзывы. А там на фотках вообще другой кувшин у людей.
Вы правы, и поэтому у нас работает чуть по-другому. Для N команд, работающих над одним проектом, выделена зона. То есть вы автоматом будете рядом с теми, кто работает над тем же самым. А уже внутри идут зоны команд, где, возможно, надо будет договориться, что команда А бывает по вторникам и четвергам, а команда Б – по средам и пятницам. И это не мешает кому-то прийти не в свой день, столов вполне хватает. Если кто-то хочет ходить 4 и больше дней в неделю, то стол за ним/ней закрепляют.
Я помню как на DevOps-конференции ребята из Monzo-банка рассказывали, что когда, например, в три часа ночи нет транзакций, то непонятно, это потому, что их действительно нет, или потому, что система лежит.
И если в течение часа не было транзакций, то они сами делали транзакцию на один фунт между своими счетами или картами, и смотрели, отразится ли она в системе.
По их словам, в изначальной версии это был механический паровозик, который проезжал с карточкой мимо бесконтактного терминала по специальной кольцевой железной дороге.
Воспользуюсь случаем, и спрошу у фаната VS Code.
какой темой вы пользуетесь? (я поставил себе base16 eighties, чтобы чёрный не выжигал глаза. Редактор выглядит лучше, но, например, окошки поиска/замены выглядят странно, что я даже не пойму, что там кнопки, а что нет)
как в VS Code заменить табы на пробелы? (я нашел через Ctrl-P, и потом >, как заменить ведущие табы на пробелы. А я хочу заменить все)
Я очень долго пользовался Das Keyboard‘ом. А потом пересел на Мак, и понял, что маковская клавиатура для меня гораздо удобнее механики.
И даже если его нет (хотя сложно себе такое представить), то то же самое элементарно пишется на case when и group by.
Про хинты у меня противоположный опыт. Единственные проекты, где запросы всегда работали нормально – это где все запросы приложения были захинтованы. А те проекты, которые считали хинты злом, регулярно ловили большие проблемы с производительностью. При этом налицо была корреляция, что у тех команд, которые не использовали хинты, было множество других проблем с пониманием, как всё работает под капотом. Там и разбиение на сущности неправильное было, и типы данных, и все остальные ошибки из этого поста.
Всё, что сейчас добавляют в Джаву, сделано позже, чем в Котлине, но при этом лучше, чем в Котлине. Целая команда крутых архитекторов сильно продумывает фичи, и как правило, делает несколько PoC, прежде, чем выпустить фичу. И получается очень хорошо: и с записями, и с value-типами, и проектом Loom, и много с чем ещё. Loom вообще хороший пример, как надо делать фичи. В Котлине корутины сделаны раньше, но далеко не так элегантно, приходится размечать асинхронный код.
Мы сейчас начали аналогичную штуку делать, но мы скорее в начале этого пути
Да, но смысл тот же, что контраст должен быть не зашкаливающим. А то при отведении взгляда от монитора вы будете видеть полоски текста, потому что буквы выжгли глаза.
И лично я прелюдпочитаю не тёмно-серый, а тёмно-коричневый, вроде такого
Серый мне навевает тоску.
Кстати, для VS Code я так и не нашел подходящей для себя темы. Они или слишком контрастные, или серые.
Хорошая тёмная тема тоже не такая уж и тёмная. Фон там не черный, да и буквы не белые.
И с трилогией про Джейсона Борна
Не подскажете, какие есть подходы к тому, что в PostgreSQL нет глобальных индексов?
Я пока вижу только вариант иметь «глобальную» таблицу вместо индекса, и поддерживать её из кода. Есть ли ещё какие-то опции?
А что вы имеете в виду под затиркой дисплея от клавиатуры?
Да, я же и говорю, что он выдает уже агрегированные метрики. А нам нужны были индивидуальные, чтобы агрегировать самим. А то, например, из персентилей по минуте чисто математически не получить персентили по часу, кроме минимума и максимума.
Коридор же не так работает. Пусть мы пишем простой селект. Тогда слово select будет начинаться прямо с начала строки, перед from будет два пробела, перед where – один, перед having – ни одного, перед left – два, и так далее. То есть от замены join на left join ничего не поползёт. Поползти может только если будет ключевое слово больше шести букв длиной, но это достаточно редко бывает.
Когда мы хотели прикрутить к приложению Micrometer-метрики, то упёрлись в то, что он сбрасывает уже сагрегированные значения, например: за минуту было 38 реквестов, среднее время 100мс, худшее 800мс. А мы хотели иметь каждую метрику отдельно, и агрегировать уже самим. В итоге пришлось остаться на своих собственных метриках, а не на Micrometer-ных.
Правда это было пару лет назад, и, возможно, сейчас Micrometer умеет то, что нам нужно.
Gramota.ru говорит нам, что правильный вариант как раз "носков". Но с некоторых пор вариант "носок" считается допустимым.
Вот эта часть из статьи как раз подходит к битмап-индексам: "Селективность колонки мала, но селективность набора многих колонок высока. Если все эти колонки используются в WHERE, то такой индекс будет полезен."
Сила битмап-индексов в том, что они хорошо сочетаются друг с другом (а маски нулей и единиц, соответсвенно, накладываются). А недостаток – слишком много строк блокируется при модификации данных, поэтому такие индексы, как правило, не используют в OLTP-системах, а только в хранилищах.
В последний раз, когда я у вас заказывал лампочки, эта система матчинга была сломана для них.
Я выбираю нужные мне лампочки, например GU10 220В. На их карточке есть переключалка, сколько в упаковке. Я, например, переключаю с 5 на 10, и получаю лампы другого вольтажа и другого размера (например 12-Вольтовые, больше размером, который не влезет в мои светильники). Обычно я успевал это заметить до заказа, но один раз мне привезли не те лампочки, и пришлось их возвращать.
Или, например, кувшины-фильтры для воды. Смотришь оценку, отзывы. А там на фотках вообще другой кувшин у людей.
Вы правы, и поэтому у нас работает чуть по-другому. Для N команд, работающих над одним проектом, выделена зона. То есть вы автоматом будете рядом с теми, кто работает над тем же самым. А уже внутри идут зоны команд, где, возможно, надо будет договориться, что команда А бывает по вторникам и четвергам, а команда Б – по средам и пятницам. И это не мешает кому-то прийти не в свой день, столов вполне хватает. Если кто-то хочет ходить 4 и больше дней в неделю, то стол за ним/ней закрепляют.
я просто оставлю это здесь
Перевод с http://dilbertru.blogspot.com
Дилберт: Мы выиграли тендер правительства на устройство для абсорбции CO2, и теперь нам нужны идеи.
Дилберт: Это пока только мозговой штурм, так что помните, "плохих идей не бывает".
Алиса: Мы могли бы ловить CO2 сетью.
Алиса: Ты разве не собираешься записать эту идею?
Дилберт: Нет, я вполне уверен, что запомню это предложение до конца своей жизни.
Уолли: Мы могли бы завлекать CO2 какой-нибудь едой.
Дилберт: ЗАБУДЬТЕ! ВЫ ВСЕ ИДИОТЫ! Я ПРОСТО САМ СДЕЛАЮ ЭТУ ДУРАЦКУЮ МАШИНУ!
Алиса: Было прикольно.
Уолли: Обожаю мозговые штурмы.
Я помню как на DevOps-конференции ребята из Monzo-банка рассказывали, что когда, например, в три часа ночи нет транзакций, то непонятно, это потому, что их действительно нет, или потому, что система лежит.
И если в течение часа не было транзакций, то они сами делали транзакцию на один фунт между своими счетами или картами, и смотрели, отразится ли она в системе.
По их словам, в изначальной версии это был механический паровозик, который проезжал с карточкой мимо бесконтактного терминала по специальной кольцевой железной дороге.