На вкус и цвет, в любом случае вокруг PDO легко написать собственную обертку со своими преферансом placeholder'ами и поэтессами обработкой результатов выборки.
Новый Office по-моему хорош, правда тем кто им активно пользовался раньше, до 2007 версии, сейчас неудобно, но я-то им никогда не пользовался (и не собираюсь :)) — потому очень доволен. Очень внятно разнесли миллионы вордовских кнопок по вкладкам.
Ну как-бы в том и суть вопроса, что мануалы по php настолько интуитивно-понятны — что любой их может открыть и разобраться, и исключительно нежелание это делать порождает и огромное количество говнокода на php, что таки присутствует, и высокомерное отношение других программистов к программистам на php.
Я вот лично например наблюдал как человек ругал php за то что он не может вызвать функцию с произвольным количеством параметров, и потому приходится делать так:
function call_user_func_array($function, array $params) {
switch(count($params)) {
case 1:
return $function($params[0]);
case 2:
return $function($params[0], $params[1]);
// ...
}
}
Вместо того чтобы таки открыть мануал и найти там call_user_func с call_user_func_array рядом. И таких примеров много… прямо скажем «тысячи их».
потому что весь комплект весит столько, что на своих двоих его унести сложно
Короче, около 15 кг в большущей неудобной коробке.
Ну это неправда, я себе микроволновку покупал весом 15кг, в большущей неудобной коробке, и таки донес до дома километр, несмотря на ИМТ 15.5, своя ноша не тянет :P
Кстати, название ncurses — библиотеки для рендеринга изображения с использованием esc-кодов, вообще говоря, идёт от английского to curse — высказывать благодарность за удобную и понятную вещь.
Это имхо и является одной из двух главных проблем фреймворка — излишне скурпулезная декомпозиция, какая-нибудь жалкая пара общих операторов — уже дополнительный базовый класс куда они вынесены, а там один класс агрегирует другой класс, оба тянут за собой цепочку наследований родительских классов и интерфейсов, в итоге каждый пук подключает 20-30 файлов с большим количеством балластного кода, на чем конкретно буксует интерпретатор. И казалось-бы — есть-же интерфейсы, можно написать реализацию самому! Но тут вылезает вторая проблема, довольно-таки известный антипаттерн — bloated interface, половина интерфейсов зенда — это хреновы миллионы однотипных методов, с псевдополиморфизмом методов (setOptions(array $options), setConfig(Zend_Config $options)), аксессорами (__get => getOption, __set => setOption) и т.д. и т.п., что выливается в человекогода их реализации.
Ну насчет подтверждений — для частоиспользуемых операций они всегда будут доводиться до автоматизма, и лишние защиты будут только зазря кушать нервы пользователя тогда, когда в этом необходимости нет, в частности текстовое поле — это по-моему сильный перебор. Как говорится, хочешь изменить мир — измени себя :)
По-моему вас от вашей ошибки спасло-бы следующее:
1) повышенное внимание в случае работы с рабочей базой сервера, даже если время не терпит — все равно осознание критичности ошибки должно заставить остановиться, остыть, так сказать, и выполнять действия обдуманно.
2) повышенное внимание в случае необратимых операций, причем на этапе выполнения, а не подтверждения операции, это мне кажется самое главное, решение нужно-ли делать TRUNCATE `users` должно обдумываться на момент нажатия TRUNCATE `users`, а не на момент нажатия подтверждения.
Ну и в конце концов если цена ошибки так высока — может стоит вообще отказаться от работы с оперативной базой через phpmyadmin? «Резание по живому» никогда не заканчивается слишком уж хорошо.
P.S. Ну и конечно если уж говорить о защите от такого рода ошибок — предупреждения и подтверждения нужно выдавать там, где это действительно критично, именно тогда на них будут обращать внимание:
» chmod -R 644 some_folder
« тишина
» chmod -R 644 /
« Вы уверены что хотите рекурсивно задать права на все файлы и подкаталоги корневого каталога? Y/N
Не понравился unity, не понравился gnome 3, хочется хорошей годной оболочки для десктопа, а все как с цепи сорвались с этими хреновыми таблетками и планшетами.
По-моему самый вероятный вариант в наших-то краях вариант — то что в яндексе есть какой-либо оголтелый нашист, подсосавшийся к техническим ресурсам и сливающий оттуда информацию милой девушке Юле, надо его обнаружить, уволить, и вместе с Юлей посадить. «Кажется так» (с) Винни-Пух.
С другой стороны даже если это не так — яндекс скорее всего все равно будет давить именно на такой вариант развития событий, потому как вряд-ли его клиенты по достоинству оценят его чрезмерную лояльность :)
преферансомplaceholder'ами ипоэтессамиобработкой результатов выборки.Я вот лично например наблюдал как человек ругал php за то что он не может вызвать функцию с произвольным количеством параметров, и потому приходится делать так:
Вместо того чтобы таки открыть мануал и найти там call_user_func с call_user_func_array рядом. И таких примеров много… прямо скажем «тысячи их».
По-моему вас от вашей ошибки спасло-бы следующее:
1) повышенное внимание в случае работы с рабочей базой сервера, даже если время не терпит — все равно осознание критичности ошибки должно заставить остановиться, остыть, так сказать, и выполнять действия обдуманно.
2) повышенное внимание в случае необратимых операций, причем на этапе выполнения, а не подтверждения операции, это мне кажется самое главное, решение нужно-ли делать TRUNCATE `users` должно обдумываться на момент нажатия TRUNCATE `users`, а не на момент нажатия подтверждения.
Ну и в конце концов если цена ошибки так высока — может стоит вообще отказаться от работы с оперативной базой через phpmyadmin? «Резание по живому» никогда не заканчивается слишком уж хорошо.
P.S. Ну и конечно если уж говорить о защите от такого рода ошибок — предупреждения и подтверждения нужно выдавать там, где это действительно критично, именно тогда на них будут обращать внимание:
и т.п.
С другой стороны даже если это не так — яндекс скорее всего все равно будет давить именно на такой вариант развития событий, потому как вряд-ли его клиенты по достоинству оценят его чрезмерную лояльность :)
ну или