0leg5ergeev: Предупреждаю - этот аргумент не всегда может существовать у пользователя. На это влияют откуда пришёл пользователь и какие характеристики окружения (толь сервер, толь браузер, точно не припомню).
Игорь: см. свой первый скрин в Опере (такое же поведение будет в Яндексе, Хроме, Хромиуме, 80% Сафари, и Макстоне). Вёрстка косячная, смотри из-за какого элемента телефоны улезают вниз.
А если подсунуть в $request id своё значение - можно "случайно" поломать весь код. Просто так что ли подобное создание объектов из массива находится в защищённом состоянии ($guarded = true)?
Ну опять же всё зависит от того же опыта. Если уже занимались JavaFX + fxml или .NET + xaml, считай что уже почти всё есть. Осталось только перенести эти идеи на немного иную сферу.
Therapyx: Хм, ну тогда только форумы, т.к. оный формат уже умирает и там в основном тусуются хоть и старички, но очень крутые.
Я конечно понимаю, что даю плохой совет, но зачастую реакция более бурная, когда работа преподносится как нечто шедевральное. Я думаю очевидно даже почему. Это так, небольшая заметка на тему.
Небольшой опус на тему:
В приведённом коде присутствует ошибка с состоянием гонки (во время инклуда файл уже может не существовать, т.к. используется набор из нескольких последовательных опкодов, а php, напоминаю, зачастую работает в многопоточном режиме), актуально для высоконагруженных систем. А при наличии собачки и должной обработкой ошибок (это важно! Ошибки всё равно надо ловить. либо не гасить вообще) подобного можно избежать (честно, не представляю как это запилить в приведённом примере). Я это всё к тому, что не стоит быть столь категоричным, это безусловно зло, но его надо очень умело использовать на благо.
На всякий случай дополню, что в PHP нельзя использовать BOM. Это может повлечь за собой много проблем, начиная с лишних символов на странице, заканчивая всякими ошибками вида "headers already sent". Кодировку стоит задавать явно в html meta теге и/или content-type хедере (функция header).
Все выводы верные. Думаю не стоит париться, и просто забить (учитывая опыт) т.к. подход с сингл-пейдж и тот, который предлагает JQ в корне различаются (опять же, основываясь на опыте в два дня). Для начала нужно разделение кода - контроллеры и шаблоны, затем уже что-то более серьёзное. роутинг, модели и т.д.
Если не хочется травить себе мозг и подстраиваться под фреймворки советую глянуть Knockout, просто понять как он работает. Он идеально разделит логику и представление (по крайней мере можно будет осознать как оно всё делается) не указывая разработчику куда что пихать и как что делать.
fshp: float near (по умолчанию 0f) тогда получается расстояние от near до vp прямоугольника в противоположную сторону от far (т.е. по факту первый рисунок вполне справедлив, пусть и не точен пропорциями прямоугольников)?
fshp: ну я не указывал специально единицы измерения, чтоб случаем не ошибиться (пока не экспериментировал с ним).
В любом случае с натяжкой можно заявить, что near и есть наш монитор, просто семантика и предназначение немного иное. По этому вопросу я +/- понял.
Но всё равно как-то не совсем понятно каким образом можно вычислить far (ширина, высота и дальность от near), имея в наличии один лишь fovY; Тут я привираю, float far есть в исходниках камеры, предполагаю что это и есть расстояние от near, а высоту в таком случае можно запросто получить исходя из fovY. Но ширину ведь можно вычислить, имея на руках либо fovX, либо допуская, что viewport.width/viewport.height == far.width/far.height - т.е. соотношение сторон у near и far полностью идентичные (пропорциональные прямоугольники). Из чего можно сделать вывод, что невозможно построить камеру, у которой near 4:3, а far 16:9, верно?
Ну так не обязательно же near (если VP всё же и есть near) должен быть прямо пропорционален far'у, может у меня far 1280х720 (вроде 16:9) а near должен получится 640х480 (4:3), который уже проецируется на экран какого-нибудь допотопного монитора. В результате fov x и y получаются разные.
В SVG - это первая мысль была. Но увы, nconvert не умеет по-умолчанию работать с конвертацией из psd\eps в svg, а чтоб сохранять прямо в него - требуется иллюстратор, т.е. не вариант.
Сейчас пробую играться с imagemagik, вроде прогресс уже есть, правда небольшой.
DaNHell: повторю вопрос, каким образом кто-то постронний сможет узнать этот csrf токен, хранящийся в хттпонли кукисах, пусть даже он напрямую завязан на пароле (т.е. не вообще не безопасен)?
