А какие потребности решаются прометеусом? Хранение метрик, да решаются
Оп, извиняюсь, я тут имел ввиду AppMetrics и его аналоги.
Неподдерживаемый код потому, что никому кроме вас он не нужен — тот же AppMetrics лучше протестирован и постоянно обновляется/фиксятся баги.
Только не надо писать про Task, он нужен когда создается множество тредов через тредпул(под капотом) и с удобным управлением
Отчего же не надо, когда тут самый подходящий случай? И тредпул как раз-таки не про множество тредов, а совсем наоборот чтобы треды не плодить.
И кстати, если бы использовали нормальную очередь с поддержкой асинхронного ожидания, то выделять тред вообще бы не пришлось.
Но если уж так надо было сделать всё синхронно, то можно выставить TaskCreationOptions.LongRunning, чтобы тредпул (но только если понадобится!) не стеснялся создать ещё один тред.
Извиняюсь, что несколько резко высказываюсь, с утра воду отключили.
Разве такие потребности не решаются тем же прометеусом?
А у вас здесь кроме неподдерживаемого кода ещё и создание тредов руками (ещё и без try..catch, что может привести к краху всего процесса) и динамики непонятно зачем и это на первый взгляд только.
Ну и ещё вопросы — кто будет ваш тред останавливать, учитывая, что при завершении процесса в очереди могут быть ещё задачи?
и BlockingCollection был бы здесь более подходящим вариантом с его семафорами и GetConsumingEnumerable, а не Thread.Sleep в цикле как у вас.
Тоже не совсем понял про just in case логи.
Зачастую они и дают понять контекст ошибок.
Что-то мне кажется, что Sentry не особо поможет прислав мне какой-нибудь InvalidOperationException, который возникает при определённых аргументах в методе, а по логам я как раз смогу увидеть/понять что предшествовало ошибке.
Или вы предлагаете заменить just in case логи на трейсинг?
Пункт 2. Разделение ввода и вывода это скорее благо (да здравствует cqs).
На одном старом проекте одни и те же модельки (=классы) использовались и на вход и на выход. Вы не представляете как меня задолбало по коду смотреть какие поля и когда надо заполнять.
Ваше предложение использовать атрибуты для указания где input/output сильно усложнило бы язык.
Строгий и явный контракт лучше, как по мне.
Работает нормально, но не без неудобств — нужно установить сам choco через powershell и не забывать периодически синхронизировать список установленных программ (можно в gui экспорт делать).
Обновление программ тоже вручную (ну или в планировщик задачу добавить).
Но жирный плюс — не нужно по инсталляторам ходить и тыкать кнопочки
Что-то меня напрягает параметр DbContext в AddReview.
Разве агрегаты не должны быть загружены полностью, прежде чем начать свою работу? Если там коллекция действительно такая большая, то возможно стоило по другому спроектировать агрегаты?
На крайний случай, можно было бы и lazy-loading заюзать.
Извиняюсь, я кажется чего-то не понял — а где хоть какой-то репозиторий birma.net или gorp.net?
За статью спасибо, не знал про реверсивные шаблоны.
Оп, извиняюсь, я тут имел ввиду AppMetrics и его аналоги.
Неподдерживаемый код потому, что никому кроме вас он не нужен — тот же AppMetrics лучше протестирован и постоянно обновляется/фиксятся баги.
Отчего же не надо, когда тут самый подходящий случай? И тредпул как раз-таки не про множество тредов, а совсем наоборот чтобы треды не плодить.
И кстати, если бы использовали нормальную очередь с поддержкой асинхронного ожидания, то выделять тред вообще бы не пришлось.
Но если уж так надо было сделать всё синхронно, то можно выставить
TaskCreationOptions.LongRunning, чтобы тредпул (но только если понадобится!) не стеснялся создать ещё один тред.Извиняюсь, что несколько резко высказываюсь, с утра воду отключили.
del
Разве такие потребности не решаются тем же прометеусом?
А у вас здесь кроме неподдерживаемого кода ещё и создание тредов руками (ещё и без try..catch, что может привести к краху всего процесса) и динамики непонятно зачем и это на первый взгляд только.
Ну и ещё вопросы — кто будет ваш тред останавливать, учитывая, что при завершении процесса в очереди могут быть ещё задачи?
и BlockingCollection был бы здесь более подходящим вариантом с его семафорами и GetConsumingEnumerable, а не Thread.Sleep в цикле как у вас.
У эластика есть ИИ для анализа логов.
Вообще было бы интересно почитать историии про его использование
У нас доходит до 40тб логов за день (и кстати эластик с этим справляется) и при этом отлаживать по логам всё ещё помогает.
В общем-то сентри об этом и пишут здесь
https://sentry.io/vs/logging/
Тоже не совсем понял про just in case логи.
Зачастую они и дают понять контекст ошибок.
Что-то мне кажется, что Sentry не особо поможет прислав мне какой-нибудь InvalidOperationException, который возникает при определённых аргументах в методе, а по логам я как раз смогу увидеть/понять что предшествовало ошибке.
Или вы предлагаете заменить just in case логи на трейсинг?
Конкретно для вашего случая (если у вас EF например), проще было бы просто условие в фильтре поставить:
Но вообще это можно решить с помощью RuleSet'ов
Я извиняюсь, но как это включить?
К примеру, открываю https://raw.githubusercontent.com/pdyck/hearthstone-db/master/cards/all-cards.json и получаю обычный неформатированный текст.
Тот же JSON Formatter автоматом всё форматирует и показывает.
Наследование это не про "как не дублировать код", а про отношения между классами.
Будет ли онлайн трансляция?
А с прошлого семинара видео нет в доступе? Хотелось бы вводные доклады как раз посмотреть
Спасибо за доклад!
Почему Rebus, а не тот же MassTransit?
Пункт
2. Разделение ввода и выводаэто скорее благо (да здравствует cqs).На одном старом проекте одни и те же модельки (=классы) использовались и на вход и на выход. Вы не представляете как меня задолбало по коду смотреть какие поля и когда надо заполнять.
Ваше предложение использовать атрибуты для указания где input/output сильно усложнило бы язык.
Строгий и явный контракт лучше, как по мне.
Работает нормально, но не без неудобств — нужно установить сам choco через powershell и не забывать периодически синхронизировать список установленных программ (можно в gui экспорт делать).
Обновление программ тоже вручную (ну или в планировщик задачу добавить).
Но жирный плюс — не нужно по инсталляторам ходить и тыкать кнопочки
Тоже этого джва года жду.
Пока что юзаю chocolately и файл с установленным софтом храню в облаке.
На мой взгляд наоборот удобнее отдельную сущность создать для связи:
Тот же самый "reactor pattern", только с пулом потоков.
Насколько знаю, у nodejs сейчас тоже пул потоков.
Что-то меня напрягает параметр
DbContextвAddReview.Разве агрегаты не должны быть загружены полностью, прежде чем начать свою работу? Если там коллекция действительно такая большая, то возможно стоило по другому спроектировать агрегаты?
На крайний случай, можно было бы и lazy-loading заюзать.