Список банальностей собран на основе обратной связи от разработчиков, когда они аргументируют свое нежелание работать с легаси-кодом, вроде «это не интересно, там нечему научиться и т.п.». Так что полагаю что было бы недостаточно.
Очень условно.
А сколько именно итераций должно быть? 1 итерация и будет легаси, или надо 2? А если было 10 итераций, но все переделки не были спешные, а в обычном рабочем процессе, то не легаси? Это субъективное восприятие.
Простите, но разве я разве где-то сказал «выключите свои мозги и никогда не дорабатывайте код под свои нужды»? Не говоря уже о каких-то лицензиях.
Если предложенное решение вас не устраивает — сделайте как вам нравится, не вижу тут никакой проблемы.
Абсолютно. Только rabbitMQ, это не только как вы кратко выразились «установка», это поднятие и поддержка сервера, доработка кода с использованием клиента, любая последующая поддержка будет требовать от исполнителя компетенции в использовании rabbitMQ, и так далее.
Согласитесь, что это слегка разные трудозатраты по сравнению php+mysql, особенно для заказчика, который будет искать исполнителя.
Вот вопрос относится не блокировкам как таковым, а скорее к обработке исключительных ситуаций. В случае с select lock for update вы получаете пачку зависающих блокировок (которые в «случае со шваброй» просто будут отпущены), в случае с update set status 'processing', вы получите в базе несколько задач, которые имеют незавершенный статус.
И как и было сказано в статье, их обработка на совести разработчика. Данный пример даже частично выигрывает в возможности обработки исключительных ситуаций, потому как мы можем легко понять в каком статусе мы закончили работу с заданием (соответственно проверить что было сделать и исправить ситуацию). Если же брать select lock..., то там освободившаяся «после швабры» блокировка никак не сообщит что произошло с заданием, даже если оно было полностью выполнено, но мы не успели об этом сообщить базе.
Иногда лучше что-то не сделать и знать об этом, чем сделать два раза ничего не подозревая (например операция со счетом).
Да собственно вы своим вопросом сами себе и ответили.
Действие клиента — простое, бизнес логика за действием — сложная и не обязательно должна быть исполнена мгновенно.
Примеров множество:
Отправка большого числа email сообщений, реиндексация поиска (например при редактировании какой-либо сущности), обновление взаимосвязанных сущностей или таблиц активности (если их логика в силу каких-то причин не могла быть реализована в хранимых функциях базы), взаимодействие со сторонними api, транзакционные действия со счетами и т.д.
Соответственно чтобы не пихать всё в один файл, или же разделять задачи по группам и приоритетам на разных мощностях («мухи отдельно, мёд отдельно»), может пригодится такая реализация.
На проекте есть несколько десятков пользователей. Когда приходит клиент и оставляет заявку, нужно обработать его «корзину», произвести операции со счетами «поставщиков», переформировать кеш, отправить сообщения «поставщикам». Нагрузка именно посетителей — минимальна, так как клиентов мало (не соц. сеть), но заставлять посетителя ждать несколько секунд после нажатия кнопки «Отправить» — кощунство, не говоря уже о перекладывании всей этой работы в клиентский запрос.
В результате имеем достаточно простые операции, но и просто нежелательно выполнять при клиентском запросе. Поднимать ради этого VPS, ставить rabbitMQ, писать скрипты — абсолютно ненужная трата ресурсов, когда абсолютно тоже самое можно реализовать приведенным в статье примером. К тому же это будет значительно проще в поддержке, следовательно дешевле в доработке для заказчика. Соответственно и для разработчика.
Поверьте, есть множество задач которые не требуют внедрения таких комплексных систем. Не говоря уже о поддержке и KIS. У любого растущего проекта всегда есть такая стадия, когда простого cron'a уже мало, а rabbitMQ или Gearman еще не известно понадобятся ли.
Так что говорить «Если вам нужно очереди задач — значит обязательно покупайте соответствующий хостинг и ставьте rabbitMQ», на мой взгляд, как-то опрометчиво. Не согласны?
Демоны имеют совершенно другое назначение. Самый простой пример: когда ваши процессорные мощности ограничены (чтобы не грузить продакшн) и вам нужно обрабатывать данные задания на другом сервере.
Похоже, вы не совсем внимательно прочитали:
> Ограничения: текущая реализация не подходит для persistent соединений, но если кому-то потребуется, несложно допилить.
Собственно возьмите в пример того же Watson'a. Он вполне себе умеет «концептуализировать» часто двусмысленные понятия и находить на них ответы, равно как и человек.
Выделение контекста это как раз часть классификации входного потока данных. И поисковые системы тем же постоянно занимаются. Так что задача не нова.
Так и не увидел причину «препятствие». Что сложность возрастает — да, но это не делает задачу нерешаемо.
Насчет параллельных вычислений имелось ввиду не добавление числа ядер, а создание горизонтального масштабирования.
Оперировать в качестве аргумента «интересной, но ничем не подкрепленной идеей» это несколько неправильно.
Может быть вы бы могли дать больше информации?
Для того чтобы поставить задачу, нужно сперва иметь нерешенную задачу, а для этого нужно иметь какую-то потребность. Ничего не мешает сделать программу, которая будет иметь определенные потребности, и соответственно которая должна заниматься поиском их удовлетворения. Например «Произвести оптимизацию процесса на 5%». Вполне себе нормальная задача.
Разница лишь в том, что все «задачи» человека связаны напрямую с его психикой, в частности с потребностью в выживании, или же например с амбициями. Аналогичное же может быть реализовано и в машине.
Касательно препятствия в последовательной архитектуре фон Неймана, то объясните пожалуйста в чем именно проблема. Желательно на примере. Где именно последовательные исчисления не способны реализовать те же алгоритмы, которые используются человеком?
Пока весь известный мне материал напрямую говорит о том, что человек также делает последовательные выводы.
Про вопросы быстродействия речь отдельная, в конце концов распределенные вычисления вполне себе реальная вещь.
«Самостоятельно»?
Ну во-первых полноценные «самостоятельные машины» это пока еще фантастика. Во-вторых если всё же немного расширить понятие самостоятельности, то можно сказать что машины сделали немало открытий, например открытия «хаббла». Конечно их создали люди, и по сути открытия были сделаны людскими алгоритмами.
Но не вижу никакого препятствия в том, что по мере развития этих алгоритмов в один из моментов мы сможем сказать что машина сделала открытие «самостоятельно».
Все задачи должны решаться по мере их появления. Так что в вашей фразе ключевое слово «пока». Когда возникнет такая необходимость, я уверен, решение будет найдено.
Для человека «делить на части» вполне привычно. Так что что бы мы не имели ввиду, свет увидят скорее всего самые различные реализации, «надо же попробовать, как оно на самом деле».
Тут мы пока все «голые теоретики», как оно будет лучше на самом деле еще предстоит выяснить.
А сколько именно итераций должно быть? 1 итерация и будет легаси, или надо 2? А если было 10 итераций, но все переделки не были спешные, а в обычном рабочем процессе, то не легаси? Это субъективное восприятие.
Если предложенное решение вас не устраивает — сделайте как вам нравится, не вижу тут никакой проблемы.
Согласитесь, что это слегка разные трудозатраты по сравнению php+mysql, особенно для заказчика, который будет искать исполнителя.
И как и было сказано в статье, их обработка на совести разработчика. Данный пример даже частично выигрывает в возможности обработки исключительных ситуаций, потому как мы можем легко понять в каком статусе мы закончили работу с заданием (соответственно проверить что было сделать и исправить ситуацию). Если же брать select lock..., то там освободившаяся «после швабры» блокировка никак не сообщит что произошло с заданием, даже если оно было полностью выполнено, но мы не успели об этом сообщить базе.
Иногда лучше что-то не сделать и знать об этом, чем сделать два раза ничего не подозревая (например операция со счетом).
Действие клиента — простое, бизнес логика за действием — сложная и не обязательно должна быть исполнена мгновенно.
Примеров множество:
Отправка большого числа email сообщений, реиндексация поиска (например при редактировании какой-либо сущности), обновление взаимосвязанных сущностей или таблиц активности (если их логика в силу каких-то причин не могла быть реализована в хранимых функциях базы), взаимодействие со сторонними api, транзакционные действия со счетами и т.д.
Соответственно чтобы не пихать всё в один файл, или же разделять задачи по группам и приоритетам на разных мощностях («мухи отдельно, мёд отдельно»), может пригодится такая реализация.
На проекте есть несколько десятков пользователей. Когда приходит клиент и оставляет заявку, нужно обработать его «корзину», произвести операции со счетами «поставщиков», переформировать кеш, отправить сообщения «поставщикам». Нагрузка именно посетителей — минимальна, так как клиентов мало (не соц. сеть), но заставлять посетителя ждать несколько секунд после нажатия кнопки «Отправить» — кощунство, не говоря уже о перекладывании всей этой работы в клиентский запрос.
В результате имеем достаточно простые операции, но и просто нежелательно выполнять при клиентском запросе. Поднимать ради этого VPS, ставить rabbitMQ, писать скрипты — абсолютно ненужная трата ресурсов, когда абсолютно тоже самое можно реализовать приведенным в статье примером. К тому же это будет значительно проще в поддержке, следовательно дешевле в доработке для заказчика. Соответственно и для разработчика.
Как бы вы решили данный вопрос?
Так что говорить «Если вам нужно очереди задач — значит обязательно покупайте соответствующий хостинг и ставьте rabbitMQ», на мой взгляд, как-то опрометчиво. Не согласны?
> Ограничения: текущая реализация не подходит для persistent соединений, но если кому-то потребуется, несложно допилить.
Выделение контекста это как раз часть классификации входного потока данных. И поисковые системы тем же постоянно занимаются. Так что задача не нова.
Насчет параллельных вычислений имелось ввиду не добавление числа ядер, а создание горизонтального масштабирования.
Может быть вы бы могли дать больше информации?
Разница лишь в том, что все «задачи» человека связаны напрямую с его психикой, в частности с потребностью в выживании, или же например с амбициями. Аналогичное же может быть реализовано и в машине.
Касательно препятствия в последовательной архитектуре фон Неймана, то объясните пожалуйста в чем именно проблема. Желательно на примере. Где именно последовательные исчисления не способны реализовать те же алгоритмы, которые используются человеком?
Пока весь известный мне материал напрямую говорит о том, что человек также делает последовательные выводы.
Про вопросы быстродействия речь отдельная, в конце концов распределенные вычисления вполне себе реальная вещь.
Ну во-первых полноценные «самостоятельные машины» это пока еще фантастика. Во-вторых если всё же немного расширить понятие самостоятельности, то можно сказать что машины сделали немало открытий, например открытия «хаббла». Конечно их создали люди, и по сути открытия были сделаны людскими алгоритмами.
Но не вижу никакого препятствия в том, что по мере развития этих алгоритмов в один из моментов мы сможем сказать что машина сделала открытие «самостоятельно».
Тут мы пока все «голые теоретики», как оно будет лучше на самом деле еще предстоит выяснить.