Создание ивента требует его обработки. Unit of Work не может этим заниматься, так как его задача - сохранять атомарность транзакций. Если он будет дополнительно обрабатывать ивенты, нарушится принцип единственной ответственности по SOLID.
Безусловно, возлагать обработку событий на Unit of Work - это было бы ошибкой проектирования. Но и к Single Responsibility Principle из SOLID это имеет весьма слабое отношение.
Несколько лет назад стоял выбор, пойти в сторону Kotlin или Scala, тогда я выбрал Kotlin. Первое время, после Java, это казалось как глоток свежего воздуха. Но потом особую разницу ощущать перестал. Спустя время, я таки решил попробовать Scala. И вот тогда-то для меня и открылся новый мир. С тех пор Kotlin ушёл на второй план, и я по-прежнему кайфую от работы со Scala. Да, понимаю что многие считают Scala чем то оверинжиниринговым, и я наверное с этим даже соглашусь. Но кайф в том, что Scala не заставляет тебя писать такой код, но она позволяет это делать, и делать это приятно.
Котлин оставил приятные воспоминания. Не вижу причин отказываться от Java, как и не вижу причин не использовать Scala или Kotlin. Спасибо за статью.
Есть у меня хороший знакомый, думаю не только у меня, так как его историю можно загуглить если постараться. Так вот, он прошёл все этапы в Яндекс, получил оффер, и... Отказал, отказал Яндексу! Прошёл из принципа, через всю эту дурацкую бюрократическую, и не только, процедуру, что бы отказать!
Очень многое зависит от самого специалиста. Например, если специалист совсем начинающий, то он будет рассматривать любые предложения в не зависимости от агентства или от компании напрямую. И мифы его интересуют мало, главное результат — получить работу.
Специалист по "матерей", все еще нуждается в самостоятельном поиске работы (по причине своей неизвестности и не авторитетности), на сайтах вакансий выставит фильтр "не показывать вакансии от агенств", ибо он понимает, что компании в которых он хотел бы работать к услугам кадровых агентств не прибегают, соответственно мифы о таковых его уже не интересуют, как и сами агентства.
Ну и третий тип. Это когда специалист уже опытный, уверенный в своих скиллах, поработавший в именитых или околоименитых компаниях, обросший связями, он работу в общем то себе особо не ищет. Она у него есть и он волен принимать или не принимать предложения если таковые поступают.
Я конечно не специалист по подбору персонала, но что-то мне подсказывает что "разрушать" или "подтверждать" мифы о кадровых агентствах само по себе занятие весьма бестолковое, т.к. повлияет это разве что на тех, кто только начинает свою карьеру. И то возможно на совсем "зеленых" ибо читай первый абзац комментария.
Составление сколь угодно исчерпывающего брифа, никак не гарантирует что заказчик на выходе получит то что он хотел. И проблема тут вовсе не в подробном ТЗ или брифе, проблема в методологии. Автору поста крайне рекомендую ознакомиться для начала с манифестом agile, ну а потом уже и с самим agile. Из простого — "Роберт Мартин — Чистый Agile". Все давным-давно придумано и успешно применяется многими на практике. Но тут главное не перегибать палку, иначе любая гибкая методология может стать скорее обузой, нежели полезным инструментом. Успехов!
Domain Driven Design. Частично в статье DDD описывается, но только частично. Конечно серебряной пули не существует, но вы судя по всему выработали свою методологию с оглядкой на существующие.
Вот хочу купить! Вот честное слово, хочу купить. Но, ребята, у меня к вам один вопрос. Лет так 5 назад, я установил себе на смарт Яндекс Клавиатуру скачав с какой-то apk помойки, потому-что В ней у единственной на тот момент (да и сейчас по моему) была функция ввода латиницы глядя на кириллицу. Потом я приобрел новый смартфон. apk потерял. Решил посмотреть клавиатуру в Google Play. Нашел новую Яндекс Клавиатуру. Обрадовался, установил. Но в ней эту функцию выпилили. Зато навешали рюшечек. И я на тот момент перепробовал все клавиатуры из Google Play но так и не нашел с такой фичей. Мне ничего не оставалось как искать эту клавиатуру по apk помойкам устанавливая каждую версию и проверяя наличия фичи. Нашел остановившись на версии 1.01. На данный момент, на моем уже несколько раз смененном смартфоне, стоит именно эта клавиатура. Может конечно уже давно есть в маркете другие клавиатуры с этой фичей, но искать я не хочу. Работает — не трож (хотя бывает падает). Так вот, скажите, если я куплю у вас этот новый девайс, мне что, придется продолжить эту традицию? Доколе? Я понимаю, может фича не востребована, но зачем вы ее выпилили? Или она была впилина назад?
Обновился вчера на SE 2022, полёт нормальный, никаких косяков не заметил. Батарея держится как обычно. Повезло.
Очередная новость, в которой автор не удосужился ни слова сказать о том, а что же это вообще такое эта ваша ажура.
Я правильно понимаю, "сущности" будут иммутабельными?
Безусловно, возлагать обработку событий на Unit of Work - это было бы ошибкой проектирования. Но и к Single Responsibility Principle из SOLID это имеет весьма слабое отношение.
Несколько лет назад стоял выбор, пойти в сторону Kotlin или Scala, тогда я выбрал Kotlin. Первое время, после Java, это казалось как глоток свежего воздуха. Но потом особую разницу ощущать перестал. Спустя время, я таки решил попробовать Scala. И вот тогда-то для меня и открылся новый мир. С тех пор Kotlin ушёл на второй план, и я по-прежнему кайфую от работы со Scala. Да, понимаю что многие считают Scala чем то оверинжиниринговым, и я наверное с этим даже соглашусь. Но кайф в том, что Scala не заставляет тебя писать такой код, но она позволяет это делать, и делать это приятно.
Котлин оставил приятные воспоминания. Не вижу причин отказываться от Java, как и не вижу причин не использовать Scala или Kotlin. Спасибо за статью.
Сначала уже думал всё, нужно брать. Но потом дошёл до пункта:
Спасибо, наверное обойдусь. Я ожидал, ну баксов 250-300, но не 1200.
Не забудьте в письме указать чей Крым.
Мда. Судя по тизеру, игра существует только на бумаге.
Есть у меня хороший знакомый, думаю не только у меня, так как его историю можно загуглить если постараться. Так вот, он прошёл все этапы в Яндекс, получил оффер, и... Отказал, отказал Яндексу! Прошёл из принципа, через всю эту дурацкую бюрократическую, и не только, процедуру, что бы отказать!
Очень многое зависит от самого специалиста. Например, если специалист совсем начинающий, то он будет рассматривать любые предложения в не зависимости от агентства или от компании напрямую. И мифы его интересуют мало, главное результат — получить работу.
Специалист по "матерей", все еще нуждается в самостоятельном поиске работы (по причине своей неизвестности и не авторитетности), на сайтах вакансий выставит фильтр "не показывать вакансии от агенств", ибо он понимает, что компании в которых он хотел бы работать к услугам кадровых агентств не прибегают, соответственно мифы о таковых его уже не интересуют, как и сами агентства.
Ну и третий тип. Это когда специалист уже опытный, уверенный в своих скиллах, поработавший в именитых или околоименитых компаниях, обросший связями, он работу в общем то себе особо не ищет. Она у него есть и он волен принимать или не принимать предложения если таковые поступают.
Я конечно не специалист по подбору персонала, но что-то мне подсказывает что "разрушать" или "подтверждать" мифы о кадровых агентствах само по себе занятие весьма бестолковое, т.к. повлияет это разве что на тех, кто только начинает свою карьеру. И то возможно на совсем "зеленых" ибо читай первый абзац комментария.
Составление сколь угодно исчерпывающего брифа, никак не гарантирует что заказчик на выходе получит то что он хотел. И проблема тут вовсе не в подробном ТЗ или брифе, проблема в методологии. Автору поста крайне рекомендую ознакомиться для начала с манифестом agile, ну а потом уже и с самим agile. Из простого — "Роберт Мартин — Чистый Agile". Все давным-давно придумано и успешно применяется многими на практике. Но тут главное не перегибать палку, иначе любая гибкая методология может стать скорее обузой, нежели полезным инструментом. Успехов!
Где вы это откопали? Пользоваться такими инструментами попросту опасно.