А как вы определяете уровень техники, уж не по результатам ли реализации идей? Не стоит считать что любая идея автоматически реализуема, а за дверью стоят и ждут ее миллиарды исполнителей. На пути идеи может стоять например окупаемость, востребованность, мода. Они обычно оцениваются еще до начала реализации.
Кстати, а почему вы сравниваете уникальность идеи — как концепции, с исполнителями — как с группой однотипных человеков? Это несколько несравнимые категории.
Вы считаете идеи первичными, однако нереализованная идея это практически ничто. В мире существует бесконечное количество нереализованных идей, например антигравитационные аппараты, карманные телепортаторы, стартапы. Это настолько бесконечно огромная область в которой борятся желания, мысли, мечты за возможность быть… реализованными :)
А ведь ресурсы для реализации всегда ограничены.
Равно как и у того непонятного человека может появиться интересная мысль грохнуть вас, чтобы рыбы стало в два раза больше. Просто вы это уже поняли, поскольку более опытны, а он — еще нет. К счастью конкуренция не всегда сводится к идее утопить конкурента, иногда она приводит к развитию.
Выигрыша не дает запуск в лоб, так как PHP не умеет повторно использовать код в памяти после отработки скрипта, а это является главным фактором ускорения fastcgi приложений.
Если я правильно понимаю, fastcgi модуль создавался как раз для того чтобы решать подобные проблемы.
Кроме того, до недавнего времени PHP имел слабый мусоросборщик что опять же не позволяло гонять скрипт в течение долгого времени без необходимости его прибивать.
Мотивы могут быть разными. Можно хотеть собрать мотоцикл можно хотеть разобраться в его устройстве и тут уж кто глубже копнет. Но пока вы через себя не пропустите, не прочувствуете причины тех или иных решений которые применили создатели мотоцикла, пока не узнаете о тех проблемах с которыми столкнулись они, в лучшем случае вы сможете расчитывать на звание слесаря по мотоциклам.
Одно дело пользоваться чужим опытом, и совсем другое - его перенимать.
Разумеется я тоже пользуюсь решениями других разработчиков. Но я говорю сейчас не об этом, практика показала что большинство программистов так никогда и не заинтересуется абстрактным уровнем движка, их вполне удовлетворят существующие базовые методы. Но ведь кто-то эти методы пишет...
Прогресс однозначно будет в том, что ему будет проще самому разобраться в дальнейшем, а также в том что он приобретет опыт в разработке функционала вместо того чтобы использовать чужое решение.
Часто эту мысль отвергают под предлогом того что программист вместо того чтобы решать чужие проблемы, решает свои - учится за счет заказчика, работодателя итд. Но согласитесь, это не повод отказываться от собственных интересов. Работа должна быть взаимовыгодной.
Так и есть, готовая ОС, PHP, Apache. Некоторые идут еще дальше и покупают коробочную CMS, например "Umi CMS", можно купить даже готовый сайт :)
Знаете, то что я сейчас скажу это конечно эмоции к которым не применимы суровые законы бизнеса, но как разработчик я люблю создавать новое. Готовые фреймворки, библиотеки, скрипты очень упрощают жизнь, они очень удобны, но также они ограничивают возможности для самореализации. Вы получаете идеологию, архитектуру, компоненты. Вы начинаете их использовать, но не потому что вам нравится паттерн MVC, а потому что так однажды придумали умные разработчики движка. При этом мотивации что-то менять практически нет - стоит только сделать какое-то большое изменение и код если не сломается, то как минимум станет несовместимым с официальной версией.
А когда люди используют чужой код они часто просто не хотят писать сами. Вопрос в том, готовы ли вы взять на себя ответственность за чужой код - за его качество, за возможные дыры, за масштабируемость, производительность, соответствие решаемым задачам или вас устроит возможность переложить ответственность на сообщество разработчиков или фирму производитель. Оба подхода имеют свои преимущества и недостатки, наприпер при разработке с нуля вы
1. автоматически становитесь самым компетентным лицом в своем движке, и знаете его лучше всех :) в некоторых случаях это очень серьезно снижает затраты на развитие проекта
2. в движке будут отсутствовать общеизвестные дыры, что не позволит пионерам сломать сайт по инструкции
3. вы повышаете свои навыки в разработке. один и тот же модуль всегда можно сделать немного по разному
4. растет карма
Всего несколько дней назад я в своем блоге как раз писал статью про изобретение велосипедов. Не вдаваясь в подробности, скажу лишь что приведенные вами аргументы
1. так оно надёжнее,
2. лень копаться в чужом коде,
3. самореализовываюсь.
на самом деле черезвычайно важны. Для молодых разработчиков они имеют вообще первостепенную важность.
Да, правда, что изобретая велосипед вы заново напишите 90% уже существующего функционала. Да, правда, что он вероятно будет не так хорош как существующий, Но оставшиеся 10% делают то, что называется прогресс.
type hinting нужен, причем в том чилсе для пользовательских типов. Это пригодится в первую очередь для реализации ORM. Так как позволит интерпретатору знать тип переменной. Сейчас для сохранения информации о типах приходится использовать дополнительные массивы или даже хранить их в базе.
Давить директор вас начал постепенно так что у вас было какое-то время чтобы постараться наладить отношения или хотя бы понять, так сказать, к чему пожилая женщина-директор клонит. И тогда свободное время можно было бы использовать не для того чтобы стажировать друга, а для того чтобы подготовить себе пути к отступлению, например смене работы.
Кстати, выводить директоров на чистую воду, если только не собираетесь занять их место, занятие неблагодарное, у них обычно больше возможностей :)
Он не порушит пока вы не обновили свой обозреватель.
После измнения стандарта же каждый участник конфликта начинает тянуть одеяло на себя. Веб мастер CNN разумеется не хочет переделывать сайт, который еще вчера работа замечательно. И его возмущение выглядит обоснованным - огромный ресурс с тысячами страниц, над которым трудится тысяча сотрудников против небольшой группы девелоперов, которым вдруг вздумалось поменять пару строчек в коде.
Вот только есть один маленький нюанс - девелоперы меняя поведение бразуера руководствуются общепринятыми стандартами, а веб-мастера CNN - своими внутрикорпоративными мотивами.
Впрочем и те и другие формально согласны с тем, что стандарты следует развивать.
Если разработчики по обе стороны баррикад это понимают, то можно говорить о каких-то заплатках и режимах совместимости. Вот только заплатки эти также должны способствовать оптимальному развитию стандартов, они не должны давать веб мастеру лазейки диктовать стандарты потому что его сайт смотрит большинство.
Мерой давления со стороны защитников стандартов в этом случае может быть например отключение некоторых востребованных элементов HTML в нестандартных режимах. Или например нестандартные margin и padding по умолчанию различающиеся в разных браузерах и даже разных версиях одного браузера.
Я уверен что в Opera в свое время возникали, да и сейчас возникают ошибки рендеринга. Разница в том что Opera Software выпустит фикс на следующий день, а Microsoft через 2 года.
Да я знаю что в больших корпорациях разработка софта занимает долгое время, но кто просил их
жестко встраивать браузер в операционную систему и делать его обозревателем по умолчанию?
Кстати, а почему вы сравниваете уникальность идеи — как концепции, с исполнителями — как с группой однотипных человеков? Это несколько несравнимые категории.
А ведь ресурсы для реализации всегда ограничены.
Если я правильно понимаю, fastcgi модуль создавался как раз для того чтобы решать подобные проблемы.
Кроме того, до недавнего времени PHP имел слабый мусоросборщик что опять же не позволяло гонять скрипт в течение долгого времени без необходимости его прибивать.
Одно дело пользоваться чужим опытом, и совсем другое - его перенимать.
Разумеется я тоже пользуюсь решениями других разработчиков. Но я говорю сейчас не об этом, практика показала что большинство программистов так никогда и не заинтересуется абстрактным уровнем движка, их вполне удовлетворят существующие базовые методы. Но ведь кто-то эти методы пишет...
Часто эту мысль отвергают под предлогом того что программист вместо того чтобы решать чужие проблемы, решает свои - учится за счет заказчика, работодателя итд. Но согласитесь, это не повод отказываться от собственных интересов. Работа должна быть взаимовыгодной.
Знаете, то что я сейчас скажу это конечно эмоции к которым не применимы суровые законы бизнеса, но как разработчик я люблю создавать новое. Готовые фреймворки, библиотеки, скрипты очень упрощают жизнь, они очень удобны, но также они ограничивают возможности для самореализации. Вы получаете идеологию, архитектуру, компоненты. Вы начинаете их использовать, но не потому что вам нравится паттерн MVC, а потому что так однажды придумали умные разработчики движка. При этом мотивации что-то менять практически нет - стоит только сделать какое-то большое изменение и код если не сломается, то как минимум станет несовместимым с официальной версией.
1. автоматически становитесь самым компетентным лицом в своем движке, и знаете его лучше всех :) в некоторых случаях это очень серьезно снижает затраты на развитие проекта
2. в движке будут отсутствовать общеизвестные дыры, что не позволит пионерам сломать сайт по инструкции
3. вы повышаете свои навыки в разработке. один и тот же модуль всегда можно сделать немного по разному
4. растет карма
1. так оно надёжнее,
2. лень копаться в чужом коде,
3. самореализовываюсь.
на самом деле черезвычайно важны. Для молодых разработчиков они имеют вообще первостепенную важность.
Да, правда, что изобретая велосипед вы заново напишите 90% уже существующего функционала. Да, правда, что он вероятно будет не так хорош как существующий, Но оставшиеся 10% делают то, что называется прогресс.
Кстати, выводить директоров на чистую воду, если только не собираетесь занять их место, занятие неблагодарное, у них обычно больше возможностей :)
После измнения стандарта же каждый участник конфликта начинает тянуть одеяло на себя. Веб мастер CNN разумеется не хочет переделывать сайт, который еще вчера работа замечательно. И его возмущение выглядит обоснованным - огромный ресурс с тысячами страниц, над которым трудится тысяча сотрудников против небольшой группы девелоперов, которым вдруг вздумалось поменять пару строчек в коде.
Вот только есть один маленький нюанс - девелоперы меняя поведение бразуера руководствуются общепринятыми стандартами, а веб-мастера CNN - своими внутрикорпоративными мотивами.
Впрочем и те и другие формально согласны с тем, что стандарты следует развивать.
Если разработчики по обе стороны баррикад это понимают, то можно говорить о каких-то заплатках и режимах совместимости. Вот только заплатки эти также должны способствовать оптимальному развитию стандартов, они не должны давать веб мастеру лазейки диктовать стандарты потому что его сайт смотрит большинство.
Мерой давления со стороны защитников стандартов в этом случае может быть например отключение некоторых востребованных элементов HTML в нестандартных режимах. Или например нестандартные margin и padding по умолчанию различающиеся в разных браузерах и даже разных версиях одного браузера.
Да я знаю что в больших корпорациях разработка софта занимает долгое время, но кто просил их
жестко встраивать браузер в операционную систему и делать его обозревателем по умолчанию?