Ну я вообще к тому, что на этапах испытаний (тем более ранних испытаний) автоматика должна быть на втором плане, как бы «смотреть и регистрировать, помогать но не мешать», а приоритет изначально должен быть на стороне пилотов. Ибо автоматике, чтобы работать, нужны сценарии. А сценарии вырабатываются, в том числе, и на таких трагических случаях. Профессия летчиков-испытателей сопряжена с рисками.
А вообще, я просто веткой промахнулся. Мой коммент был адресован вот этому:
Так пилот и нужен, по сути, только на случай отказа автоматики либо какой-то внешней непредусмотренной ситуации.
Я вам приведу одну из реальных причин авиакатастроф пассажирских лайнеров. Замерз на самолете индикатор угла наклона (не помню его точное название), который физически реагировал как гироскоп и передавал данные. Компьютер продолжал получать данные, вот только они были ошибочны. При попытке выполнения маневра, из-за этих ошибочных данных все остальные действия автопилота были просчитаны некорректно и самолет начал резко задирать нос. Пилоты попытались вмешаться, но поскольку все управление все равно идет через электронику, которая вносит свои корректировки, это ничего не дало — автоматика «перебивала» действия пилотов даже с выключенным автопилотом. Самолет задрал нос до критического угла и началось сваливание. Через пару минут он врезался в землю. Погибли все пассажиры и экипаж. Если бы электроника не была «слишком строга», пилоты могли бы спокойно выровнять самолет и довести его дальше до посадки даже с ошибочными показаниями угла, ориентируясь на другие показатели.
Мне прям как-то стыдно признаваться, что я путешествую с полноценным системным блоком да еще и клеткой с котом. Монитор иногда беру (24"), иногда дешевле и проще по месту купить, потом перед отъездом продать. Пора покупать ноут и путешествовать как белый человек :)
Перестаньте путать людей. MyISAM/InnoDB — все зависит от конкретного проекта. Какую из таблиц в каком типе держать — зависит от каждого случая. От оъема данных, сложности архитектуры, собственно самих запросов. Блог или новостной портал, даже очень большой, будет использовать одни запросы. Интернет-магазин или каталог — другие. Появление запросов по meta_key, больших объединяющих запросов, сортировок по meta_value существенно изменит поведение, так как пойдет полнотекстовый поиск, вылезут узкие места с индексами. Если используются свои кастомные таблицы — отдельная история. Вот исходя из этого надо тестировать и выбирать наиболее подходящий тип для каждой конкретной таблицы. А для более-менее стандартного сетапа и среднестатистического сайта, коих большинство — нет никакой разницы. Так что эту рекоммендацию можно смело опустить.
Начиная с версии 4.0 данная константа не используется и ее наличие или отсутствие погоды не делает. Учитывая, что 4й версии уже пару месяцев, пора почитать Changelog.
Ничего подобного. Один и тот же код в плагине или в functions.php выполняется с одной и той же скоростью. Разница только в том, когда он будет выполнен. Код в плагине выполняется раньше, чем код в functions.php, что имеет свои положительные стороны. В остальном, как раз хорошая и правильная практика — выносить функционал в плагины. Инициализация плагинов отнимает время только если это комплексные плагины со своими библиотеками, лоадерами и т.д. Но тут без вариантов — такой код вы и при желании в functions.php не засунете.
Полгода пробовали все возможные варианты и комбинации на 8 своих и клиентских сайтах, в т.ч. высоконагруженных. Пришли к: Nginx mainline с fastcgi_cache, php5-fpm с OPcache, memcached и php5-memcached (с буквой D в конце!), MariaDB. На стороне WP — EWWW Image Optimizer, кеширование gettext (.mo), минификация и конкатенация, очистка? параметров у статических файлов, вывод статики на поддомен без кук, CloudFlare DNS, CDN имеет смысл только для больших international сайтов с высокой нагрузкой и геораспределением юзеров, в других случаях это минус. Плюс оптимизация самого WP (без модификации ядра). Full page кеширование вместо проблемного монстра W3 Total Cache — Batcache, FFPC. Сейчас еще экспериментируем с full page cache в памяти (Memcached) и выдачей напрямую Nginx через свой родной модуль ngx_http_memcached_module. На выходе этой кухни имеем стабильные 96+ Pagespeed Score, загрузку в диапазоне 200-600мс для простых и средних сайтов, 600-1200мс для больших и тяжелых. Повторная загрузка не более 400-600мс.
Да, и еще бонус — многие графические элементы и иконки перевели на svg, сделали «текстовые спрайты», которые отлично жмутся и кешируются. Ну и продолжаем эксперименты постоянно, выискивая новые методы оптимизации. Скоро вот SPDY планируем погонять в хвост и в гриву.
А вообще, я просто веткой промахнулся. Мой коммент был адресован вот этому:
Да, и еще бонус — многие графические элементы и иконки перевели на svg, сделали «текстовые спрайты», которые отлично жмутся и кешируются. Ну и продолжаем эксперименты постоянно, выискивая новые методы оптимизации. Скоро вот SPDY планируем погонять в хвост и в гриву.