The image is from a scene set in a traditional pub or bar, with four individuals seated around a small round table, each holding a pint of beer. There's also a packet of cigarettes on the table. It is a screenshot from the 1972 television show "Love Thy Neighbour," and the overlaid text suggests a reaction of surprise or disapproval, reflecting on the norms and broadcast standards of that era.
Предпочитаю varchar и constraint(по необходимости).
Не люблю инты в силу того, что через некоторое время хрен разберёшь что за status=4 и для интерпретации данных из таблицы, всё время приходится обращаться к энамам из приложения.
Только одна вещь раздражает в RuStore -- когда пытаюсь обновить все приложения через магазин, он в том числе пытается обновить приложения, которые были "заморожены" из-за очень редкого использования (Телефон от Samsung, s21). И каждый раз это долгое скачивание, попытка установить, куча потраченного времени и "ошибка обновления" :(
Всегда было интересно, какова вероятность ошибки у таких систем?
Одно дело когда к моему айфону физически имеют доступ я и еще 30 человек. Но к таким камерам имеет доступ неограниченный круг лиц, считай десятки миллионов.
array<array-key,WeakReference<T>> -- GC будет чистить значение внутри WR, а сам массив будет расти потихоньку (если его не чистить руками, но в чём тогда смысл брать WR).
А на основе WeakMap -- там же объекты в ключах, значит идентификатор кешируемого объекта будет в значении, т.е. надо будет итерироваться чтобы найти нужное, т.е. O(n).
Ну для небольших карт это прокатит, но в целом решение не масштабируемое.
В сборе они выполняют только часть верхнеуровневой задачи, это не целая ручка.
Как пример: цепочка прасеров чего либо.
Есть класс, который в конструктор получает регулярку. И таких классов N-штук. Классы одинаковые — регулярки разные.
Все эти классы списком заинжекчены в ChainOfResponsibility, который будет идти по списку до тех пор, пока мы не выпарсим что-то внятное.
Вся эта конструкция, и в том числе регулярки, описаны в контейнере.
Тестить классы сами по себе бессмысленно, нужно доставать из контейнера чейн и тестить его, причём вместе с конфигами, которые прокидываются через контейнер.
А бывают такие случаи, что там где-то графе зависимостей контейнера, зачесался еще и репозиторий, и в контейнере его уже не так просто замокать. Так как тесты должны быть независимыми друг от друга, то лучше контейнер потом пересобрать, что крайне долго.
Например есть такой кейс:
есть набор классов, которые по раздельности, наверно, не особо имеет смысл тестить — они слишком маленькие.
возможно намельчили в разбиении и в понимании «единичной ответственности», но что есть то есть.
эти классы связываются через ди-конейнер, через него же туда прокидываются недостающие примитивы параметров — всякого рода костанты.
в итоге, этот микро-граф классов образует уже что-то пригодное для blackbox-тестирования, без вдавания в подробности реализации классов.
* получается, в тесте надо собирать эти классы вместе, для того чтобы начать их тестить, но если кто-то из разработчиков поменяет конфиг ди-контейнера, то тест станет неактуальным, хотя и продолжит отдавать зелёные результаты.
* другой вариант — доставать эти классики прямо из ди-контейнера в тесте, но тогда возникает вопрос — как замокать репозитории и прочие внешние зависимости в ди-контейнере, без постоянной пересборки его на каждый тест(медленно)
Не сталкивались с таким? Можете что-то посоветовать?
Как-то мало инфы в интернетах о krakjoe/parallel.
Выглядит как очень крутая штука.
Хотелось бы какой то обзор — плюсы, минусы, примеры использования.
Очень похоже на то что есть в голанге.
Неудобно что в Unit-тестах с аннотацией @expectedException всё равно требует try-catch или @throws, а отключить это инспекцию, как понял, можно только на весь проект.
Но какой же может быть cohesion внутри модуля между слоями?
DDD Quickly:
While cohesion starts at the class and method level, it can be applied at module level. It is recommended to group highly related classes into modules to provide maximum cohesion possible.
Но тут опять же ничего не сказано про другие слои. Я могу интерпретировать эту фразу как: связывай доменные модели, но не делай связи между слоями внутри модуля.
Модули внутри модели являются именованными контейнерами для некоторой группы объектов предметной области
For a large and complex application, the model tends to grow bigger and bigger. The model reaches a point where it is hard to talk about as a whole, and understanding the relationships and interactions between different parts becomes difficult. For that reason, it is necessary to organize the model into modules.
Здесь, в статье, и в DDD Quickly везде написано что «Модуль» включается в себя разбитую на куски «Модель» когда она слишком разрастается.
Это не доменная модель? Что это за модель тогда? «Модель» = «модель всей предметной области» = «всё моё приложение»? Если так, то да — всё приложение целиком включает в себя любые необходимые слои. Но если имеется ввиду разбиение именно доменной модели, то тут не могут быть никакие другие слои, кроме непосредственно доменного.
Модуль в понятиях DDD может ли содержать в себе сервисы из инфраструктурного или слоя приложения?
Условно говоря — модуль «оформления заказа» имеет в себе, помимо доменных моделей, ещё и инфраструктурные шлюзы оплаты или что-либо в таком духе.
А у меня вполне достойный результат выдаёт
The image is from a scene set in a traditional pub or bar, with four
individuals seated around a small round table, each holding a pint of
beer. There's also a packet of cigarettes on the table. It is a
screenshot from the 1972 television show "Love Thy Neighbour," and the
overlaid text suggests a reaction of surprise or disapproval, reflecting
on the norms and broadcast standards of that era.
Звучит как transactional outbox паттерн
надо запускать приложение ИЗ файловой системы линукс, а не винды.
тогда работает ровно с такой скоростью, как если бы было запущено на нативном линуксе.
По ttl на пакетах
Предпочитаю varchar и constraint(по необходимости).
Не люблю инты в силу того, что через некоторое время хрен разберёшь что за status=4 и для интерпретации данных из таблицы, всё время приходится обращаться к энамам из приложения.
Только одна вещь раздражает в RuStore -- когда пытаюсь обновить все приложения через магазин, он в том числе пытается обновить приложения, которые были "заморожены" из-за очень редкого использования (Телефон от Samsung, s21). И каждый раз это долгое скачивание, попытка установить, куча потраченного времени и "ошибка обновления" :(
Всегда было интересно, какова вероятность ошибки у таких систем?
Одно дело когда к моему айфону физически имеют доступ я и еще 30 человек. Но к таким камерам имеет доступ неограниченный круг лиц, считай десятки миллионов.
Кейсы --
Ложно положительные:
Как обстоят дела с близнецами?
А с очень похожими людьми?
Ложно отрицательные:
А если у меня вскочит большой прыщ на лице?
Если я опухну после попойки?
array<array-key,WeakReference<T>> -- GC будет чистить значение внутри WR, а сам массив будет расти потихоньку (если его не чистить руками, но в чём тогда смысл брать WR).
А на основе WeakMap -- там же объекты в ключах, значит идентификатор кешируемого объекта будет в значении, т.е. надо будет итерироваться чтобы найти нужное, т.е. O(n).
Ну для небольших карт это прокатит, но в целом решение не масштабируемое.
По поводу структур данных.
С удивлением обнаружил что есть WeakMap, но нет WeakHashMap что сильно сужает количество кейсов для создания например кеша на основе WeakReference'ов.
Очень странное решение!
Как пример: цепочка прасеров чего либо.
Есть класс, который в конструктор получает регулярку. И таких классов N-штук. Классы одинаковые — регулярки разные.
Все эти классы списком заинжекчены в ChainOfResponsibility, который будет идти по списку до тех пор, пока мы не выпарсим что-то внятное.
Вся эта конструкция, и в том числе регулярки, описаны в контейнере.
Тестить классы сами по себе бессмысленно, нужно доставать из контейнера чейн и тестить его, причём вместе с конфигами, которые прокидываются через контейнер.
А бывают такие случаи, что там где-то графе зависимостей контейнера, зачесался еще и репозиторий, и в контейнере его уже не так просто замокать. Так как тесты должны быть независимыми друг от друга, то лучше контейнер потом пересобрать, что крайне долго.
есть набор классов, которые по раздельности, наверно, не особо имеет смысл тестить — они слишком маленькие.
возможно намельчили в разбиении и в понимании «единичной ответственности», но что есть то есть.
эти классы связываются через ди-конейнер, через него же туда прокидываются недостающие примитивы параметров — всякого рода костанты.
в итоге, этот микро-граф классов образует уже что-то пригодное для blackbox-тестирования, без вдавания в подробности реализации классов.
* получается, в тесте надо собирать эти классы вместе, для того чтобы начать их тестить, но если кто-то из разработчиков поменяет конфиг ди-контейнера, то тест станет неактуальным, хотя и продолжит отдавать зелёные результаты.
* другой вариант — доставать эти классики прямо из ди-контейнера в тесте, но тогда возникает вопрос — как замокать репозитории и прочие внешние зависимости в ди-контейнере, без постоянной пересборки его на каждый тест(медленно)
Не сталкивались с таким? Можете что-то посоветовать?
Выглядит как очень крутая штука.
Хотелось бы какой то обзор — плюсы, минусы, примеры использования.
Очень похоже на то что есть в голанге.
DDD Quickly:
Но тут опять же ничего не сказано про другие слои. Я могу интерпретировать эту фразу как: связывай доменные модели, но не делай связи между слоями внутри модуля.
Здесь, в статье, и в DDD Quickly везде написано что «Модуль» включается в себя разбитую на куски «Модель» когда она слишком разрастается.
Это не доменная модель? Что это за модель тогда? «Модель» = «модель всей предметной области» = «всё моё приложение»? Если так, то да — всё приложение целиком включает в себя любые необходимые слои. Но если имеется ввиду разбиение именно доменной модели, то тут не могут быть никакие другие слои, кроме непосредственно доменного.
Условно говоря — модуль «оформления заказа» имеет в себе, помимо доменных моделей, ещё и инфраструктурные шлюзы оплаты или что-либо в таком духе.