Да, я хотел спросить, «почему союз итак почти все тут пишут раздельно». Просто уже далеко не первый раз замечаю, так сказать, эпидемический характер носят эти ошибки. Вот и поинтересовался, вдруг тут это модно?
Ну и как можно связаться с автором этого квики? Я нашел чудовищную ошибку:
Quicky syntax error Unexpected constant «output_format» in template file:ru/product.html on line 49
Tag: {$price|string_format:$cur->output_format}
Как мне с этим быть? На форуме и вообще на сайте царит какой-то хаос.
Ну, например, можно написать статью и приписать в конце — статью написал тот-то, но кармы не хватило. Благодарные читатели тут же ринуться поднимать карму.
Да серьезно! И раньше человек формируется — примерно к моменту полового созревания, может, даже еще раньше.
Я бы рад с Вами согласиться, но до сих пор (хотя через полгода четвертак) иногда испытываю ощущения, как в 13-летнем возрасте. Просто накопленный за это время опыт и… понты, что ли… создают иллюзию, словно я изменился — но если копнуть дальше в психику, то окажется, что время замерло на месте.
Окей, поясняю минусующим: расширение mbstring включено далеко не на всех хостингах и не во всех дистрибутивах, это первая проблема.
Вторая проблема — использование автоматического перекодирования (mbstring_internal_encoding) вместо того, чтобы просто iconv'ом преобразовывать кодировку только там, где это действительно нужно — занимает лишнее процессорное время и память, пусть и по мизеру, но в сочетании с первым пунктом, смысл использования этого расширения в проектах, делаемых на публику (а автор вышел со своим проектом на публику) — совершенно неясен.
Разве автору самому нравится дополнительное системное требование, без которого можно обойтись, в принципе?
Просто это один из элементов подхода к разработке, пока он не поменяется, вы еще много раз будете переписывать все заново.
К примеру, я сейчас разрабатываю как раз библиотеку/фреймворк. Сложность кода уже — пипец, а в ближайшие месяцы все станет сложнее в несколько раз. На написание документации, хотя бы в виде комментариев, уйдет еще несколько месяцев — и только если я переборю свою лень.
А документировать в процессе я просто не могу — я говорю, код очень complicated, соответственно реализация каждой новинки занимает не несколько минут, а несколько часов и дней, во время которых я просто не могу отрываться (отвлекаться) от программирования, чтобы не потерять мысли.
Решение может быть таким: после написания какого-то куска или всей библиотеки программист пишет краткий код, иллюстрирующий, как с библиотекой работать — т. н. «точку входа» для документаторов, глядя на которую и отправляясь от нее, они будут смотреть код и составлять описание.
На самом деле, я насчет документирования не закончил — вот вы говорите, что у гигантов есть специальные команды, занимающиеся документацией — мне кажется, сама структура сообщества должна быть разделена на две части — программистов и писателей документации. И рейтинг не должен никак зависить от документированности, потому что наверняка в таком случае хорошо документированные, но слабые проекты будут постоянно превосходить сильные проекты по рейтингу. Надо организовать сообщество так, чтобы разработчики находили людей, которые будут писать документацию им (правда, и насчет мотивации этого я еще не придумал)
В PHP не создают, как правило, специальные библиотеки для переиспользования с хорошей документацией. Исключения — Zend Framework и другие — прекрасно существуют и без Вас, и привлечь их (на первом этапе) вряд ли удасться. А обычные девелоперы не всегда команду-то имеют, не то что документацию своих проектов. Тот же demirGo.CMS, о котором идет речь и который Вы (в первом коментарии) предлагали импортировать в другие проекты одной строкой — много там документации? (Правда, я не считаю, что этот проект созрел для документирования)
Ха, с таким подходом распиарить не получится вообще. Более 9000 хороших разработчиков вообще не документируют свой код, просто потому, что у них есть более важные задачи — и это вполне нормально, я считаю.
Поищите, пожалуйста, за меня: сравнительно недавно в министерствах решили, что оба варианта употребления (и мужской, и средний род) являются правильными — для «осовременнивания» правил русского языка.
Я сам очень удивился, но у меня теща учительница — подтвердила, «черное» кофе больше ошибкой не является.
Для максимально надежного отключения буферизации на любом уровне, я использую такой код: @apache_setenv('no-gzip', 1);
@ini_set('zlib.output_compression', 0);
@ini_set('implicit_flush', 1);
for ($i = 0; $i < ob_get_level(); $i++) { ob_end_flush(); }
ob_implicit_flush(1);
Quicky syntax error Unexpected constant «output_format» in template file:ru/product.html on line 49
Tag: {$price|string_format:$cur->output_format}
Как мне с этим быть? На форуме и вообще на сайте царит какой-то хаос.
Я бы рад с Вами согласиться, но до сих пор (хотя через полгода четвертак) иногда испытываю ощущения, как в 13-летнем возрасте. Просто накопленный за это время опыт и… понты, что ли… создают иллюзию, словно я изменился — но если копнуть дальше в психику, то окажется, что время замерло на месте.
Вторая проблема — использование автоматического перекодирования (mbstring_internal_encoding) вместо того, чтобы просто iconv'ом преобразовывать кодировку только там, где это действительно нужно — занимает лишнее процессорное время и память, пусть и по мизеру, но в сочетании с первым пунктом, смысл использования этого расширения в проектах, делаемых на публику (а автор вышел со своим проектом на публику) — совершенно неясен.
Разве автору самому нравится дополнительное системное требование, без которого можно обойтись, в принципе?
Просто это один из элементов подхода к разработке, пока он не поменяется, вы еще много раз будете переписывать все заново.
К примеру, я сейчас разрабатываю как раз библиотеку/фреймворк. Сложность кода уже — пипец, а в ближайшие месяцы все станет сложнее в несколько раз. На написание документации, хотя бы в виде комментариев, уйдет еще несколько месяцев — и только если я переборю свою лень.
А документировать в процессе я просто не могу — я говорю, код очень complicated, соответственно реализация каждой новинки занимает не несколько минут, а несколько часов и дней, во время которых я просто не могу отрываться (отвлекаться) от программирования, чтобы не потерять мысли.
Решение может быть таким: после написания какого-то куска или всей библиотеки программист пишет краткий код, иллюстрирующий, как с библиотекой работать — т. н. «точку входа» для документаторов, глядя на которую и отправляясь от нее, они будут смотреть код и составлять описание.
На самом деле, я насчет документирования не закончил — вот вы говорите, что у гигантов есть специальные команды, занимающиеся документацией — мне кажется, сама структура сообщества должна быть разделена на две части — программистов и писателей документации. И рейтинг не должен никак зависить от документированности, потому что наверняка в таком случае хорошо документированные, но слабые проекты будут постоянно превосходить сильные проекты по рейтингу. Надо организовать сообщество так, чтобы разработчики находили людей, которые будут писать документацию им (правда, и насчет мотивации этого я еще не придумал)
Я сам очень удивился, но у меня теща учительница — подтвердила, «черное» кофе больше ошибкой не является.
@apache_setenv('no-gzip', 1);
@ini_set('zlib.output_compression', 0);
@ini_set('implicit_flush', 1);
for ($i = 0; $i < ob_get_level(); $i++) { ob_end_flush(); }
ob_implicit_flush(1);
помогает. А почему убрали ISPServer?