2) Нет ci/cd? Для финтеха сомнительно, ну ладно. Нужно выбивать. У меня в лохматые годы тоже не было. Ничего, не обломался, поднял tfs, Тим сити. Они бесплатные. Потом посмотрели, подняли на уровень управления
3) Работа не повышает квалификацию? Есть курсы, конференции, разработка пет-проектов.
Собственно, enterprise-программирование - это не искусство, а, в первую очередь, ремесло. Нужно искусство - смотри стартапы или отделы r&d
И такой код просто отключает индекс по полю CreatedDate.
Логичный и ясный запрос в orm не всегда является таковым с точки зрения оптимальности запроса sql.
Актуальность orm продается под соусом избавления программиста от знания sql. Но по факту программист должен знать и sql, и особенности orm. Двойная работа.
Поэтому мне больше по душе легковесные orm типа dapper, которые занимаются именно маппингом объектов, оставляя логику написания запроса программисту
"Вы предлагаете запросу, с одной транзакцией случайно сгенерировать ранг 7539 и ждать, пока 7538 транзакций отработают, пока кукушонку не дойдет очередь.": Именно так, ведь мы исходим из предположения, что все транзакции равноправны. Иных вводных то нет. Поэтому уравниваем вероятности исполнения транзакций.
Конечно, если всего 2 клиента, по 1 транзакции и 10к транзакций, то такие коллизии возможны. Но когда одиночных транзакций становится побольше, среднее время ожидания уменьшается
Есть ещё вариант: реализовать список из клиентов, где у каждого клиента своя очередь транзакций. И можно выбирать поочередно из каждой очереди сообщения. Этот вариант более лоялен к клиентам с мелкими транзакциями. А крупняки получат могут получить приличную задержку.
Вариант 3 - это вариация варианта 2: оценивать при вычитывании размер очереди. Чем больше размер очереди, тем больше у этой очереди приоритет вычитывания транзакций. И после каждого вычитывания пересчитывать приоритеты
Получится примерно так-2 клиента: 10к транзакций и 100 транзакций. И на каждую 1000 транзакций из первой очереди считаем 10 транзакций из второй. Этот вариант позволяет уровнять время обслуживания всех клиентов.
Я может чего не понял в постановке, но что мешает получить сообщение с транзакциями (без учёта их количества) и по одной записывать в ту же кафку? Тогда сообщения от всех клиентов будут равномерно перемешаны с учётом времени прихода. И также горизонтально масштабируется путем создания нужных партий и увеличения консьюмеров
Если же требуется "размазать" условные 10к транзакций по периоду, и в эту кашу подкидывать транзации-кукушата, то нужно придумать функцию, которая ранжирует транзации. В простейшем варианте - генератор равномерно распределенных случайных чисел.
Грубо говоря - получили 10к транзакций. Присваиваем каждой из них случайное число в диапазоне 0..100к и пишем их в БД.
Вычитываем топ N транзакций, отправляем на исполнение, а у оставшихся транзакций в бд уменьшаем ранжирование на величину, равную минимальному оставшемуся значению (это позволит уменьшить время ожидания самых последних транзакций)
То есть вычитали скажем одну, самую низкоранговую транзакцию с рангом 157. Следующая транзакция например 301. Тогда у всех остальных ранг понизили на 301. И транзация 301 стала транзакцией с нулевым рангом.
Метод работает хорошо, если скорость исполнения транзакций значительно превышает скорость их прихода.
PS только обратил внимание, что gandjustas предложил в принципе то же самое со своей функцией долга
1) делаем справочник вместо перечислений, если изменение списка допустимых значений не приводит к необходимости доработки существующего кода
2) используем enum, если каждое изменение перечня значений - это изменение функциональности в коде, и выводится на пром релизом, в котором учтены скрипты миграции
А зачем просиживать штаны? Почему бы и не развиваться там, где распределен?
Я по своему опыту и говорю - попал в НИИ, прекрасно себя чувствовал, + похалтуривал. 5 лет прошло, спокойно ушел в банк работать.
Вам не кажется, что человек, просиживающий штаны в НИИ, будет точно также просиживать в коммерции? И доход у такого человека всегда будет невпечатляющий
300-500к - это стоимость годового обучения в нормальном ВУЗе. Типа Плешки. А у вас за 3 года налогов...
6*400=2 млн 400 т. рублей стоимость обучения. +, Если кредит на обучение брать, это ещё около 800к процентов. Итого 3200
Допустим, в сфере разработки начинающим спецам будут платить 200к. Итого в год 2400. То есть чтобы расплатиться за обучение, всю зп нужно отдавать 1.3 года. А если не всю, то те же 3-4 года займет выплата долга
Вот и считайте, выгодно ли будет отработать на государство 3 года и получать в районе 40-50 тысяч. Или лучше в свободном полете получать те же 40-50 на свою жизнь, расплачиваясь с банком
Эта ведь з/п в 200к это для подавляющего большинства населения очень большие деньги. Если подставлять более реальные зарплаты, то окупаемость будет сильно выше, чем гипотетическая 3 летняя работа.
У меня только один вопрос-просьба: в каких реальных, а не синтетических кейсах затраты на throw оказались настолько критичными, что потребовалась оптимизация? Приведите пример, пожалуйста
А я читаю: Я решила использовать что-то новое, возникли проблемы и МЫ всей командой начали думать, как исправить эти проблемы ))
А так: сложный фронт - горе в команде. Тем более, что сложный фронт в web. Лучше режим виртуализации + обсчитывающая хотелки пользователей бэковая часть
Всегда есть что сделать
1) Нет документации? Так начинай вести
2) Нет ci/cd? Для финтеха сомнительно, ну ладно. Нужно выбивать. У меня в лохматые годы тоже не было. Ничего, не обломался, поднял tfs, Тим сити. Они бесплатные. Потом посмотрели, подняли на уровень управления
3) Работа не повышает квалификацию? Есть курсы, конференции, разработка пет-проектов.
Собственно, enterprise-программирование - это не искусство, а, в первую очередь, ремесло. Нужно искусство - смотри стартапы или отделы r&d
Полнотекстовый поиск
И такой код просто отключает индекс по полю CreatedDate.
Логичный и ясный запрос в orm не всегда является таковым с точки зрения оптимальности запроса sql.
Актуальность orm продается под соусом избавления программиста от знания sql. Но по факту программист должен знать и sql, и особенности orm. Двойная работа.
Поэтому мне больше по душе легковесные orm типа dapper, которые занимаются именно маппингом объектов, оставляя логику написания запроса программисту
Какой-то странный выверт сознания. В Сбере ИТшники как раз и имеют возможность сидеть на удалёнке.
И очень много людей с регионов
Тут я не согласен. Возвращать 200 на любой чих можно и в REST. Это не косяк RPC, а кривые руки разработчика.
ЗЫ А так вообще приятно видеть знакомые ники с sql ru
Пришлось делать получение объектов через post /objects/get - сложные фильтры с массивами через тело передаю
В итоге если остальные методы делать как rest - будет некрасиво и не единообразно
Решил тогда всю api-шку сделать как rpc:
Все методы post, глагол в конце url, все идентификаторы - как query параметры
Ну и в этой парадигме в тему пришлось создание сразу нескольких объектов в одном запросе
Кажется, не то же самое. Отдельный инстанс на мелкие транзакции неравно отдельному инстансу на клиента
"Вы предлагаете запросу, с одной транзакцией случайно сгенерировать ранг 7539 и ждать, пока 7538 транзакций отработают, пока кукушонку не дойдет очередь.": Именно так, ведь мы исходим из предположения, что все транзакции равноправны. Иных вводных то нет. Поэтому уравниваем вероятности исполнения транзакций.
Конечно, если всего 2 клиента, по 1 транзакции и 10к транзакций, то такие коллизии возможны. Но когда одиночных транзакций становится побольше, среднее время ожидания уменьшается
Есть ещё вариант: реализовать список из клиентов, где у каждого клиента своя очередь транзакций. И можно выбирать поочередно из каждой очереди сообщения. Этот вариант более лоялен к клиентам с мелкими транзакциями. А крупняки получат могут получить приличную задержку.
Вариант 3 - это вариация варианта 2: оценивать при вычитывании размер очереди. Чем больше размер очереди, тем больше у этой очереди приоритет вычитывания транзакций. И после каждого вычитывания пересчитывать приоритеты
Получится примерно так-2 клиента: 10к транзакций и 100 транзакций. И на каждую 1000 транзакций из первой очереди считаем 10 транзакций из второй. Этот вариант позволяет уровнять время обслуживания всех клиентов.
Я может чего не понял в постановке, но что мешает получить сообщение с транзакциями (без учёта их количества) и по одной записывать в ту же кафку? Тогда сообщения от всех клиентов будут равномерно перемешаны с учётом времени прихода. И также горизонтально масштабируется путем создания нужных партий и увеличения консьюмеров
Если же требуется "размазать" условные 10к транзакций по периоду, и в эту кашу подкидывать транзации-кукушата, то нужно придумать функцию, которая ранжирует транзации. В простейшем варианте - генератор равномерно распределенных случайных чисел.
Грубо говоря - получили 10к транзакций. Присваиваем каждой из них случайное число в диапазоне 0..100к и пишем их в БД.
Вычитываем топ N транзакций, отправляем на исполнение, а у оставшихся транзакций в бд уменьшаем ранжирование на величину, равную минимальному оставшемуся значению (это позволит уменьшить время ожидания самых последних транзакций)
То есть вычитали скажем одну, самую низкоранговую транзакцию с рангом 157. Следующая транзакция например 301. Тогда у всех остальных ранг понизили на 301. И транзация 301 стала транзакцией с нулевым рангом.
Метод работает хорошо, если скорость исполнения транзакций значительно превышает скорость их прихода.
PS только обратил внимание, что gandjustas предложил в принципе то же самое со своей функцией долга
Возможно, комментатор предположил, что это гастролирующая пиццерия, которая готовит пиццу на оборудовании заказчика?
Или порядок приготовления пиццы отличается в зависимости от рецептуры
Сбер большой. Команд много. Кто то канбанит, кто то скрамит, кто то свое придумывает. У каждой команды свои практики.
Мы следуем следующей логике.
1) делаем справочник вместо перечислений, если изменение списка допустимых значений не приводит к необходимости доработки существующего кода
2) используем enum, если каждое изменение перечня значений - это изменение функциональности в коде, и выводится на пром релизом, в котором учтены скрипты миграции
Сильное заблуждение. Есть там спецы, и очень хорошие.
А зачем просиживать штаны? Почему бы и не развиваться там, где распределен?
Я по своему опыту и говорю - попал в НИИ, прекрасно себя чувствовал, + похалтуривал. 5 лет прошло, спокойно ушел в банк работать.
Вам не кажется, что человек, просиживающий штаны в НИИ, будет точно также просиживать в коммерции? И доход у такого человека всегда будет невпечатляющий
300-500к - это стоимость годового обучения в нормальном ВУЗе. Типа Плешки. А у вас за 3 года налогов...
6*400=2 млн 400 т. рублей стоимость обучения. +, Если кредит на обучение брать, это ещё около 800к процентов. Итого 3200
Допустим, в сфере разработки начинающим спецам будут платить 200к. Итого в год 2400. То есть чтобы расплатиться за обучение, всю зп нужно отдавать 1.3 года. А если не всю, то те же 3-4 года займет выплата долга
Вот и считайте, выгодно ли будет отработать на государство 3 года и получать в районе 40-50 тысяч. Или лучше в свободном полете получать те же 40-50 на свою жизнь, расплачиваясь с банком
Эта ведь з/п в 200к это для подавляющего большинства населения очень большие деньги. Если подставлять более реальные зарплаты, то окупаемость будет сильно выше, чем гипотетическая 3 летняя работа.
По моему, логично. Если государство платит за твое образование, значит должен быть определенный расчет на то, что ты затраты компенсируешь.
Бери кредит и выплачивай долг. Нет денег? Тогда отработай там, где ты нужен государству определенное время.
А так, действительно, светлые головы за наш общий счёт получают образование, но выгодоприобретателем этого зачастую становятся иностранные государства
С технической точки зрения документ-родитель связан со своим наследником отношением 1 к 1
Пример: реестр документов. Одна таблица - общая шапка. Другие - содержат переменную часть, зависящую от конкретного типа документа
У меня только один вопрос-просьба: в каких реальных, а не синтетических кейсах затраты на throw оказались настолько критичными, что потребовалась оптимизация? Приведите пример, пожалуйста
А я читаю: Я решила использовать что-то новое, возникли проблемы и МЫ всей командой начали думать, как исправить эти проблемы ))
А так: сложный фронт - горе в команде. Тем более, что сложный фронт в web. Лучше режим виртуализации + обсчитывающая хотелки пользователей бэковая часть