В Composer 2 давно применяется многопроцессная обработка пакетов. Ну и судя по исходному коду, данное творение целиком и полностью написано нейронкой, и это ни хорошо ни плохо. Скорее плохо, так как вероятность что проект будет заброшен или в нём не будут исправляться найденные ошибки (ввиду того что автор свой код сам не писал) очень велика. Но попытка интересная.
Ничего удивительного. Господа из PVS Studio всегда считают себя "самыми умными" и делают такого рода финты. Им плевать на пользователей, пиар превыше всего. Потому и тащат на свой сайт. И если вы перейдёте по ссылке, то увидите, что статься там ни о чём.
Финт конечно интересный, но тогда лучше вынести 1 в константу, так как если в проекте используется анализатор, например SonarQube как у нас, то такой код quality gate не пройдёт, ибо magic number
Интересное решение. Но хотелось бы понять, в чём преимущество перед готовыми решениями? Например, ONLYOFFICE DocSpace Community разворачивается в докере в пару кликов, и при этом OpenSource.
Ну и хотелось бы немного высказать своё ИМХО по вашей статье. Как мне кажется, подход ResultTransformer более применим в контексте паттерна Query Object, т. е. когда нам действительно не нужно получать из БД сущности, а нужны некие DTO. То что репозиторий возвращает что-то отличное от сущностей, как мне кажется не есть хорошо.
Не совсем понятно, а причём тут собственно GraphQL? По сути, для статьи достаточно было описать SmsService, всё остальное детали для конкретного проекта. Полагаю что GraphQL притянут за уши, что бы статья совсем уж не выглядела голой рекламой вашего сервиса (впрочем это не помогло).
Ну и конечно же, не могу не отметить "качество" представленного кода, например:
Создание ивента требует его обработки. Unit of Work не может этим заниматься, так как его задача - сохранять атомарность транзакций. Если он будет дополнительно обрабатывать ивенты, нарушится принцип единственной ответственности по SOLID.
Безусловно, возлагать обработку событий на Unit of Work - это было бы ошибкой проектирования. Но и к Single Responsibility Principle из SOLID это имеет весьма слабое отношение.
Несколько лет назад стоял выбор, пойти в сторону Kotlin или Scala, тогда я выбрал Kotlin. Первое время, после Java, это казалось как глоток свежего воздуха. Но потом особую разницу ощущать перестал. Спустя время, я таки решил попробовать Scala. И вот тогда-то для меня и открылся новый мир. С тех пор Kotlin ушёл на второй план, и я по-прежнему кайфую от работы со Scala. Да, понимаю что многие считают Scala чем то оверинжиниринговым, и я наверное с этим даже соглашусь. Но кайф в том, что Scala не заставляет тебя писать такой код, но она позволяет это делать, и делать это приятно.
Котлин оставил приятные воспоминания. Не вижу причин отказываться от Java, как и не вижу причин не использовать Scala или Kotlin. Спасибо за статью.
Есть у меня хороший знакомый, думаю не только у меня, так как его историю можно загуглить если постараться. Так вот, он прошёл все этапы в Яндекс, получил оффер, и... Отказал, отказал Яндексу! Прошёл из принципа, через всю эту дурацкую бюрократическую, и не только, процедуру, что бы отказать!
Очень многое зависит от самого специалиста. Например, если специалист совсем начинающий, то он будет рассматривать любые предложения в не зависимости от агентства или от компании напрямую. И мифы его интересуют мало, главное результат — получить работу.
Специалист по "матерей", все еще нуждается в самостоятельном поиске работы (по причине своей неизвестности и не авторитетности), на сайтах вакансий выставит фильтр "не показывать вакансии от агенств", ибо он понимает, что компании в которых он хотел бы работать к услугам кадровых агентств не прибегают, соответственно мифы о таковых его уже не интересуют, как и сами агентства.
Ну и третий тип. Это когда специалист уже опытный, уверенный в своих скиллах, поработавший в именитых или околоименитых компаниях, обросший связями, он работу в общем то себе особо не ищет. Она у него есть и он волен принимать или не принимать предложения если таковые поступают.
Я конечно не специалист по подбору персонала, но что-то мне подсказывает что "разрушать" или "подтверждать" мифы о кадровых агентствах само по себе занятие весьма бестолковое, т.к. повлияет это разве что на тех, кто только начинает свою карьеру. И то возможно на совсем "зеленых" ибо читай первый абзац комментария.
В Composer 2 давно применяется многопроцессная обработка пакетов. Ну и судя по исходному коду, данное творение целиком и полностью написано нейронкой, и это ни хорошо ни плохо. Скорее плохо, так как вероятность что проект будет заброшен или в нём не будут исправляться найденные ошибки (ввиду того что автор свой код сам не писал) очень велика. Но попытка интересная.
Ничего удивительного. Господа из PVS Studio всегда считают себя "самыми умными" и делают такого рода финты. Им плевать на пользователей, пиар превыше всего. Потому и тащат на свой сайт. И если вы перейдёте по ссылке, то увидите, что статься там ни о чём.
Хмм, я бы взял такую, несмотря на хейт выше. А если они сделают возможность открывать разные документы на разных экранах - то тем более.
Финт конечно интересный, но тогда лучше вынести 1 в константу, так как если в проекте используется анализатор, например SonarQube как у нас, то такой код quality gate не пройдёт, ибо magic number
А что конкретно не понравилось, если не секрет?
Интересное решение. Но хотелось бы понять, в чём преимущество перед готовыми решениями? Например, ONLYOFFICE DocSpace Community разворачивается в докере в пару кликов, и при этом OpenSource.
Здравствуйте! К сожалению, актуальных сравнительных тестов нет, думаю они появятся в следующих статьях.
Коммерческое внедрение есть. Используется как обработчик сообщений из RabbitMQ а так же на более ранней версии реализован телеграм бот.
К сожалению, над проектом работаю один, с конца 2018 года.
Поставил лайк за редактор блок-схем. Очень годная вещь получилась.
Сделайте, пожалуйста, подсветку синтаксиса кода.
Ну и хотелось бы немного высказать своё ИМХО по вашей статье. Как мне кажется, подход ResultTransformer более применим в контексте паттерна Query Object, т. е. когда нам действительно не нужно получать из БД сущности, а нужны некие DTO. То что репозиторий возвращает что-то отличное от сущностей, как мне кажется не есть хорошо.
За статью спасибо.
Не совсем понятно, а причём тут собственно GraphQL? По сути, для статьи достаточно было описать SmsService, всё остальное детали для конкретного проекта. Полагаю что GraphQL притянут за уши, что бы статья совсем уж не выглядела голой рекламой вашего сервиса (впрочем это не помогло).
Ну и конечно же, не могу не отметить "качество" представленного кода, например:
return $invite ? true : false;
Обновился вчера на SE 2022, полёт нормальный, никаких косяков не заметил. Батарея держится как обычно. Повезло.
Очередная новость, в которой автор не удосужился ни слова сказать о том, а что же это вообще такое эта ваша ажура.
Я правильно понимаю, "сущности" будут иммутабельными?
Безусловно, возлагать обработку событий на Unit of Work - это было бы ошибкой проектирования. Но и к Single Responsibility Principle из SOLID это имеет весьма слабое отношение.
Несколько лет назад стоял выбор, пойти в сторону Kotlin или Scala, тогда я выбрал Kotlin. Первое время, после Java, это казалось как глоток свежего воздуха. Но потом особую разницу ощущать перестал. Спустя время, я таки решил попробовать Scala. И вот тогда-то для меня и открылся новый мир. С тех пор Kotlin ушёл на второй план, и я по-прежнему кайфую от работы со Scala. Да, понимаю что многие считают Scala чем то оверинжиниринговым, и я наверное с этим даже соглашусь. Но кайф в том, что Scala не заставляет тебя писать такой код, но она позволяет это делать, и делать это приятно.
Котлин оставил приятные воспоминания. Не вижу причин отказываться от Java, как и не вижу причин не использовать Scala или Kotlin. Спасибо за статью.
Сначала уже думал всё, нужно брать. Но потом дошёл до пункта:
Спасибо, наверное обойдусь. Я ожидал, ну баксов 250-300, но не 1200.
Не забудьте в письме указать чей Крым.
Мда. Судя по тизеру, игра существует только на бумаге.
Есть у меня хороший знакомый, думаю не только у меня, так как его историю можно загуглить если постараться. Так вот, он прошёл все этапы в Яндекс, получил оффер, и... Отказал, отказал Яндексу! Прошёл из принципа, через всю эту дурацкую бюрократическую, и не только, процедуру, что бы отказать!
Очень многое зависит от самого специалиста. Например, если специалист совсем начинающий, то он будет рассматривать любые предложения в не зависимости от агентства или от компании напрямую. И мифы его интересуют мало, главное результат — получить работу.
Специалист по "матерей", все еще нуждается в самостоятельном поиске работы (по причине своей неизвестности и не авторитетности), на сайтах вакансий выставит фильтр "не показывать вакансии от агенств", ибо он понимает, что компании в которых он хотел бы работать к услугам кадровых агентств не прибегают, соответственно мифы о таковых его уже не интересуют, как и сами агентства.
Ну и третий тип. Это когда специалист уже опытный, уверенный в своих скиллах, поработавший в именитых или околоименитых компаниях, обросший связями, он работу в общем то себе особо не ищет. Она у него есть и он волен принимать или не принимать предложения если таковые поступают.
Я конечно не специалист по подбору персонала, но что-то мне подсказывает что "разрушать" или "подтверждать" мифы о кадровых агентствах само по себе занятие весьма бестолковое, т.к. повлияет это разве что на тех, кто только начинает свою карьеру. И то возможно на совсем "зеленых" ибо читай первый абзац комментария.