>потому что опытному программеру со своими наработками это не больше пары недель работы
Это в случае идеально расписанного ТЗ заказчика. Т.е. только работа. В данном случае, как видно из текста, заказчик «типовой», Т.З. будет меняться по ходу работы, будет масса уточнений и переделок. Процесс может растянуться на месяцЫ («ой, у нас начались новогодние канинкулы… ой, шеф улетел на Канары… ой, уже майские праздники...»).
100 тыс. сабжевый проект стоит только в режиме сделал — сдал. Реально — дороже. Я недавно нечто подобное сделал именно с «делёжкой по этапам». Т.е. 100 тыс — за работу по Т.З. Ушло недели две на собственно работу и месяца два на ожидание реакций заказчика по мелочам. Сейчас за 60 тыс. делаю «расширения ТЗ». Уже месяц делаю. В среднем темп работы заказчика «одна транзакция в неделю». Вот уже полторы недели жду реакцию на последний вариант сайта :)
PHP уже давным давно компилятор. Как и подавляющее большинство современных трансляторов.
В противном случае — объясните мне, чем занимается eAccelerator? :)
>разницу знаете??
>Интерпретатор не сохраняет результат и ему главное скорость перегонки кода, Компилятор сохраняет результат в выполняемый файл, время перегонки больше, но код работает быстрее.
Вы путаете очень разные понятия :)
Интерпретатор исполняет программу без предварительной обработки прямо с текста. Компилятор — транслирует в промежуточный код, более удобный для исполнения.
Классический пример различия — циклы. Интерпретатор будет транслировать исходный текст при каждом проходе цикла, компилятор — сделает это один раз.
Очень многие путают компиляцию, компиляцию в нативный код и генерацию исполняемых нативных файлов. Второе, скажем, могут делать, в принципе, и чистые интерпретаторы.
При чём замечу, что этот момент относится к конкрентым реализациям и версиям, а не языкам. Никогда не видели интерпретатора Си? А чем отличался qbasic.exe от qb45.exe не застали? :)
И касается этот момент не только конкретных реализаций, но и конкретного действия: трансляции исходного текста программы. Иначе просто невозможно дать определение. Вот в случае PHP что у нас происходит:
1. Исходный код компилируется в байткод виртуальной машины.
2. Байткод интерпретируется виртуальной машиной в машинные коды.
3. Машинные коды интерпретируются процессором в набор микрокоманд.
4. Микрокоманды процессора исполяются аппаратно.
Если не касаться вопроса обработки исходника, то даже компилирующий в категории исходников Си можно отнести к интерпретаторам. Во-первых, потому что готовые машинные коды на современных процессорах интерпретируются, во-вторых, их можно запустить на виртуальной машине. И тогда интерпретация будет даже при исполнении хостовых машинных кодов аппаратно. И такое деление теряет смысл.
>Боюсь что достоверных цифр вы не узнаете ещё несколько десятков лет, пока «преемники» не кончатся.
А вы берите цифры не из официальных источников, а нормально скоррелируйте цифры первоисточников — собственно участников тех боевых действий. Зачем Вам Интернет дан? Плюс включите здравый смысл и логический анализ обстановки.
Общие выводы будут, как ни странно, очень недалеки от официальной информации.
Похоже, в этой войне наш генералитет пытался поиграть в открытость. Искажения есть, но на фоне прошлых историй они совершенно незначительны. Вот однобокие трактовки — этого сколько угодно. Но это уже вопросы политики и мотивации, но не конкретных легко проверяемых технических деталей.
Впрочем, и не удивительно. Эта война была с самого начала расчитана на показуху для Запада. Отсюда и масса конкретных фактов, приглашения наблюдателей, раскрытие деталей и т.п.
Вот Грузия — та повела себя, как раз, с противоположным знаком. Уже одно только блокирование русских Интернет-ресурсов говорит о многом. В России-то, скажем, Грузию не блокировали :) Это уже ярко выраженный асимметричный ответ :D
>Я бы удивился, если бы у симулятора полёта на тяжёлом, но очень устойчивом самолёте времён второй мировой оказалось бы что-то общее с современной малой авиацией.
Если ещё раз прочитать моё предыдущее сообщение, то можно увидеть, что я там ни слова не говорил про лётную модель. Только про вопросы распознавания образов :)
>Точно так же — удивился бы, если бы нашлось много похожего у контртеррористической операции в замкнутом, и довольно-таки небольшом пространстве с работой в лесу.
И опять — к ней же отсылаю.
Пока компьютеры не дают круговой обзор, полное заполнение поля зрения, поекцию фокуса и дивергенции в диапазоне от метра и до бесконечности и разрешения не менее угловой минуты, ни о какой пригодной для тренировки визуальной имитиации речи идти не может.
Представь, хотя бы, что бойцов в реальности будут тренировать с надетым на голову узким конусом, направленным вперёд… А это только _один_ из рассмотренных моментов несоответствия :)
>А вот чему научат в шутере — так это на раз отличать униформу потенциальных противников
Не в этой жизни :) Проблема распознавания удалённых образов в играх и реальной жизни относится к совершенно разным категориями. Отличается всё — дистанция фокусировки глаза, яркость, оттенки объектов, разрешение…
Мне и с автоматом по полям/лесам побегать доводилось, и из пилотажного самолёта на землю посмотреть… Так вот, ни у какого-нибудь CS с первым, ни у Ил-2 со втором — ничего общего нет :)
…
Максимум, что можно в иаких играх отработать — это коммуникационные команды. Даже головой в этом шутере не покрутишь. Как думаешь, много навоюет солдат, у которого рефлексы на «вспышка справа» начнут пальцы гнуть, а не ноги/туловище/голову? :)
Снёс всё, касающееся связки со Smarty. В шаблоне есть, например, вызов плагина {module name="..."}. Модуля теперь нет. Но диагностики этого события тоже нет. Опять ошибка в шаблоне:
Отказывается компилироваться шаблон. Ошибки совершенно неинформативные…
Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ',' or ';' in /var/www/bal.aviaport.ru/www/cache/system2/smarty-templates_c/common.html.714368.php on line 4
Вылезает несовместимость по шаблонам. В Smarty ресурсы имели вид «res:path», а с враппером будет «res://path». Понятно, что второй вариант привычнее (у меня в системе даже объекты адресуются как «class://id» в строковом представлении), но лишает возможности простого перехода на сабж.
Ладно, придётся для тестирования делать отдельный комплект шаблонов :)
>В Smarty вообще очень очень много чего нет из того что есть в Quicky.
Прошу прощения, но в Quicky я не нашёл register_resource. Он не поддерживает этот функционал? Увы, тогда он отпадает. А уж в свете вышеприведённых цифр из тестов… Хотя всё равно ещё сам протестирую как-нибудь…
Если ты используешь шаблон, типа Smarty, то там и угловых скобок внутри параметра не будет.
Если используешь в качестве шаблона PHP — наверное, ты знаешь, что делаешь. И это, как раз, не тот случай, за который я ратую :) Но даже в этом случае проблема не встаёт. Шаблоны — на то и шаблоны, чтобы использовать их декомпозитивно. И уж на такую фигню, как угловую скобку внутри параметра, можно забить. Всё равно проверять на валидность можно только конечный результат, а не шаблон.
>ну и поедет у тебя вся вёрстка, ибо в аттрибутах кавычки и переводы тоже должны экранироваться, а не только угловые скобочки да амперсандики.
Мы, наверное, друг друга недопонимаем.
>и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
Требуется уточнение:
— Откуда вдруг взялся препроцессор, что ты под ним понимаешь?
— Что ты понимаешь под «пониманием редактором»? Тут возможно двоякое поведение. Редакторы, типа mcedit в этом случае тупо подсвечивают строку как строку. Редакторы в массе своей, от vim до kdevelop подсвечивают в этом случае в строке php-синтаксис. Что для тебя более правильно? :)
Это в случае идеально расписанного ТЗ заказчика. Т.е. только работа. В данном случае, как видно из текста, заказчик «типовой», Т.З. будет меняться по ходу работы, будет масса уточнений и переделок. Процесс может растянуться на месяцЫ («ой, у нас начались новогодние канинкулы… ой, шеф улетел на Канары… ой, уже майские праздники...»).
100 тыс. сабжевый проект стоит только в режиме сделал — сдал. Реально — дороже. Я недавно нечто подобное сделал именно с «делёжкой по этапам». Т.е. 100 тыс — за работу по Т.З. Ушло недели две на собственно работу и месяца два на ожидание реакций заказчика по мелочам. Сейчас за 60 тыс. делаю «расширения ТЗ». Уже месяц делаю. В среднем темп работы заказчика «одна транзакция в неделю». Вот уже полторы недели жду реакцию на последний вариант сайта :)
PHP уже давным давно компилятор. Как и подавляющее большинство современных трансляторов.
В противном случае — объясните мне, чем занимается eAccelerator? :)
>разницу знаете??
>Интерпретатор не сохраняет результат и ему главное скорость перегонки кода, Компилятор сохраняет результат в выполняемый файл, время перегонки больше, но код работает быстрее.
Вы путаете очень разные понятия :)
Интерпретатор исполняет программу без предварительной обработки прямо с текста. Компилятор — транслирует в промежуточный код, более удобный для исполнения.
Классический пример различия — циклы. Интерпретатор будет транслировать исходный текст при каждом проходе цикла, компилятор — сделает это один раз.
Очень многие путают компиляцию, компиляцию в нативный код и генерацию исполняемых нативных файлов. Второе, скажем, могут делать, в принципе, и чистые интерпретаторы.
При чём замечу, что этот момент относится к конкрентым реализациям и версиям, а не языкам. Никогда не видели интерпретатора Си? А чем отличался qbasic.exe от qb45.exe не застали? :)
И касается этот момент не только конкретных реализаций, но и конкретного действия: трансляции исходного текста программы. Иначе просто невозможно дать определение. Вот в случае PHP что у нас происходит:
1. Исходный код компилируется в байткод виртуальной машины.
2. Байткод интерпретируется виртуальной машиной в машинные коды.
3. Машинные коды интерпретируются процессором в набор микрокоманд.
4. Микрокоманды процессора исполяются аппаратно.
Если не касаться вопроса обработки исходника, то даже компилирующий в категории исходников Си можно отнести к интерпретаторам. Во-первых, потому что готовые машинные коды на современных процессорах интерпретируются, во-вторых, их можно запустить на виртуальной машине. И тогда интерпретация будет даже при исполнении хостовых машинных кодов аппаратно. И такое деление теряет смысл.
Так что смотреть надо только на первый этап.
Пардон, но это сравнение тёплого с мягким :)
Сравнивать в этом контексте можно только:
PHP vs PHP+Quicky
или
PHP/eAccelerator vs (PHP+Quicky)/eAccelerator.
Другие сравнения смысла не имеют :)
По большому счёту и первое сравнение смысла не имеет, т.к. нагруженный сайт без акселератора — это не совсем логично, мягко говоря :)
А вы берите цифры не из официальных источников, а нормально скоррелируйте цифры первоисточников — собственно участников тех боевых действий. Зачем Вам Интернет дан? Плюс включите здравый смысл и логический анализ обстановки.
Общие выводы будут, как ни странно, очень недалеки от официальной информации.
Похоже, в этой войне наш генералитет пытался поиграть в открытость. Искажения есть, но на фоне прошлых историй они совершенно незначительны. Вот однобокие трактовки — этого сколько угодно. Но это уже вопросы политики и мотивации, но не конкретных легко проверяемых технических деталей.
Впрочем, и не удивительно. Эта война была с самого начала расчитана на показуху для Запада. Отсюда и масса конкретных фактов, приглашения наблюдателей, раскрытие деталей и т.п.
Вот Грузия — та повела себя, как раз, с противоположным знаком. Уже одно только блокирование русских Интернет-ресурсов говорит о многом. В России-то, скажем, Грузию не блокировали :) Это уже ярко выраженный асимметричный ответ :D
Если ещё раз прочитать моё предыдущее сообщение, то можно увидеть, что я там ни слова не говорил про лётную модель. Только про вопросы распознавания образов :)
>Точно так же — удивился бы, если бы нашлось много похожего у контртеррористической операции в замкнутом, и довольно-таки небольшом пространстве с работой в лесу.
И опять — к ней же отсылаю.
Пока компьютеры не дают круговой обзор, полное заполнение поля зрения, поекцию фокуса и дивергенции в диапазоне от метра и до бесконечности и разрешения не менее угловой минуты, ни о какой пригодной для тренировки визуальной имитиации речи идти не может.
Представь, хотя бы, что бойцов в реальности будут тренировать с надетым на голову узким конусом, направленным вперёд… А это только _один_ из рассмотренных моментов несоответствия :)
Не в этой жизни :) Проблема распознавания удалённых образов в играх и реальной жизни относится к совершенно разным категориями. Отличается всё — дистанция фокусировки глаза, яркость, оттенки объектов, разрешение…
Мне и с автоматом по полям/лесам побегать доводилось, и из пилотажного самолёта на землю посмотреть… Так вот, ни у какого-нибудь CS с первым, ни у Ил-2 со втором — ничего общего нет :)
…
Максимум, что можно в иаких играх отработать — это коммуникационные команды. Даже головой в этом шутере не покрутишь. Как думаешь, много навоюет солдат, у которого рефлексы на «вспышка справа» начнут пальцы гнуть, а не ноги/туловище/голову? :)
Всё дело в очень невнятной обработке ошибок.
Предыдущая ошибка вызывалась при подключении каталога smarty-плагинов. Но при чём тут тогда ? :)
Снёс всё, касающееся связки со Smarty. В шаблоне есть, например, вызов плагина {module name="..."}. Модуля теперь нет. Но диагностики этого события тоже нет. Опять ошибка в шаблоне:
<div id="nav">{module class="nav_top" delim=' / '}</div>превращается в
…
Я, кстати, даже догадываюсь из-за чего… Вся подстрока непринуждённо транслируется в PHP без всяких проверок на корректность.
В общем, рекомендую реализовать хоть какую-то диагностику ошибок компиляции. Иначе пока пользоваться нереально :)
Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ',' or ';' in /var/www/bal.aviaport.ru/www/cache/system2/smarty-templates_c/common.html.714368.php on line 4
Файл common.html:
{include file="xfile://aviaport/_head.html"} ... <div id="container">Компилируется это в:
<?php /* Quicky compiler version 0.4.6.4, created on Tue, 25 Nov 2008 15:41:29 +0300 compiled from */ require_once '/home/balancer/work/programming/php/bors-core/engines/smarty/plugins/function.module.php'; echo 'include' 'file'='xfile://aviaport/_head.html'; ?> <div id="container"> ...…
Что-то пока не складывается с Quicky :)
Ладно, придётся для тестирования делать отдельный комплект шаблонов :)
?
quicky.keeperweb.com/ru/download
Текущая версия — 0.4.6.4.
Прошу прощения, но в Quicky я не нашёл register_resource. Он не поддерживает этот функционал? Увы, тогда он отпадает. А уж в свете вышеприведённых цифр из тестов… Хотя всё равно ещё сам протестирую как-нибудь…
Не знаю :D
>я изначально сказал, что БОД не всегда равен битам в секунду.
И я сделал на это ссылку с самого начала, уточнив, что бод равен биту в секунду только в конкретной ситуации :)
Если ты используешь шаблон, типа Smarty, то там и угловых скобок внутри параметра не будет.
Если используешь в качестве шаблона PHP — наверное, ты знаешь, что делаешь. И это, как раз, не тот случай, за который я ратую :) Но даже в этом случае проблема не встаёт. Шаблоны — на то и шаблоны, чтобы использовать их декомпозитивно. И уж на такую фигню, как угловую скобку внутри параметра, можно забить. Всё равно проверять на валидность можно только конечный результат, а не шаблон.
:)
>бод — количество бит, переданное в секунду (при двоичном кодировании).
Да нет же, бод — это количество изменений состояния в секунду. При любом кодировании :)
Но потом ты всё верно пишешь.
Если линия однобитовая (классический модем или ethernet), то бод — это 1 бит в секунду.
Если линия, скажем, 8-битная шина данных, то бод — это 8бит в секунду будет.
Вообще, вот: ru.wikipedia.org/wiki/Бод
…
Кстати, я не прав на счёт модема оказался :)
Мы, наверное, друг друга недопонимаем.
>и какой же редактор понимает инструкции препроцессору внутри аттрибутов?
Требуется уточнение:
— Откуда вдруг взялся препроцессор, что ты под ним понимаешь?
— Что ты понимаешь под «пониманием редактором»? Тут возможно двоякое поведение. Редакторы, типа mcedit в этом случае тупо подсвечивают строку как строку. Редакторы в массе своей, от vim до kdevelop подсвечивают в этом случае в строке php-синтаксис. Что для тебя более правильно? :)