Сомнительная оптимизация, так как при использовании кэша байткода все файлы лежат в памяти и доступ к ним практически мгновенный. Я пришел к такому выводу, когда я оптимизировал через xhprof разные вещи. В итоге, при полном избавлении от файловых операций (включая file_exists) и после перехода на php array конфиги, самые большие затраты цпу пришлись на… вызовы microtime(), который вызывался в начале и конце каждого скрипта.
Ага, увидел, значит этой болезни там нет — это хорошо. Ещё по поводу самого кода — я бы все-таки разнёс все классы (включая статические, включая описанные в include.php, в разные файлы с именами классов (и директориями неймспейсов). Так гораздо удобнее с ними работать. И ещё, правила в .htaccess это конечно замечательно, но мне гораздо спокойнее когда в проекте вся публичная часть лежит в отдельном каталоге public (или htdocs).
Метод вызывается внутри _registerDependencies(), который вызывается в register(), который в свою очередь содержит ещё пачку file_exists, который вызывается из _registerCurrentApp(), который вызывается в init(), который в initWeb($rootDir), который вызывается в index.php. Если я правильно все понял, куча файловых операций, включая чтение текстового файла и парсинг json, будет выполняться каждый запрос. Почему бы не подключать конфиг в виде нормально кешируемого байткод-кешерами php-файла с php-массивом?
Вообще, код выглядит перемудрёным и переусложненным. Смысл делать java из php — сомнительная затея вообще, на мой взгляд, на php можно писать намного проще, сохраняя при этом гибкость и скорость работы и разработки.
Не все последние версии софта есть в epel. Сравнений nginx/fpm против apache — полный интернет, вкратце это скорость, удобство и экономия ресурсов. Если у вас речь идет о боевом сервере, а не о девелоперском, то будет нелишним настроить iptables, а то есть риск случайно оставить открытым в паблик какой-нибудь интересный порт, например БД.
Я бы добавил как минимум подключение репозиториев (epel, remi, webtatic, ...), постгрес вполне уже можно ставить 9.3 и включить ему логи запросов (полезно для слежения и отладки через tail или notice-ивенты в клиенте), вместо апача сейчас всё популярнее ставить nginx + php-fpm, плюс добавить cron, ntp, и прочие полезные мелочи. Кроме того, для виртуалки разработчика будет полезно узнать, как прокидываются порты (с этим часто возникают проблемы у новичков). Ну и зачем нужен ftp, когда у нас есть ssh, а следовательно куда более удобный sftp?
Почему «нет»? Я не исключаю, что некоторым это нравится. Но автору комментария — нет, ему это мешает воспринимать серьезно свою работу. Мне тоже не нравится брендинг такого типа, это дело вкуса. С продуктом должно быть приятно работать, иначе приходится переступать через себя.
Он говорит не про качество фреймворка, а про неудачный несерьезный брендинг с феями и мультяшностью. Названия и образы, с которыми работает программист — важная ведь штука.
Это понятно, но таким образом мышца хрусталика не будет работать, и это не соотносится с утверждением промо-сайта, что «Ваши глаза будут все время фокусироваться на разных точках: иногда вы будете вглядываться в даль, а иногда смотреть на что-то поближе. Ваши зрачки будут постоянно работать, как в естественной среде, поэтому глаза не устанут и вреда здоровью не будет.»
У Oculus Rift расхождение с реальностью при фокусировке на близких предметах еще больше, чем у 3д-монитора. Это не только не тренирует мышцу хрусталика, но и может вызывать дополнительную нагрузку на мозговой центр обработки зрения, и утомлять его. А ещё от этого у меня появляется на непродолжительное время постэффект (когда смотришь после трехчасового «сеанса» на простой монитор, и изображение на нем кажется немного на другом расстоянии, чем оно есть на самом деле). Чтобы было понятнее мысль, проиллюстрирую:
Действительно ли Oculus Rift заставляет цилиарную мышцу работать? Интересно, как это сделано технически? Ведь даже в 3д-кинотеатре и на 3д-мониторе глаза фокусируются всегда на одном и том же расстоянии — расстоянии до экрана. А поскольку к этому прилагается разделение изображений для глаз, то происходит рассинхронизация стереоскопии и аккомодации, что и вызывает тот самый дискомфорт (мнение, основанное на личных наблюдениях). Плюс отягчающий фактор мерцания (или чересстрочности при пассивном 3д) ещё больше усугубляет ситуацию с усталостью.
В самых запущенных случаях, говоря «скивел», подразумевают MSSQL, а не SQL вообще. Особенно режут лирические фразы вроде «Сиквел намного круче Мускуля!» :)
Боевой — продакшн-сервер. Залить на боевой — задеплоить новую версию. Запулься — напоминание программисту актуализировать свой репозиторий. Закостылять — быстренько починить баг / добавить срочную фичу перед дедлайном любым доступным способом с планом на рефакторинг. Накосячить — допустить баг и пропустить его в продакшен. Фиксануть — исправить баг, пофиксить. Рак — место, где допущены некрасивые («срочные») решения, сделанные в обход общей архитектуры (имеет свойство расти и метастазировать, что рано или поздно приводит к смерти кода или консервированию модуля с опухолью). Перефигачить — вылечить запущенную раковую опухоль путем полного переписывания проблемного кода (тотальный рефакторинг). Штурмовать — обсуждать какое-то сложное или важное решение коллективно. Так, ладно, надо работать — мантра, произносимая при потере контекста обсуждения.
Сложных примеров быть не должно. Если вложенность колбэков слишком большая, из разносят в разные части кода, делают декомпозицию через async и подобные библиотеки, делают фабрики звеньев цепи, и используют прочие паттерны. Некоторые вообще рекомендуют избегать создания анонимных функций, особенно в циклах, включая forEach. Хороший код не содержит глубоких «ёлочек». Пример правильной организации логики обработки — цепи middleware в express (точно так же можно организовать любые цепи, например последовательные запросы к БД). Если в nodejs появляется «елочка» — это уже повод задуматься, что что-то идёт не так. Как выглядит аккуратный код с декомпозицией, хорошо показывает пример (stackowerflow):
function loadUser(req, res, next) {
if (req.params.userId) {
Users.findOne({ id: req.params.userId }, function(err, user) {
if (err) {
return next(new Error("Couldn't find user: " + err));
}
req.user = user;
next();
});
} else {
next();
}
}
// ...
app.get('/user/:userId', loadUser, function(req, res) {
// do something with req.user
});
app.get('/users/:userId?', loadUser, function(req, res) {
// if req.user was set, it's because userId was specified (and we found the user).
});
// Pretend there's a "loadItem()" which operates similarly, but with itemId.
app.get('/item/:itemId/addTo/:userId', loadItem, loadUser, function(req, res) {
req.user.items.append(req.item.name);
});
function requireAdmin(req, res, next) {
if (!req.user || !req.user.admin) {
return next(new Error("Permission denied."));
}
next();
}
app.get('/top/secret', loadUser, requireAdmin, function(req, res) {
res.send('blahblahblah');
});
Для изучения смысла регулярок — пойдёт. Выучить синтаксис обычных регулярок не сложно, и шпаргалить там нечего, сложно синтезировать (и в некоторых случаях разобрать) логику. Изучив однажды регулярки, мозг и сам будет «проговаривать» их мысленно, на любом удобном вербальном языке. Сложные для разбора выражения на такой библиотеке будут все равно не менее адскими, чем на языке регулярок.
Вот есть там метод такой loadDeps() который делает такие операции:
Метод вызывается внутри _registerDependencies(), который вызывается в register(), который в свою очередь содержит ещё пачку file_exists, который вызывается из _registerCurrentApp(), который вызывается в init(), который в initWeb($rootDir), который вызывается в index.php. Если я правильно все понял, куча файловых операций, включая чтение текстового файла и парсинг json, будет выполняться каждый запрос. Почему бы не подключать конфиг в виде нормально кешируемого байткод-кешерами php-файла с php-массивом?
Вообще, код выглядит перемудрёным и переусложненным. Смысл делать java из php — сомнительная затея вообще, на мой взгляд, на php можно писать намного проще, сохраняя при этом гибкость и скорость работы и разработки.
src
У Oculus Rift расхождение с реальностью при фокусировке на близких предметах еще больше, чем у 3д-монитора. Это не только не тренирует мышцу хрусталика, но и может вызывать дополнительную нагрузку на мозговой центр обработки зрения, и утомлять его. А ещё от этого у меня появляется на непродолжительное время постэффект (когда смотришь после трехчасового «сеанса» на простой монитор, и изображение на нем кажется немного на другом расстоянии, чем оно есть на самом деле). Чтобы было понятнее мысль, проиллюстрирую:
Боевой — продакшн-сервер.
Залить на боевой — задеплоить новую версию.
Запулься — напоминание программисту актуализировать свой репозиторий.
Закостылять — быстренько починить баг / добавить срочную фичу перед дедлайном любым доступным способом с планом на рефакторинг.
Накосячить — допустить баг и пропустить его в продакшен.
Фиксануть — исправить баг, пофиксить.
Рак — место, где допущены некрасивые («срочные») решения, сделанные в обход общей архитектуры (имеет свойство расти и метастазировать, что рано или поздно приводит к смерти кода или консервированию модуля с опухолью).
Перефигачить — вылечить запущенную раковую опухоль путем полного переписывания проблемного кода (тотальный рефакторинг).
Штурмовать — обсуждать какое-то сложное или важное решение коллективно.
Так, ладно, надо работать — мантра, произносимая при потере контекста обсуждения.