А как же post rock. Для себя долго подбирал разное, остановился на пост роке. Без слов, достаточно энергии, чтобы не закисать в процессе работы. При этом достаточно монотонно, чтобы не отвлекаться от работы.
Идея с листенерами мне нравится. Получается более универсальный вариант. Нужно ли их использовать — опять же по ситуации. В коде появляется подписка на события, При добавлении нового таска надо не забывать на него подписаться там где необходимо.
Например, взвесив за и против, для нынешнего проекта я предпочту вариант с pipeline. Для другого проекта с еще более витиеватой логикой возможно лучше подойдет вариант с листенерами.
Да, можно и так. Но у меня жесткого связывания нет, логику управления задачами я как раз вынес за пределы задач. С листенерами получится примерно так же — надо передавать данные и информацию о том, в рамках какого процесса сейчас идет обработка данных, если нужно, чтобы одну и ту же задачу можно было использовать в разных процессах.
Вот пример. Из внешнего сервиса прилетает новый документ на обработку. Нужно найти в нем ключевые слова, определить их тональность, сделать еще ряд манипуляций. Это делается через очереди. Каждая задача — в своей очереди. И эта цепочка как раз описана в отдельном потомке PipelineAbstract.
Помимо этого иногда надо повторно обработать старые документы. В этом случае происходит почти то же самое, но немножко по другому. Чтобы не плодить условия внутри джобов или сами джобы, оказалось очень удобно сделать второй наследник PipelineAbstract и там описать процесс повторной обработки материала.
Я в статье объяснил, почему это оказалось не удобно.
Насчет карты, можно. Это будет чуть ближе к варианту со штатным withChain(). Это уже дело техники и предпочтений, и зависит от ситуации. В моем случае, как я упоминал выше, есть элементы бизнес логики, иногда надо создавать 1 джоб, иногда сразу группу джобов, с разными входными данными, тут практичнее использовать условия.
Вы про метод next()? Не думал как тут можно обойтись без условий. Он вызывается из каждого джоба одинаковым способом. Внутри этого метода надо как-то понять, что делать дальше исходя из того, на какой стадии сейчас находимся. От этого и возникают условия. Тут получается этакая фабрика джобов. На мой взгляд наличие условий в этом методе — не страшно. Но если есть идеи как избавиться тут от if-ов, буду рад.
Тут я даже больше скажу. В альфа версии ангуляра были именованные роуты. И в документации даже была рекомендация пользоваться ими. И на примере объяснялось, почему это так удобно. Когда я обновлял ангуляр в своем проекте до стабильной версии, я был удивлен, с какой стати именованные роуты выпилили. Такой непоследовательности в разработке я искренне не понимаю.
Сказали примерно так — «Используйте обходные пути, но уже вне рамках поддержки билайн». В общем, отказаться от их услуги защиты меня от нежелательных (и желательных) ресурсов пока что увы, не удалось.
Сегодня позвонил специалист из поддержки Билайн и сказал, что у них такие внутренние распоряжения — блокировать весь IP адрес. Почему не могут блокировать более аккуратно — ответить затруднился, ссылаясь на то, что не знает всех технических особенностей. В разговоре употреблял слова «закон» и тому подобные. Но ссылку на закон прислать тоже затруднился. И предложил использовать обходные пути.
Сегодня как раз столкнулся с тем, что работая через Билайн не удается открыть страничку octobercms.com. Оказывается, на том же IP адресе находилась какая-то букмекерская контора и по решению суда заблокировали весь этот IP. Что тут можно сказать про такую работу Роскомнадзора… Три буквы (не ура).
Тут большая часть списка:
https://music.yandex.ru/users/mnvx/artists
Буду рад, если тоже поделитесь
А как же post rock. Для себя долго подбирал разное, остановился на пост роке. Без слов, достаточно энергии, чтобы не закисать в процессе работы. При этом достаточно монотонно, чтобы не отвлекаться от работы.
Ответ в последнем абзаце.
Идея с листенерами мне нравится. Получается более универсальный вариант. Нужно ли их использовать — опять же по ситуации. В коде появляется подписка на события, При добавлении нового таска надо не забывать на него подписаться там где необходимо.
Например, взвесив за и против, для нынешнего проекта я предпочту вариант с pipeline. Для другого проекта с еще более витиеватой логикой возможно лучше подойдет вариант с листенерами.
Да, можно и так. Но у меня жесткого связывания нет, логику управления задачами я как раз вынес за пределы задач. С листенерами получится примерно так же — надо передавать данные и информацию о том, в рамках какого процесса сейчас идет обработка данных, если нужно, чтобы одну и ту же задачу можно было использовать в разных процессах.
Вот пример. Из внешнего сервиса прилетает новый документ на обработку. Нужно найти в нем ключевые слова, определить их тональность, сделать еще ряд манипуляций. Это делается через очереди. Каждая задача — в своей очереди. И эта цепочка как раз описана в отдельном потомке
PipelineAbstract.Помимо этого иногда надо повторно обработать старые документы. В этом случае происходит почти то же самое, но немножко по другому. Чтобы не плодить условия внутри джобов или сами джобы, оказалось очень удобно сделать второй наследник
PipelineAbstractи там описать процесс повторной обработки материала.Я в статье объяснил, почему это оказалось не удобно.
Насчет карты, можно. Это будет чуть ближе к варианту со штатным
withChain(). Это уже дело техники и предпочтений, и зависит от ситуации. В моем случае, как я упоминал выше, есть элементы бизнес логики, иногда надо создавать 1 джоб, иногда сразу группу джобов, с разными входными данными, тут практичнее использовать условия.Вы про метод
next()? Не думал как тут можно обойтись без условий. Он вызывается из каждого джоба одинаковым способом. Внутри этого метода надо как-то понять, что делать дальше исходя из того, на какой стадии сейчас находимся. От этого и возникают условия. Тут получается этакая фабрика джобов. На мой взгляд наличие условий в этом методе — не страшно. Но если есть идеи как избавиться тут от if-ов, буду рад.Вот так:
На графиках суммы после вычета налогов (на руки) или до?
Вряд ли
Спасибо, попробую как будет возможность. Обертка для PHP не помешает.
Теперь по умолчанию в связке с Vue поставляется небезызвестный Laravel. Это тоже должно повлиять на популярность Vue в том числе и на hh.
Тут я даже больше скажу. В альфа версии ангуляра были именованные роуты. И в документации даже была рекомендация пользоваться ими. И на примере объяснялось, почему это так удобно. Когда я обновлял ангуляр в своем проекте до стабильной версии, я был удивлен, с какой стати именованные роуты выпилили. Такой непоследовательности в разработке я искренне не понимаю.
Спасибо, что передали идею, но прошло уже 3 месяца, а уведомлений о приходах пока не появилось.
Видимо автор под термином "объект модели" понимает класс, в котором описывается сущность.