1. в PHP это будет сделано через какую-то задницу
2. следуя из (1), будет много гемороя с производительностью в таком случае и, скорее всего, с бажностью такого сервиса
3. как следствие (2) не выдержит сервис просто большой нагрузки.
На PHP много чего можно написать, для чего он не предназначался изначально. Но вы сами понимаете, что так делать не надо.
в PHP я уже много чего достиг. И я считаю, что достиг достаточно того, чтобы сказать, что достал до потолка :) А сложные приложения с MVC моделью в нём работают достаточно медленно.
И потихоньку хочу переползти на распределённые энтерпрайз с веб-интерфейсом. Я имею в виду, что писать приложения, которые бы могли работать для организаций, филиалы которых распределены по регионам.
Допустим, есть человек - честный человек. Он делает "честный" продукт и продаёт его по "честной" цене в 1000, когда как "нечестные" делают его плохо и продают по 5000. "Честный" честно продаёт его по 1000 и считает, что делает правильно. Но в нынешних условиях он не сможет этого сделать, так как будет попросту физически убран с рынка за демпинг цен. Возможно это лишь в том случае, если честный человек имеет привилегированное положение в обществе, т.е. имеет достаточно много власти для устранения нечестных конкурентов. Но власть и честность в нашем обществе не могут находиться в одном человеке. Круг замкнулся.
Не соглашусь с вами по поводу IDE. Я работаю и работал над большими проектами. И время гробится не на переход между окнами в IDE, а на фиксинг багов в коде, что от IDE не зависит. Разве что IDE только упрощает их поиск и возможно даёт подсказки по функциям.
2. Просмотр логов - всегда. Запуск консольных скриптов - изредка. Но часто svn commit/update.
3. E_ALL | E_STRICT | E_NOTICE не всегда будет равняться цифре 8191. От версии к версии может меняться, если введут ещё типы ошибок. Константы всегда рулят.
7. Потому что, как подсказывает опыт,—это удобно и экономит время разработки.
Что вы подразумеваете под "сутью девелопмента"? В моём понимании—это оптимальное время разработки с минимальным количеством багфикса + удобство в разработке для достижения цели задача и проекта.
Я описал, чем я пользуюсь и, возможно, кому-то поможет организовать свой процесс.
unset() использовал только в одном случае в жизни: когда делал анализатор логов и много мегов загнанных массив могли бы не дать скрипту нормально завершиться не вылетев с ошибкой allocated memory.
Но unset() по сравнению с жутко расточительными алгоритмами всяких подпольных cms смотрится как-то мелко :)
почему же? это обычная плата за "бесплатное" размещение. кто-то пользуется "фотосайтом", но и кто-то же должен платить за ресурс. в мире халявы не бывает.
можно отойти в сторону от компутеров и вместо дискеты изображать сейф как "сейв".
а вместо белого листа тупо написать NEW (как на старых порнобанерах:)
Хабр зато отлично понимает <select size="5"> ⇒ <select size="5">
Если вы пишите про мнемоники и стандарты, то и пользуйтесь ими. в XML «>» вызовет ошибку без тега.
Думал, что всё, надо искать, но фраза "сезон был снят перед живой аудиторией" отбила всякое желание. Когда уже перестанут снимать кино с этим дурацким фоновым смехом?
2. следуя из (1), будет много гемороя с производительностью в таком случае и, скорее всего, с бажностью такого сервиса
3. как следствие (2) не выдержит сервис просто большой нагрузки.
На PHP много чего можно написать, для чего он не предназначался изначально. Но вы сами понимаете, что так делать не надо.
И потихоньку хочу переползти на распределённые энтерпрайз с веб-интерфейсом. Я имею в виду, что писать приложения, которые бы могли работать для организаций, филиалы которых распределены по регионам.
2. Просмотр логов - всегда. Запуск консольных скриптов - изредка. Но часто svn commit/update.
3. E_ALL | E_STRICT | E_NOTICE не всегда будет равняться цифре 8191. От версии к версии может меняться, если введут ещё типы ошибок. Константы всегда рулят.
7. Потому что, как подсказывает опыт,—это удобно и экономит время разработки.
Что вы подразумеваете под "сутью девелопмента"? В моём понимании—это оптимальное время разработки с минимальным количеством багфикса + удобство в разработке для достижения цели задача и проекта.
Я описал, чем я пользуюсь и, возможно, кому-то поможет организовать свой процесс.
Но unset() по сравнению с жутко расточительными алгоритмами всяких подпольных cms смотрится как-то мелко :)
а вместо белого листа тупо написать NEW (как на старых порнобанерах:)
Если вы пишите про мнемоники и стандарты, то и пользуйтесь ими. в XML «>» вызовет ошибку без тега.
$one = 0;
$two = 20;
($r = $one) || ($r = $two); // $r = 20
или
$one = 10;
$two = 20;
($r = $one) || ($r = $two); // $r = 10