Задать вопрос
  • Настройка трёх сетевых карт Debian systemd-networkd?

    @historydev
    То есть это проще, чем купить нормальный или самый дешёвый роутер?
    - Причина для подобных деяний сомнительная.
    Написано
  • Видит ли администрация сайта сканирование,и можно ли скрыть?

    @historydev
    onlywin, Выделите сумму Х на тесты, основной аккаунт для них не используйте.
    - Вымышленные законы нельзя учитывать при расчётах.

    Иначе продолжайте делать то, что делаете и посмотрите к чему это приведёт.
    - "Не использовать ПО" может быть лишь на бумаге и для блокировки очень наглых пользователей, которые спамят запросы например.
    Написано
  • Видит ли администрация сайта сканирование,и можно ли скрыть?

    @historydev
    Если есть тестовое окружение - тестируйте на нём, если нет - аккаунты для тестов заведите, чтобы в случае их блокировки ничего не терять.
    - Полагаю биржа с криптой связана и не столь сложно завести несколько аккаунтов.
    Написано
  • Как идентифицировать проксированные ошибки?

    @historydev Автор вопроса, куратор тега JavaScript
    rPman, Идея хорошая, но столько времени в данный момент у меня нет, покрою минимальное кол-во ошибок, а как появится время вернусь к этому сценарию.
    Написано
  • Как идентифицировать проксированные ошибки?

    @historydev Автор вопроса, куратор тега JavaScript
    rPman, Понял, значит попроще не получится.. Спасибо.
    Написано
  • Как идентифицировать проксированные ошибки?

    @historydev Автор вопроса, куратор тега JavaScript
    открываешь табличный процессор (excel/libre calc/google spreadsheet/..) открываешь в соседнем окне документацию по используемой библиотеке/фреймворке/базе данных (или исходники, если документация как обычно не полна), и собираешь строчка за строчкой все виды ошибок в первой колонке... пытаясь объединить однотипные ошибки (например not found везде имеет один смысл, или connection error/file not found для того же sqlite)...

    - Это самая очевидная часть.

    Вот пример проблемы: Если я передам сообщение без конкретной информации, например "user not found", в таком случае для локализации этой ошибки мне придётся работать с этим текстом, а наличие некоторого кода X и доп. информации даст возможность понимать что произошло не вникая в сообщение.
    - Чтобы вызывающая сторона могла утверждать: Если err.code.X === "U1" показать "Пользователь не найден". Вместо вывода err.message
    Написано
  • Как идентифицировать проксированные ошибки?

    @historydev Автор вопроса, куратор тега JavaScript
    rPman, Вот именно! А как эту систему ошибок строить - я не понимаю. Могу малой кровью конвертировать любые пакетные ошибки в свои, но как идентифицировать их для вызывающей стороны - непонятно.
    - Подумываю взять фиксированный набор ошибок которые с большей вероятностью могут возникнуть у вызывающей стороны, а остальные отнести к непредвиденным и по необходимости расширять, например валидацию проксирую, а подключение к базе нет.

    Доступно вызывающей стороне?
    Написано
  • Как идентифицировать проксированные ошибки?

    @historydev Автор вопроса, куратор тега JavaScript
    rPman, 3 типа: ошибка zod (валидация), ошибка prisma (смешанно: валидация/подключение/foreign key) и непредвиденная ошибка
    try { /* ... */} catch(e) { throw new UserRepoError() }


    Эти ошибки могут вернуть любые пакеты или даже голый sql и ручная проверка, я хочу привести это к фиксированному формату, чтобы в случае замены этих пакетов нужно было лишь проецировать новые ошибки на свой формат.

    Переписать все типы ошибок это как раз моё решение с нумерацией, но сроки уже на пороге, а работы меньше не становится.

    Если я передам её дальше, в случае замены пакета вызывающая сторона получает в багаж ломающее изменение, а так-же получает информацию о внутреннем устройстве модуля - моя цель избежать этого.
    Написано
  • Как идентифицировать проксированные ошибки?

    @historydev Автор вопроса, куратор тега JavaScript
    Проблема не в месте хранения мета информации, а в её структуризации.
    Написано
  • Долгое ожидание загрузки через браузер (Laravel + React / InertiaJS), из-за чего?

    @historydev
    аеза закончилась - ищи другого поставщика.
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA, Нет. Я же по цифрам специально разделил:
    Валидация - Баланс это число.
    Бизнес-правило - Баланс не может быть меньше нуля.

    Мне нужно чтобы части системы легко заменялись.
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA, 2 типа проверок:
    1. Валидация
    2. Бизнес-правила

    1. Баланс это число
    2. Баланс не может быть меньше нуля
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA,
    любые проверки можно делать на этом этапе: userRepository.save(user);

    - Нарушает разделение ответственности.
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA, Методы не генерирую, только свойства, в частности геттеры в рамках обхода дублирования.
    - Мне придётся пересмотреть архитектуру, что-то я тут не то делаю.
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA, И где в таком случае мне эти проверки делать?
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA
    Alexandroppolus

    Запутался. Вот подробности:

    Слоёная архитектура:
    presentation (1)
    application (2)
    domain (3)
    repository (4)
    model (5)

    Всё кроме model, по задумке, классы с методами.

    * - множество

    1.method => 2.method* => 3.method* => 4.method* => model

    1 - просто принимает запросы и вызывает нужный сценарий из 2 или что-то конкретное из 3.
    2 - хранит сценарии где пересекаются несколько сервисов из 3, чтобы не создавать циклических зависимостей.
    3 - хранит бизнес-логику, диктует интерфейс 4, вызывает 4
    4 - абстракция для 5
    5 - база / orm

    Класс User в этом случае находится в 3, он должен инкапсулировать своё состояние и бизнес-логику.
    - Возможно я изначально пошёл не туда.

    const user = userRepository.getById(123);
    user.changeFirstname('John2'); // проверяем вход => записываем в User.firstname
    userRepository.save(user);


    Что не так с классами?
    - Объект поставит меня ровно в туже ситуацию, ведь класс это синтаксический сахар над ним.
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA, геттеры нужны на случай если исходное имя поля изменится, чтобы ничего в публичном апи не сломалось.

    Или же вообще ничего не делать, всё равно с базы тебе уникальный объект придёт,

    - Это понятно, но изменяться будет он-же, он же и хранит логику для полей.

    Прокси хорошо - но от дублирования не спасает, а это основная проблема сейчас.

    хочется классы, запихни в свойство класса сгенерированные геттеры

    - Потеряется user.field, user.v.field странно выглядит.
    Написано
  • Как типизировать созданные геттеры?

    @historydev Автор вопроса
    WbICHA, Планируется примерно следующая схема:
    const user = userRepository.getById(123); // get user from db, return User
    user.changeFirstname('John2'); // validate, write
    userRepository.save(user); // update user in db
    Написано