есть правила, а есть фактическая устоявшаяся традиция.
насколько я могу судить, именно фактическое произношение, а не формальная транскрипция заимствованных слов в конечном итоге попадает в словари.
Правила же транскрипции созданы для транскрибирования малоизвестных слов, которые по тем или иным причинам нужно написать по-русски в обычном тексте (ибо в тексте для лингвистов, если надо передать звучание, проще и правильнее использовать общепринятые системы фонетического письма).
предлагаю не сопротивляться тому, что неизбежно и не несёт зла.
не тупое копирование, а естественное заимствование.
не новояз (уверяю вас, новояз Оруэлла это совсем не то о чем вы сейчас говорите), а современный живой язык.
заимствования — нормальный и естественный путь развития любого естественного языка, а без нормального развития языка мы бы сейчас писали ижицой и говорили на старославе.
Врочем, если копнуть глубже, без развития языка мы бы сейчас вообще не говорили.
ну, primo — мы не во франции, secundo — я, например, предпочитаю общаться с людьми на том языке, на котором меня понимают.
окружающие люди хорошо понимают Блютуз и ФайрВайр и плохо понимают Синий Зуб и Огонь-провод. Хорошо понимают ВайФай с его узким общепринятым смыслом, и плохо — «беспроводную связь» с её более общим значением, отлично воспринимают ГПС и недоуменно морщат лоб на Глобальную Систему Позиционирования несмотря на совпадение аббревиатур.
Язык — вещь изменчивая и рано или поздно блютуз станет таким же полноправным русским словом как ИМХО и люминофор. Не вижу смысла этому сопротивляться.
Опечатка: «pcntl_fork возвращает дочернему процессу и PID дочернего процесса — родительскому». Так что же pcntl_fork возвращает дочернему процессу? (-:
Недочет:
В вашем варианте работы с pid_file'ом всё-ещё возможен одновременный запуск двух демонов. Чтобы этого избежать демон должен лочить пид-файл на запись в начале работы. Если это не удалось, то факт наличия существующего процесса можно даже не проверять — он точно есть, раз файл занят.
Дополнения:
При использовании веб-ориентированных фреймворков для создания любых долгоживущих процессов вообще и форкающихся демонов в частности надо с особой осторожностью следить за ресурсами, т.к. многие фреймворки имеют серьёзные проблемы с их утечкой, так как не рассчитаны на длительную работу и в таких условиях никем не тестировались. Проблема эта в основном происходит от довольно примитивного сборщика мусора в PHP, который ведётся на банальные циклические ссылки.
Так, например, во фреймворке symfony экземпляры sfAggregateLogger никогда не удаляются из-за циклической ссылки (где-то через sfEventManager) — как результат получается утечка памяти. И файловых дескрипторов, если используются sfFileLogger'ы.
Таких примеров очень много.
Пути решения — либо исправлять фреймворк, либо ограничивать время жизни рабочего процесса, как это сделано в apache.
Ещё: полезно иметь управляющие скрипты, поддерживающие как минимум общепринятые юниксовые команды start и stop. Такие скрипты можно класть в rc.init (или rc.d) и таким образом обеспечить себе корректный подъём демонов при старте сервера и не менее корректное их завершение при выключении.
И ещё: не менее полезно перед началом любой работы переключаться в конкретную, определенную в конфигах рабочую директорию, дабы не плодить по файловой системе случайный/дебаговый вывод и не зависеть от того где в действительности был запущен демон.
я бы даже сказал, что он очень сильно устарел и пользоваться им для ознакомления с симфони довольно опасно, так как это грозит приобретением дурных и очень вредных привычек.
Я бы всё-же начал перевод сразу с документации к 1.2. Выходные впереди, может быть возьмусь за вводные главы сам…
нет, я имел ввиду что две следующие строчки дадут разный результат и, как следствие, тест, который это не учитывает, не является корректным:
print_r (json_decode (json_encode(array ('one'=>'two'))); // будет инстанс stdClass с пропертёй one которая равна строке 'two'
print_r (unserialize (serialize(array ('one'=>'two'))); // выдаст именно то, что засовывали.
Это важно как с точки зрения корректности теста, так и с точки зрения быстродействия, т.к. манипуляции с объектами в пхп затратнее, чем манипуляции с массивами.
Еще это важно с точки зрения доказательства того факта, что вы делаете абстрактные тесты, явно ниразу по-настоящему не использовав предмет тестирования в реальных задачах, но это уже мелочи (-:
Т.е. в вашем тесте надо как минимум выставить второй параметр json_decode() в true.
Впрочем, это не отменяет того факта, что json не является средством сериализации произвольных данных.
похоже для крупных проектов кроме CentOS/RHEL особо ничего и нет серьёзного.
собственно я CentOS и пользуюсь в тех случаях когда по каким-то сторонним причинам нельзя поставить FreeBSD.
насколько я могу судить, именно фактическое произношение, а не формальная транскрипция заимствованных слов в конечном итоге попадает в словари.
Правила же транскрипции созданы для транскрибирования малоизвестных слов, которые по тем или иным причинам нужно написать по-русски в обычном тексте (ибо в тексте для лингвистов, если надо передать звучание, проще и правильнее использовать общепринятые системы фонетического письма).
не тупое копирование, а естественное заимствование.
не новояз (уверяю вас, новояз Оруэлла это совсем не то о чем вы сейчас говорите), а современный живой язык.
заимствования — нормальный и естественный путь развития любого естественного языка, а без нормального развития языка мы бы сейчас писали ижицой и говорили на старославе.
Врочем, если копнуть глубже, без развития языка мы бы сейчас вообще не говорили.
окружающие люди хорошо понимают Блютуз и ФайрВайр и плохо понимают Синий Зуб и Огонь-провод. Хорошо понимают ВайФай с его узким общепринятым смыслом, и плохо — «беспроводную связь» с её более общим значением, отлично воспринимают ГПС и недоуменно морщат лоб на Глобальную Систему Позиционирования несмотря на совпадение аббревиатур.
Язык — вещь изменчивая и рано или поздно блютуз станет таким же полноправным русским словом как ИМХО и люминофор. Не вижу смысла этому сопротивляться.
а FireWire предлагаете переводить как ОгоньПровод?
Если пароль использовать слишком часто, то он будет потрёпаный и засаленый. (-:
А добавление соли по-русски, насколько я понимаю, правильнее будет называть засолкой.
Недочет:
В вашем варианте работы с pid_file'ом всё-ещё возможен одновременный запуск двух демонов. Чтобы этого избежать демон должен лочить пид-файл на запись в начале работы. Если это не удалось, то факт наличия существующего процесса можно даже не проверять — он точно есть, раз файл занят.
Дополнения:
При использовании веб-ориентированных фреймворков для создания любых долгоживущих процессов вообще и форкающихся демонов в частности надо с особой осторожностью следить за ресурсами, т.к. многие фреймворки имеют серьёзные проблемы с их утечкой, так как не рассчитаны на длительную работу и в таких условиях никем не тестировались. Проблема эта в основном происходит от довольно примитивного сборщика мусора в PHP, который ведётся на банальные циклические ссылки.
Так, например, во фреймворке symfony экземпляры sfAggregateLogger никогда не удаляются из-за циклической ссылки (где-то через sfEventManager) — как результат получается утечка памяти. И файловых дескрипторов, если используются sfFileLogger'ы.
Таких примеров очень много.
Пути решения — либо исправлять фреймворк, либо ограничивать время жизни рабочего процесса, как это сделано в apache.
Ещё: полезно иметь управляющие скрипты, поддерживающие как минимум общепринятые юниксовые команды start и stop. Такие скрипты можно класть в rc.init (или rc.d) и таким образом обеспечить себе корректный подъём демонов при старте сервера и не менее корректное их завершение при выключении.
И ещё: не менее полезно перед началом любой работы переключаться в конкретную, определенную в конфигах рабочую директорию, дабы не плодить по файловой системе случайный/дебаговый вывод и не зависеть от того где в действительности был запущен демон.
Но, конечно, включать её ни в коем случае нельзя, по крайней мере не для обработки запросов от неавторизованной публики.
На самом деле меня больше интересует ответ на первый вопрос: «почему странно?»
а если это методы?
Я бы всё-же начал перевод сразу с документации к 1.2. Выходные впереди, может быть возьмусь за вводные главы сам…
print_r (json_decode (json_encode(array ('one'=>'two'))); // будет инстанс stdClass с пропертёй one которая равна строке 'two'
print_r (unserialize (serialize(array ('one'=>'two'))); // выдаст именно то, что засовывали.
Это важно как с точки зрения корректности теста, так и с точки зрения быстродействия, т.к. манипуляции с объектами в пхп затратнее, чем манипуляции с массивами.
Еще это важно с точки зрения доказательства того факта, что вы делаете абстрактные тесты, явно ниразу по-настоящему не использовав предмет тестирования в реальных задачах, но это уже мелочи (-:
Т.е. в вашем тесте надо как минимум выставить второй параметр json_decode() в true.
Впрочем, это не отменяет того факта, что json не является средством сериализации произвольных данных.