Это серьезный вызов для индустрии. С одной стороны офисы уходят, с другой мы так и не научились делать fix-price проекты, с третьей платя удалённому сотруднику можно отказаться третьим работодателем, а с четвёртой жёсткий контроль сотрудников сьедает кучу времени и сильно тормозит процесс.
Вы путаете "культурный код" в голове человека и национальность в паспорте. Во мне 50% славянской крови, а оставшиеся 50% это смесь мордвы, чувашей и поляков. Рос я в Башкирии и культура башкир и татар мне понятна. Жена выросла в Новгородской области, для нее имя Гульнар кажется экзотическим. Мы оба русские, но немного разные русские :)
Возьмите русского с Дальнего Востока и русского из Новгородской области и вы найдете два довольно разных культурных кода у них в голове. На этой разнице, в частности, и появляются всякие конфликты, которые составляют проблематику многонационального государства.
Еще момент - татар может быть и 2%, но в Татарии и Башкирии их будет 50% населения. И если у русских есть с ними проблемы, то для этой конкретной территории это большая проблема.
Я не предлагаю буквально завтра всем поднять зп до 300 тыр за счет государства, это очевидная глупость. Но если бы стояла задача разогнать ВВП, то инвестиции в производство, более-менее свободный рыночек (которые порешает) сами собой вызывают рост зп, который отражает рост ВВП. А если у вас случился кризис и куча производств стоит, то вливание денег в зп просто запустить эти производства.
С другой стороны, если 50% (и более) экономики это государству, то вливание денег в зп просто переложит эти деньги в карман Сечину и компании. Поднимутся цены на бензин, перевозки, энергию и так далее, не потому, что бензина стало нужно больше, а потому что можно поднять цены. Работяга на дополнительные рубли купит еду в ресторане, а Сечин купит акций AAPL (выведет капитал из России);
Если вы удвоите зарплаты методом печатного станка, это вызовет мгновенное повышение спроса. Люди пойдут в магазины покупать то что они раньше не покупали. А что происходит при резком повышении спроса?
Ничего страшного, если рынок работает. Например начинают больше завозить дорогих помидор и меньше дешевых, а затем начинает развиваться сельское хозяйство. Или сначала начинают везти больше одежды от Армани, а затем Армани открывает фабрику в России. Или в ресторанах цены начинают расти, вместе с зп официантов.
Есть тонкий момент, из-за которого все это в России мы не увидим. Армани хочет евро, а у нас напечатанные рубли, курс евро/рубль может упасть. Чтобы курс не упал берем и даем преференции тем странам где а) производят одежду от Армани и б) есть положительное сальдо торгового баланса. В итоге съедаем это сальдо, но получаем время, за которое надо чтобы Армани к нам приехал с фабрикой. Для даем ему дешевые кредиты (опять деньги в нашу экономику) и защищаем его бизнес на нашей территории. Все давно известно и опробовано, уже не раз и не два. Просто защита интересов чужого бизнеса равносильна верховенству закона, а это сильно мешает сильным лидерам.
Если-б все было так просто, то ЦБ и правительства всех стран только этим и занимались-бы. Печатали деньги и раздавали их в качестве зарплат. Но этого не происходит.
Все они ровно этим и занимаются, одни печатают деньги чтобы отразить рост производства, другие чтобы его запустить, а третьи чтобы обеспечить популистскую риторику вождя. Инфляция гарантированно растет только в третьем случае.
Взяли явный код и заменили неявным, кастанули заклинание «SOLID», которое даёт +10 от аргумента «говнокод» и все вроде бы хорошо. Но есть проблемы. Вернее нет проблем, которые бы нуждались в отдельном инструменте такого масштаба. В язык уже встроен шустрый механизм динамической диспетчеризации сообщений - vtbl, таблица виртуальных методов, которой хватает в 90% случаев. Ещё в .NET есть MulticastDelegate, который закроет минимум половину от оставшихся 10%. Ещё есть multiple dispatch через dynamic, что закроет ещё существенный кусок.
MediatR даёт нам тормозную, но более мощную реализацию vtbl. Ради оставшихся 10% проще написать свой велосипед на 50 строк, использовать middleware, написать action filter или просто хардкодить. Любое из этих решений проще поддерживать.
Потому что такой анализ требует широкого кругозора от проектировщика. Увидеть функции не сложно, придумать какую-то объектную модель - запросто. Представить как будут меняться требования - вам скажут, что это бесполезно и есть agile. По факту вполне можно, но нужно очень хорошо понимать в бизнесе. А этого понимания как раз и нет у проектировщика.
Не совсем так - увеличьте зп и у вас вырастет ВВП на это значение. Потому что люди пойдут и потратят эти деньги. Грубо говоря - выдай к все зп в 300 тыр и ВВП вырастет. Если эти траты поддержки производители товаров и услуг увеличение производства, то инфляции не будет. И вот случилась магия - напечатали денег, а инфляции нет. Конечно при условии расширения производства, поэтому все не так просто. Но и не то, чтобы слишком сложно.
Офанаревшие людоедские российские эйчары и менеджмент. За такое на западе вся компания бы попала под прессинг сообщества.
Согласен, но в целом-то описывается наша текущая реальность, автор тут ни при чем, да и его конкретная компания тоже.
Возраст ничего не значит, и это как раз и видно из приведенных примеров - важны знания, умения, нетворкинг.
К сожалению значит, как минимум в глазах работодателя. По факту действительно сложнее изучать новый супер-пупер фреймворк. Отмечу, что сложнее, а не невозможно. К 40 годам разработчик уже должен цениться за умение решать проблемы, а не использования фреймворка. Если за умение решать проблемы возрастного сотрудника не ценят, то это не только проблема компании, но и конкретного человека.
В любом случае я против дискриминации по возрасту, но не очень понятно что с этим можно сделать.
Тут пишут, что egress GCP это 12-8 центов за Гб. У Амазона от 9 центов и ниже. Непонятно как вы на трафике экономите?
А если заморочиться с AWS Private Link то платить можно 2 цента за Гб + сколько возьмёт местный провайдер.
Я могу предположить, что у клиента утилизация ресурсов была низкой. При переезде купили сервера дешевле, настроили автомасштабирование и сэкономили за счёт лучшей утилизации ресурсов. Что с egress непонятно, у гугла он вроде дороже чем у AWS. Могу предположить, что было много «лишнего» трафика внутри AWS зон, который после переезда пропал.
Автор попал в точку, вот прямо сейчас имею кучу геморроя из-за AI. Восстание машин уже с нами и возглавляют его дилетанты и карьеристы. Пытаюсь выяснить у Альфа-Банка простую вещь - корректно ли мне начислили возврат денег за покупку, так как там уплаченная и вернувшаяся сумма не бьется.
4 дня, четыре дня, Карл! Я пытаюсь пройти квест с роботом-помощником в их чате поддержки. Он очень интеллектуально анализирует мой вопрос и затем филигранно тратит мое время, подсовывая бесполезные ответы.
Вот вам сценарий грядущей катастрофы - роботы-дуболомы заменяют людей, все встаёт колом и цивилизация умирает.
Функция, которая покупает или продает актив на таймфрейме в 740 мс ничего не предсказывает. Они делает это либо потому что обязана в силу договора о маркет мейкинге, либо потому что есть арбитраж. Брокерские комиссии, в случае маркет мейкинга, скорее всего отрицательные (вам платят rebate), либо вам дают retail ордера с которыми торговать всегда выгодно.
Верно, оно годится для двух случаев а) буферы из байтов б) десятки или сотни объектов, которые долго создавать. На этом все.
Вот, например, посмотрите тут неплохая серия экспериментов.
According to the GC pauses data, the pooling strategy is actually the worst one when it comes to the real-time operation. It simply does not work – nothing that shows pauses of nearly one second can be considered real-time.
В статье используется пул буферов - массивы байтов это лучший кандидат для пула. Вот еще хорошая цитата
The garbage collector is indeed the biggest risk factor. Pooling introduces very many live objects that causes infrequent, but long GC delays. Allocation, however, overloads GC completely. Besides, at the times of high load (our case C) there may be many live objects anyway, and there allocation fails miserably. So pooling is still better.
Жирным выделил ровно то, о чем я говорю. Пулы тащат для решения проблем пауз GC, но пулы могут ухудшать ситуацию с паузами, делая их еще длинее.
Проблема с GC вылезает в моменты пиковой нагрузки, когда а) система перегружена и тормозит сама по себе б) объектов выделяется много в силу большого числа запросов в) объекты живут долго, ибо система тормозит. Вот тут наступает полная опа. Одно из решений это не допускать таких режимов работы. Другое - положить множество живых объектов в пул, система будет работать лучше чем без пула, но все равно будут длительные паузы.
>Конечно, в самом начале подсчёт чек-сумм пакетов был вынесен в либу через JNI, это понятно. Но тормозило.
Посчет чексумм лучше делать в Java. При использовании JNI вы платите за а) маршалинг аргументов б) пининг буферов. Второе в вашем случае важно, потому что это означает, что GC не может двигать эту область памяти пока выполняется JNI метод. Если предположить, что подсчет чексуммы это существенная часть работы, то вот вам и ответ на вопрос почему тормозит - память сильно фрагментируется из-за пининга, GC выделяет новые регионы памяти, потому что в старых куча дырок, но двигать данные внутри региона нельзя. Память начинает заканчиваться - GC запускается все чаще.
Как только в этой картине появился пул, исчезла проблема фрагментации памяти.
Но я повторюсь - это не проблема того, что приложение генерирует мусор. Это проблема того, что у вас слишком много живых объектов.
Я об этом писал выше - GC плевать сколько у вас мусора накопилось, он не удаляет никакой мусор. Имеет значение количество живых объектов. GC найдёт живые объекты и переместит их в начало сегмента памяти, в процессе перетрет мусор данными живых объектов. Скорость GC зависит от того сколько ему нужно живых объектов проверить и скопировать. Количество мусора (недостижимых объектов) вообще не имеет значения, кроме крайних случаев.
А почему бы тогда просто не выделить эту сотню объектов по мере необходимости и не избавить себя от управления жизненным циклом? Я только одну причину вижу - объекты очень дорого инициализировать.
“Удаления” объектов в Java считайте что нет, забываем про финализаторы. Создание объекта это бесплатная операция, увеличение счётчика. Пул имеет смысл только если конструктор или инициализация объекта какая-то очень сложная. А как решение проблем с GC это так себе идея.
Какой? Я знаю кучу англицизмов, с которыми автокорректор телефона категорически не согласен, и ни одного нормального слова для обозначения API endpoint.
Это серьезный вызов для индустрии. С одной стороны офисы уходят, с другой мы так и не научились делать fix-price проекты, с третьей платя удалённому сотруднику можно отказаться третьим работодателем, а с четвёртой жёсткий контроль сотрудников сьедает кучу времени и сильно тормозит процесс.
Вы путаете "культурный код" в голове человека и национальность в паспорте. Во мне 50% славянской крови, а оставшиеся 50% это смесь мордвы, чувашей и поляков. Рос я в Башкирии и культура башкир и татар мне понятна. Жена выросла в Новгородской области, для нее имя Гульнар кажется экзотическим. Мы оба русские, но немного разные русские :)
Возьмите русского с Дальнего Востока и русского из Новгородской области и вы найдете два довольно разных культурных кода у них в голове. На этой разнице, в частности, и появляются всякие конфликты, которые составляют проблематику многонационального государства.
Еще момент - татар может быть и 2%, но в Татарии и Башкирии их будет 50% населения. И если у русских есть с ними проблемы, то для этой конкретной территории это большая проблема.
Я не предлагаю буквально завтра всем поднять зп до 300 тыр за счет государства, это очевидная глупость. Но если бы стояла задача разогнать ВВП, то инвестиции в производство, более-менее свободный рыночек (которые порешает) сами собой вызывают рост зп, который отражает рост ВВП. А если у вас случился кризис и куча производств стоит, то вливание денег в зп просто запустить эти производства.
С другой стороны, если 50% (и более) экономики это государству, то вливание денег в зп просто переложит эти деньги в карман Сечину и компании. Поднимутся цены на бензин, перевозки, энергию и так далее, не потому, что бензина стало нужно больше, а потому что можно поднять цены. Работяга на дополнительные рубли купит еду в ресторане, а Сечин купит акций AAPL (выведет капитал из России);
Ничего страшного, если рынок работает. Например начинают больше завозить дорогих помидор и меньше дешевых, а затем начинает развиваться сельское хозяйство. Или сначала начинают везти больше одежды от Армани, а затем Армани открывает фабрику в России. Или в ресторанах цены начинают расти, вместе с зп официантов.
Есть тонкий момент, из-за которого все это в России мы не увидим. Армани хочет евро, а у нас напечатанные рубли, курс евро/рубль может упасть. Чтобы курс не упал берем и даем преференции тем странам где а) производят одежду от Армани и б) есть положительное сальдо торгового баланса. В итоге съедаем это сальдо, но получаем время, за которое надо чтобы Армани к нам приехал с фабрикой. Для даем ему дешевые кредиты (опять деньги в нашу экономику) и защищаем его бизнес на нашей территории. Все давно известно и опробовано, уже не раз и не два. Просто защита интересов чужого бизнеса равносильна верховенству закона, а это сильно мешает сильным лидерам.
Все они ровно этим и занимаются, одни печатают деньги чтобы отразить рост производства, другие чтобы его запустить, а третьи чтобы обеспечить популистскую риторику вождя. Инфляция гарантированно растет только в третьем случае.
Тормоза понятие относительно, MediatR точно медленнее чем vtbl, важно это или нет, зависит от контекста.
Взяли явный код и заменили неявным, кастанули заклинание «SOLID», которое даёт +10 от аргумента «говнокод» и все вроде бы хорошо. Но есть проблемы. Вернее нет проблем, которые бы нуждались в отдельном инструменте такого масштаба. В язык уже встроен шустрый механизм динамической диспетчеризации сообщений - vtbl, таблица виртуальных методов, которой хватает в 90% случаев. Ещё в .NET есть MulticastDelegate, который закроет минимум половину от оставшихся 10%. Ещё есть multiple dispatch через dynamic, что закроет ещё существенный кусок.
MediatR даёт нам тормозную, но более мощную реализацию vtbl. Ради оставшихся 10% проще написать свой велосипед на 50 строк, использовать middleware, написать action filter или просто хардкодить. Любое из этих решений проще поддерживать.
Потому что такой анализ требует широкого кругозора от проектировщика. Увидеть функции не сложно, придумать какую-то объектную модель - запросто. Представить как будут меняться требования - вам скажут, что это бесполезно и есть agile. По факту вполне можно, но нужно очень хорошо понимать в бизнесе. А этого понимания как раз и нет у проектировщика.
Не совсем так - увеличьте зп и у вас вырастет ВВП на это значение. Потому что люди пойдут и потратят эти деньги. Грубо говоря - выдай к все зп в 300 тыр и ВВП вырастет. Если эти траты поддержки производители товаров и услуг увеличение производства, то инфляции не будет. И вот случилась магия - напечатали денег, а инфляции нет. Конечно при условии расширения производства, поэтому все не так просто. Но и не то, чтобы слишком сложно.
Согласен, но в целом-то описывается наша текущая реальность, автор тут ни при чем, да и его конкретная компания тоже.
К сожалению значит, как минимум в глазах работодателя. По факту действительно сложнее изучать новый супер-пупер фреймворк. Отмечу, что сложнее, а не невозможно. К 40 годам разработчик уже должен цениться за умение решать проблемы, а не использования фреймворка. Если за умение решать проблемы возрастного сотрудника не ценят, то это не только проблема компании, но и конкретного человека.
В любом случае я против дискриминации по возрасту, но не очень понятно что с этим можно сделать.
Тут пишут, что egress GCP это 12-8 центов за Гб. У Амазона от 9 центов и ниже. Непонятно как вы на трафике экономите?
А если заморочиться с AWS Private Link то платить можно 2 цента за Гб + сколько возьмёт местный провайдер.
Я могу предположить, что у клиента утилизация ресурсов была низкой. При переезде купили сервера дешевле, настроили автомасштабирование и сэкономили за счёт лучшей утилизации ресурсов. Что с egress непонятно, у гугла он вроде дороже чем у AWS. Могу предположить, что было много «лишнего» трафика внутри AWS зон, который после переезда пропал.
Автор попал в точку, вот прямо сейчас имею кучу геморроя из-за AI. Восстание машин уже с нами и возглавляют его дилетанты и карьеристы. Пытаюсь выяснить у Альфа-Банка простую вещь - корректно ли мне начислили возврат денег за покупку, так как там уплаченная и вернувшаяся сумма не бьется.
4 дня, четыре дня, Карл! Я пытаюсь пройти квест с роботом-помощником в их чате поддержки. Он очень интеллектуально анализирует мой вопрос и затем филигранно тратит мое время, подсовывая бесполезные ответы.
Вот вам сценарий грядущей катастрофы - роботы-дуболомы заменяют людей, все встаёт колом и цивилизация умирает.
Функция, которая покупает или продает актив на таймфрейме в 740 мс ничего не предсказывает. Они делает это либо потому что обязана в силу договора о маркет мейкинге, либо потому что есть арбитраж. Брокерские комиссии, в случае маркет мейкинга, скорее всего отрицательные (вам платят rebate), либо вам дают retail ордера с которыми торговать всегда выгодно.
Верно, оно годится для двух случаев а) буферы из байтов б) десятки или сотни объектов, которые долго создавать. На этом все.
Вот, например, посмотрите тут неплохая серия экспериментов.
В статье используется пул буферов - массивы байтов это лучший кандидат для пула. Вот еще хорошая цитата
Жирным выделил ровно то, о чем я говорю. Пулы тащат для решения проблем пауз GC, но пулы могут ухудшать ситуацию с паузами, делая их еще длинее.
Проблема с GC вылезает в моменты пиковой нагрузки, когда а) система перегружена и тормозит сама по себе б) объектов выделяется много в силу большого числа запросов в) объекты живут долго, ибо система тормозит. Вот тут наступает полная опа. Одно из решений это не допускать таких режимов работы. Другое - положить множество живых объектов в пул, система будет работать лучше чем без пула, но все равно будут длительные паузы.
>Конечно, в самом начале подсчёт чек-сумм пакетов был вынесен в либу через JNI, это понятно. Но тормозило.
Посчет чексумм лучше делать в Java. При использовании JNI вы платите за а) маршалинг аргументов б) пининг буферов. Второе в вашем случае важно, потому что это означает, что GC не может двигать эту область памяти пока выполняется JNI метод. Если предположить, что подсчет чексуммы это существенная часть работы, то вот вам и ответ на вопрос почему тормозит - память сильно фрагментируется из-за пининга, GC выделяет новые регионы памяти, потому что в старых куча дырок, но двигать данные внутри региона нельзя. Память начинает заканчиваться - GC запускается все чаще.
Как только в этой картине появился пул, исчезла проблема фрагментации памяти.
Но я повторюсь - это не проблема того, что приложение генерирует мусор. Это проблема того, что у вас слишком много живых объектов.
Я об этом писал выше - GC плевать сколько у вас мусора накопилось, он не удаляет никакой мусор. Имеет значение количество живых объектов. GC найдёт живые объекты и переместит их в начало сегмента памяти, в процессе перетрет мусор данными живых объектов. Скорость GC зависит от того сколько ему нужно живых объектов проверить и скопировать. Количество мусора (недостижимых объектов) вообще не имеет значения, кроме крайних случаев.
А почему бы тогда просто не выделить эту сотню объектов по мере необходимости и не избавить себя от управления жизненным циклом? Я только одну причину вижу - объекты очень дорого инициализировать.
Мне станет лучше от того, что автокорректор телефона перестанет мне мешать. Мелочь, а приятно.
“Удаления” объектов в Java считайте что нет, забываем про финализаторы. Создание объекта это бесплатная операция, увеличение счётчика. Пул имеет смысл только если конструктор или инициализация объекта какая-то очень сложная. А как решение проблем с GC это так себе идея.
Какой? Я знаю кучу англицизмов, с которыми автокорректор телефона категорически не согласен, и ни одного нормального слова для обозначения API endpoint.
Вангеры, абсолютно уникальная игра, одно из лучших произведений русского игростроя.
Про ALTER я не понял, чем оно принципиально отличается от
?