Хоть на shell. Вопрос в том что он будет делать.

Поисковик, погода, перевод или что то такое, на этом уровне.

Тут вроде тема про ядро на html'е была...

А чем этот ЯП отличается от других?

Сходить в сеть за текстом можно на чём угодно. Поисковик где и чего? А вообще если для написания демона на PHP требуется моё разрешение, то я разрешаю. По крайней мере jabber-бот на нём написать никто не мешает.

>Насколько оправдано и качественно это может получиться? Например, написание jabber бота. (говорят, демоны на пхп не пишут)

Говорят, в моськве кур доят,

А пришли - привет, isden...

только не очень понятно, почему этот ваш бот должен постоянно висеть в памяти как демон? Не проще-ли его привинтить к клиенту? Хотя это совсем не относится к ЯП... Пишите, какая разница? У мну сейчас демон на Java висит, чем php хуже?

оправданно иногда

Вот, kanicq вроде бы такой и использует (да-да, б-гомерский icq-сервис)

>говорят, демоны на пхп не пишут

говорят, пых течет

Нинасколько. Совершенно непригодное средство для такой задачи.

Помнится, у php нету сборщика мусора (или он ооочень кривой), поэтому через хотя бы сутки аптайма вся оперативная память будет им занята :)

PS. Информация двухлетней давности (наверное), сейчас, может быть, что-нибудь исправили.

Говорят, что если мусор не плодить, то ничего и собирать не надо.

>Помнится, у php нету сборщика мусора (или он ооочень кривой), поэтому через хотя бы сутки аптайма вся оперативная память будет им занята :)

PS. Информация двухлетней давности (наверное), сейчас, может быть, что-нибудь исправили.

Вот именно, что 2х летней. В пыхе нету GC в том понимании, в каком он есть, к примеру, в Java. Там идет управление памятью на уровне областей видимости переменных (вышел из функции - локальные переменные удаляются) + подсчет ссылок. + же еще технология copy-on-write (lazy-copy). Поэтому попробовать можно. Но! Я бы для такого дела использовал бы все-таки python. Ибо будет красивее. Php заточен под Web.

Хм, спасибо, что просветили, буду знать. И да, плюсую питон (или перл на крайний случай, ибо ближе к php).

2 uRandom: если хорошо погуглить, можно найти множество реализаций jabber ботов на php.

Вот тут http://www.ibm.com/developerworks/opensource/library/os-php-5.3new1/index.htm... говорят, что GC в 5.3 наконец научился удалять циклические ссылки.

Но возьми-ка лучше питон, как по мне, куда более подходящий иструмент. Да и наверняка уже есть написанный нужный питонодемон.

Довольно странное желание - писать демона на языке, который by design (я, правда, не уверен, что там вообще хоть какой-то дизайн был) является движком-шаблонизатором.

Да еще и jabber-бота. twisted.words/wokkel - и вперед.

>Говорят, что если мусор не плодить, то ничего и собирать не надо.

в пыхе даже если за собой убирать (удалять переменные), то все равно протекает. Просто язычок рассчитан на другой круг задач, оптимизацией в этой области никто нормально не занимался.

И таки мусор в пхп не плодить можно только в хелловорлде. Тут даже объект по-человечески удалить нельзя.

Собственно уже все сказали. Он течет и ничего ты с этим не поделаешь, даже 5.3.

> И таки мусор в пхп не плодить можно только в хелловорлде. Тут даже объект по-человечески удалить нельзя.

Есть скрипт, занимается обработкой FBL, асинхронных bounce и прочей хренью, uptime где-то три с половиной месяца. И не течёт! Причём OOP активно используется. PHP 5.1.6 или что-то такое

Есть другой скрипт, занимается data scraping. В силу специфики задачи там получаются сотни тысяч запросов к сайтам, анализ данных, распихивание результатов в БД. Тоже ООП. Работает почти месяц. PHP 5.3.3. Потребление памяти минимально, RSS процесса со временем не растёт.

Есть третий скрипт, рассылка почты. Судя по логам, отправляем около 2-2.5 миллионов сообщений в сутки. Email Marketing. Может работать неделями и не течет.

Вот расскажите мне, как так получается писать, что вокруг всё течет? Реально интересно посмотреть на простой протекающий пример.

2-2.5 миллионов сообщений в сутки.

Email Marketing

Вот как это теперь называется. Буду знать.

А у меня обратный пример. Для индексирования больших объемов данных нашему лиду пришлось городить map/reduce на форках, потому что последовательная обработка всего датасета приводила к memory_limit. И fcgi воркеры живут совсем недолго, слава богу, php-fpm очень гладко их может отстреливать, чтоб сервер чувствовал себя уютно по памяти.

>говорят, пых течет

В 5.3 полностью сборщик мусора переписали. Теперь он кольцевые ссылки корректно разруливает.

Но и раньше можно было делать мелкое ядро, а все события с хитрой внутренней работой с памятью обрабатывать в форках. Форки по завершении работы отдают всю память.

Google -> phpdaemon

Его используют, и демонов делать вполне реально. Но если у вас руки от веба растут, есть смысл присмотреться к жабаскрипту (node.js).

Пока в php не появятся weakrefs, ни о каком серьезном управлении памятью не может быть и речи, так, одно баловство.

>Пока в php не появятся weakrefs

А по-русски?

так, одно баловство.

Есть ряд задач, где PHP в роли демона отлично справляется со своими задачами. А кому важны шашечки - безусловно могут выбирать себе другой цвет :D

А по-русски?

Слабые ссылки, если в терминах сборщика мусора, основанного на подсчете ссылок, то сохранение такого указателя на объект не влечет увеличение счетчика ссылок. Или это указание gc, что объект, на который остались только слабые ссылки можно удалить.

Зачастую, так ссылаются на всякие менеджеры, диспатчеры, соединения..., чтоб позволить им спокойненько собраться невзирая на связанные с ними прикладные объекты. Так же через weakrefs передаются методы объектов, выступающие как коллбэки, опять таки для безпрепятсвенного сбора мусора. Применений на самом деле масса.

Есть ряд задач, где PHP в роли демона отлично справляется со своими задачами.

Ну, в общем-то это вопрос из разряда, код на каких языках может поддерживать команда. Если это только PHP, то можно, если осторожно. Но если дело касается надежных демонов, которые способны работать годами, то только java (jvm по-сути), дешевая, сердитая и без сюрпризов.

Но если дело касается надежных демонов, которые способны работать годами, то только java (jvm по-сути), дешевая, сердитая и без сюрпризов.

Вот это едва ли. Ява течёт так же как и динамические ЯП. Точнее, течёт неправильно написанный код и от этого избавиться средствами ЯП нельзя. Обычно принято просто делить демон на мастер процесс и рабочие процессы с принудительным ограничением времени жизни последних. Эта схема работает отлично практически для любых ЯП и задач, где такое функциональное деление демона допустимо.

Работа годами практически всегда достигается только избыточностью и резервированием служб.

>Точнее, течёт неправильно написанный код и от этого избавиться средствами ЯП нельзя.

Это да... В L2J я, как минимум, пару раз в месяц проводил жёсткую ревизию и нередко находил множество утечек, допущенных менее внимательными членами команды. Иногда - очень сильных утечек. Самый любимый приём у народа - зарегистрировать у глобального синглетона объект и забыть его освободить, когда не нужен...

Точнее, течёт неправильно написанный код и от этого избавиться средствами ЯП нельзя.

Имеются ввиду ошибки реализации (то есть утечки в самой jvm) или убывание permgen контейнера? Если последнее, то к демонам это не имеет никакого отношения.

Забыл самый главный аргумент. Легкость профилирования утечек. Я имею ввиду возможность дампа памяти — распределение кучи по типам экземпляров и построение графа ссылок. Для jvm такие средства есть, для PHP нет (вернее не было, когда с ним еще работал).

Ведь, как правило, сложность не в том чтобы изначально написать правильно (это просто очень дорого), а в том как найти и исправить проблему.

Сложность не в том, чтобы изначально писать правильно?

Черт возьми! Это дорого?! А, простите, облажавшаяся перед заказчиком команда, лихорадочно правящая свои косяки после прохождения всех сроков сдачи проекта это, по-вашему дешево? Милейший, да это просто новое слово в управлении пректами! Вот теперь я точно понял почему мы сливаем индусам... Только шуба заворачивается...

И, да, по теме...

ТК, решите — нужен ли Вам именно демон или проблему можно решить проще? Варианты — запуск в скрине или в режиме nohup не подойдут?

В любом случае демона лучше бы писать на чем-то отличном от пхп.

А, простите, облажавшаяся перед заказчиком команда, лихорадочно правящая свои косяки после прохождения всех сроков сдачи проекта это, по-вашему дешево?

И тем не менее, большинство сданных в срок проектов — образцы говнокода, чтобы вы там на своей планете не думали.

Погоня за качеством очень тонкое ремесло, трейдофф между скоростью написания здесь-и-сейчас и стоимостью поддержки в будущем. Не замечали тенденцию? Мейнстрим языки (или правильнее сказать инфраструктуры таких языков) обладают удивительным качеством: дешевое сопровождение. То есть какой бы кошмар не был написан изначально (замечу, работающий кошмар), волшебные IDE и инструменты профилирования способны достаточно легко привести его в божеский вид.

Не раз и не два был свидетелем, когда мелкая фича в двадцать строк и добавлением колонки в БД, выливалась в двухнедельный codereview, с жарким обсуждением паттернов и умными словами. Имплементация оказывалась на 500 строк, переинженеренная по самое небалуйся, зато готовая хоть к ядерной войне. В итоге, самое смешное, эта фича оказывалась потом не нужной.

Мне кажется, многие тимлиды-д'артаньяны не понимают простой истины, им платят не за качество, а за работающее нечто, которое не надо потом слишком уж часто фиксить.

Вдобавок к языку на котором зарабатываете учите ещё один, нормальный.

> Мне кажется, многие тимлиды-д'артаньяны не понимают простой истины, им платят не за качество, а за работающее нечто, которое не надо потом слишком уж часто фиксить.

Не надо мешать в кучу управление качеством и говнокод.

Не надо мешать в кучу управление качеством и говнокод.

Разверни мысль, ведь отсутствие управления качеством — это тоже стратегия производства, позволяет быстро получить конечный продукт.

Во, надо будет обрадовать пионэров, что он не тупые обезьяны, а имеют стратегию производства - «отсутствие управления качеством».

Контроль качества подразумевает управление сразу пачкой параметров - сроки, бабло, говнокодистость, фичи, поддержка, и т.п. Выдирать из контекста один единственный и строить на нем логические выкладки - бессмысленно.

ЛОЛШТО?!?

Заранее прошу прощения — моего обычного стиля здесь не хватит. Пишу как есть.

ведь отсутствие управления качеством — это тоже стратегия производства, позволяет быстро получить конечный продукт.

Это позволяет получить «продукт» вида «Лада-Калина». На котором только картошку с огорода возить.

И тем не менее, большинство сданных в срок проектов — образцы говнокода, чтобы вы там на своей планете не думали.

На моей планете придумали поговорку — «величина Разума — постоянная, но население у нас растёт». Я раньше считал это приколом. Ан нет. Вам удалось убедить меня в том, что это не иначе как тенденция.

То есть какой бы кошмар не был написан изначально (замечу, работающий кошмар), волшебные IDE и инструменты профилирования способны достаточно легко привести его в божеский вид.

Мой vim был обрадован эпитетом «волшебная IDE», а ctags так тот вообще скрючило в пароксизме счастья.

У меня для Вас плохая новость. Если программист — идиот, то результаты его «труда» отправляются в /dev/null. Потому как средства профилирования и анализа кода (статистического типа splint или динамического типа valgring), равно как и фаззеры (это для проверки на ряд потенциально опасных ситуаций всего проекта) это НЕ БОЛЕЕ чем средства профилирования и анализа. Они не пишут за Вас код, они не пишут его за Вас безошибочно. Они могут показать только потенциально опасные и/или не оптимальные конструкции. Но если программист вместо 2*2 написал 2*3, то ни одно средство ЭТО в божеский вид не приведёт.

Не раз и не два был свидетелем, когда мелкая фича в двадцать строк и добавлением колонки в БД, выливалась в двухнедельный codereview, с жарким обсуждением паттернов и умными словами. Имплементация оказывалась на 500 строк, переинженеренная по самое небалуйся, зато готовая хоть к ядерной войне. В итоге, самое смешное, эта фича оказывалась потом не нужной.

Простите, я не понял? Что, в обдолбанную в хлам Плату #6 ЗАБЫЛИ завезти _ТЕХНИЧЕСКОЕ_ЗАДАНИЕ_? :)))

+1

.

Так вы, товарищ, сишник (с++ и vim? навряд ли), тогда говнокод, конечно, для вас очень дорого обходится, отсюда такая волна возмущения. Я же говорю «с другой планеты». Если «СИ» для вас мейнтстрим, то умываю руки.

Все понятно, одного д'Артаньяна нашли, удачи вам в вашем нелегком деле.

Илита в треде?

Да как бэ, совсем даже наоборот. Я не витаю в облаках, ставля качество (и все, связанные с ним мероприятия) во главу угла. На элитизм это мало похоже, не находите? Или вы с планеты анонимуса, где все сделано из сверкающей нержавейки, а не из говна и палок?

Я вам в первом посте уже написал, чем вы занимаетесь. Выдирать 1 критерий разработки из кучи и вещать про него великую истину - обычное балабольство.

У меня люди делают код так, как требуют обстоятельства. Могут качественно, могут не очень, могут быстро. А те, кто кроме говна и палок ничего в руках не держал, надолго не задерживаются.

Почти.

В основном С, Java. Вкрапления SQL, JavaScript, html. И, да, работаю, вдобавок в конторе, где крайне жестко рассматриваются вещи типа двойного освобождения памяти. С++ есть, но под Symbian, равно как и Obj-C под iOS. «Дисциплина» в мозгах нужна жесточайшая, уж поверьте.

Выдирать 1 критерий разработки из кучи и вещать про него великую истину - обычное балабольство.

Если, не заметили, то я отстаиваю простой пойнт: дорогой и красивый софт не нужен и бессмыслен применительно к коммерческой разработке, а любой инструмент или подход, позволяющий удешевить производство — суть благо, невзирая на чье-то чувство прекрасного.

К такой формулировке есть возражения? Или это тоже «только один из критериев»?

Смотрите, всё перечисленное (кроме java) требует аккуратности, я же не спорю с тем, что где это действительно необходимо, следует писать абы как.

Мой опыт разработки на Java говорит, что один квалифицированный специалист может подчищать огрехи десяти джуниоров. И это прекрасно, я считаю. Мало какой инструмент может похвастаться таким же свойством.

Банальности про максимизацицию прибыли можно прикручивать к чему угодно. Но они представляют такой же интерес, как неуловимый Джо.

искренне ваш,

Кэп.

Кэп, кэпом, но почему-то многие не понимают следствий этого утверждения.

Есть поправка. Не "пойнт", а "понт"...

Ибо...

дорогой и красивый софт не нужен и бессмыслен применительно к коммерческой разработке, а любой инструмент или подход, позволяющий удешевить производство — суть благо, невзирая на чье-то чувство прекрасного.

Пример с «Лада-Калина» выше. Готовы всю жизнь ездить на _этом_? Вперёд. Но кому-то маловато будет этой скотовозки. Я вот например либо BMW, либо Volkswagen предпочитаю. Ибо действительно Das Auto, а не «бюджетное» решение на базе Фиата 63 или 65 года. Хотя и дороже. Намного.

С другой стороны, лично моё мнение (я на этом для себя закрою данную тему) состоит в том, что Вы позволяете себе кормить своего заказчика откровенным говном. Не более. Называется это нае?аловка, хотя возможно Вы попробуете «облагородить» данный термин, поиграв словами. К процессу девелопмента _ЭТО_ не имеет ровным счётом ни какого отношения, понятие «качество» здесь звучит как издёвка. В таком случае, думаю что положение поправит натурный эксперимент — в следующий раз не в магазин за продуктами, а более «бюджетный» вариант — на свалку. За объедками. Аналогия дошла? Ну и да... «Жигули» под зад. Для полного вкуривания ситуации. Это будет лучше, чем умняк крючить и по две недели глумиться над паттернами.

Это называется «практический менеджмент», истоки которого сформулированы очень давно — «НЕ ДЕЛАЙ ДРУГИМ ТОГО, ЧЕГО СЕБЕ НЕ ЖЕЛАЕШЬ».

Не нанимайте за $200/мес. студентов и не понадобится ассенизатор.

> Мой опыт разработки на Java говорит, что один квалифицированный специалист может подчищать огрехи десяти джуниоров. И это прекрасно, я считаю. Мало какой инструмент может похвастаться таким же свойством.

Мой опыт разработки говорит о том, что либо всё правильно и сразу, либо ни как. Это проще и, в итоге, дешевле.

Если гитаробренчатель, который по совместительству пишет код не поддерживает темп и условия команды — за борт. В конце-концов, если бордель не исполняет план, то меняют девок, а не мебель.

И да, кстати, сделайте над собой усилие... Перечитайте «Собачье Сердце» Булгакова. Там по поводу «разрухи» было... Это так... Если угодно, то «обще-философский» совет. По доброте душевной.