Виктор Николаев Veikedo

Я возможно чего-то не понимаю, но как при правильно настроенном CSP можно слить JWT из local storage на сторонний сервер?

В целом положительные.
Но у нас не как у Джими Богарда с его vertical features.

У нас "почти clean" — сборка с апп сервисами и в ней свои фичи, сборка презентейшн — либо напрямую юзает классы (дто) из апп сервисов, либо добавляет свои фичи (например, для graphql).

Кроме размещения фич в одном файле, не стесняемся пользоваться nested классами — меньше проблем с придумыванием имён и меньше нейм-конфликтов. Если класс получается большим из-за nested-классов, то делаем класс partial и выносим в отдельный файл.

Раньше вообще делали так, тоже неплохо было, но не прижилось почему-то:

  public class CreateAccount
  {
    public class Command : MediatR.IRequest<Result>
    {
      public string Name { get; }
    }

    public class Result
    {
      public Account Account { get; set; }
    }

    // dto
    public class Account
    {
    }

    public class Mappings : Profile
    {
    }

    public class Validation : AbstractValidator<Command>
    {
    }

    public class Handler : IRequestHandler<Command, Result>
    {
    }
  }

Плюсы медиатра в том, что очень легко решать cross cutting concerns, у marshinov хорошие статьи были на эту тему.

Сейчас используем такой извращённый интересный подход:

namespace Vendor.Features.Statistics
{
  public class GetAutomationStatisticsQuery : IRequest<GetAutomationStatisticsResult>
  {
    public DateTime? FromDate { get; set; }
    public DateTime? ToDate { get; set; }
    public string TaskArn { get; set; }
  }

  public class GetAutomationStatisticsResult
  {
    public long TotalAutomations { get; set; }
    public long ErrorsReported { get; set; }
    public long WarningsReported { get; set; }
  }

  internal class GetAutomationStatisticsHandler :
    IRequestHandler<GetAutomationStatisticsQuery, GetAutomationStatisticsResult>
  {
    private readonly GetAutomationsLogTotalCount _getAutomationsLogTotalCount;
    private readonly GetAutomationsTotalCount _getAutomationsTotalCount;

    public GetAutomationStatisticsHandler(
      // Это делегаты на другие фичи (этакая инкапсуляция над медиатром)
      GetAutomationsLogTotalCount getAutomationsLogTotalCount,
      GetAutomationsTotalCount getAutomationsTotalCount)
    {
      _getAutomationsLogTotalCount = getAutomationsLogTotalCount;
      _getAutomationsTotalCount = getAutomationsTotalCount;
    }

    public async Task<GetAutomationStatisticsResult> Handle(GetAutomationStatisticsQuery query, CancellationToken ct)
    {
      // some logic
    }
  }

  public delegate Task<GetAutomationStatisticsResult> GetAutomationStatistics(
    GetAutomationStatisticsQuery query, CancellationToken ct = default);
}

В каждом файле "фичи" лежат классы для реквеста, респонса, хендлера и делегат (GetAutomationStatistics в примере).

Затем этот делегат через рефлексию регистрируется в IoC с помощью такого класса:

    private sealed class MediatorForwarderForDelegates<TRequest, TResponse> where TRequest : IRequest<TResponse>
    {
      private readonly IMediator _mediator;

      public MediatorForwarderForDelegates(IMediator mediator)
      {
        _mediator = mediator;
      }

      public Task<TResponse> Handle(TRequest request, CancellationToken cancellationToken)
      {
        return _mediator.Send(request, cancellationToken);
      }
    }

Ну и эти делегаты потом уже можно инжектировать в другие хендлеры/сервисы.

Я имел ввиду, что такой подход с инжекцией медиатра, вместо явных зависимостей имеет те же проблемы, что и использование сервис локатора.

ViennaNET.Mediator.*
Такой подход позволяет сократить количество DI-инъекций до одной, например, в контроллерах.

Это про то, что теперь вместо пяти разных сервисов, можно заинжектить какой-нибудь IMediator и юзать его?

Если да, то есть мнение, что это тот же service locator.

react-admin хорош, если все формы простые и одинаковые.
Чуть шаг в сторону и начинаются костыли и баги

Почему не воспользовались AppMetrics?

Извиняюсь, я кажется чего-то не понял — а где хоть какой-то репозиторий birma.net или gorp.net?

За статью спасибо, не знал про реверсивные шаблоны.

А какие потребности решаются прометеусом? Хранение метрик, да решаются

Оп, извиняюсь, я тут имел ввиду AppMetrics и его аналоги.
Неподдерживаемый код потому, что никому кроме вас он не нужен — тот же AppMetrics лучше протестирован и постоянно обновляется/фиксятся баги.

Только не надо писать про Task, он нужен когда создается множество тредов через тредпул(под капотом) и с удобным управлением

Отчего же не надо, когда тут самый подходящий случай? И тредпул как раз-таки не про множество тредов, а совсем наоборот чтобы треды не плодить.
И кстати, если бы использовали нормальную очередь с поддержкой асинхронного ожидания, то выделять тред вообще бы не пришлось.
Но если уж так надо было сделать всё синхронно, то можно выставить TaskCreationOptions.LongRunning, чтобы тредпул (но только если понадобится!) не стеснялся создать ещё один тред.

Извиняюсь, что несколько резко высказываюсь, с утра воду отключили.

del

Разве такие потребности не решаются тем же прометеусом?
А у вас здесь кроме неподдерживаемого кода ещё и создание тредов руками (ещё и без try..catch, что может привести к краху всего процесса) и динамики непонятно зачем и это на первый взгляд только.
Ну и ещё вопросы — кто будет ваш тред останавливать, учитывая, что при завершении процесса в очереди могут быть ещё задачи?
и BlockingCollection был бы здесь более подходящим вариантом с его семафорами и GetConsumingEnumerable, а не Thread.Sleep в цикле как у вас.

У эластика есть ИИ для анализа логов.
Вообще было бы интересно почитать историии про его использование

У нас доходит до 40тб логов за день (и кстати эластик с этим справляется) и при этом отлаживать по логам всё ещё помогает.

В общем-то сентри об этом и пишут здесь
https://sentry.io/vs/logging/

Тоже не совсем понял про just in case логи.
Зачастую они и дают понять контекст ошибок.
Что-то мне кажется, что Sentry не особо поможет прислав мне какой-нибудь InvalidOperationException, который возникает при определённых аргументах в методе, а по логам я как раз смогу увидеть/понять что предшествовало ошибке.

Или вы предлагаете заменить just in case логи на трейсинг?

Конкретно для вашего случая (если у вас EF например), проще было бы просто условие в фильтре поставить:

var note = _db.Notes.FirstOrDefault(x => x.UserId == currentUserId && x.Id == noteId)

Но вообще это можно решить с помощью RuleSet'ов

Я извиняюсь, но как это включить?
К примеру, открываю https://raw.githubusercontent.com/pdyck/hearthstone-db/master/cards/all-cards.json и получаю обычный неформатированный текст.
Тот же JSON Formatter автоматом всё форматирует и показывает.

Если вы старайтесь не дублировать код, то наверняка сталкивались с наследованием DTO

Наследование это не про "как не дублировать код", а про отношения между классами.

Будет ли онлайн трансляция?

А с прошлого семинара видео нет в доступе? Хотелось бы вводные доклады как раз посмотреть

Спасибо за доклад!

Почему Rebus, а не тот же MassTransit?

Пункт 2. Разделение ввода и вывода это скорее благо (да здравствует cqs).

На одном старом проекте одни и те же модельки (=классы) использовались и на вход и на выход. Вы не представляете как меня задолбало по коду смотреть какие поля и когда надо заполнять.

Ваше предложение использовать атрибуты для указания где input/output сильно усложнило бы язык.
Строгий и явный контракт лучше, как по мне.

Работает нормально, но не без неудобств — нужно установить сам choco через powershell и не забывать периодически синхронизировать список установленных программ (можно в gui экспорт делать).
Обновление программ тоже вручную (ну или в планировщик задачу добавить).

Но жирный плюс — не нужно по инсталляторам ходить и тыкать кнопочки

Чтобы на новом компе после логина сразу все ставилось

Тоже этого джва года жду.

Пока что юзаю chocolately и файл с установленным софтом храню в облаке.

На мой взгляд наоборот удобнее отдельную сущность создать для связи:

1. Можно создавать связи не загружая самих сущностей;
2. Легко добавлять дополнительные поля в эту связующую сущность. Например, дату линкования.

Тот же самый "reactor pattern", только с пулом потоков.

Насколько знаю, у nodejs сейчас тоже пул потоков.

Что-то меня напрягает параметр DbContext в AddReview.

Разве агрегаты не должны быть загружены полностью, прежде чем начать свою работу? Если там коллекция действительно такая большая, то возможно стоило по другому спроектировать агрегаты?

На крайний случай, можно было бы и lazy-loading заюзать.

const Widget = () => {
  if (1 === 1) {
    return <div>Nice One</div>
  }

  return <div>Nice Two</div>
};

const Widget1 = () => (
  <div>
    {1 === 1 && <div>Nice One</div>}
    {2 === 1 && <div>Nice Two</div>}
  </div>
);

const Widget2 = () => (
  <div>
    {() => {
      if (1 === 1) {
        return <div>"Nice One"</div>
      }

      return <div>"Nice Two"</div>
    }}
  </div>
);

Если хотите с проверкой типов, то можно юзать tsx, часть typescript'a.

Кавычки будут (это же xml всё-таки), всё остальное верно.

<widget onClick={() => alert(1)}>
   <children>
      ...
   </children>
</widget>

Может и вкусовщина, но мне кажется, было бы гораздо легче тех же реакт нативщиков перевести на флаттер.

Всё это относится и к jsx.

уже есть транслятор jsx во флаттер?

Да, спасибо.

Как реализовать понятно, вопрос о том, есть ли уже готовое.

Ещё вопрос — неужели всех устраивает монструозный (как по мне) трёхэтажный синтаксис описания виджетов? Есть ли планы по разработке подобия jsx?

Понял, спасибо.

Для react native существует, например, nativebase.io, который под каждую платформу отображает нативный элемент.

Видимо, для флаттер придётся подождать сообщества.

Не совсем понял — при использовании флаттер, UI нужно писать отдельно для каждой платформы? Или гугл выпустил какой-то набор компонент, которые по разному отображаются в зависимости от платформы?

Хабр съел ссылку. Подход называется Contextual Validation. Гуглится на сайте Фаулера.

https://martinfowler.com/bliki/ContextualValidation.html

Про Do/CanDo в своё писал Фаулер.

Да я понял о каких книгах речь, спасибо :)

Какую книгу читать сначала: “синюю” или “красную”?

Ну так какую?