Главное не пробуйте метод с тремя прочтениями. Книжки надо читать. A не использовать в качестве зубодробительного средства для зубрёжки. Читать — значит получать удовольствие. Быть захваченным перипетиями сюжета. Сопереживать героям. Погружаться в повествование. Всё это невозможно при постоянных пробуксовках на одном месте и сосредоточении на отдельных предлогах. Если слово неизвестное, но примерно понятен смысл из контекста — пофиг, пляшем. Когда это слово встретится еще 5-10 раз — смысл сам выкристаллизуется.
Зато на фоне повышенного эмоционального фона новые слова и — что куда важнее — стандартные грамматические конструкции — укладываются в голове куда лучше. Если какой-то кусок йеликом непонятен — тоже не страшно. В принципе, можно попробовать его разобрать, но я предпочитаю двигаться дальше. Либо дальше из развития событий будет ясно, либо в следующий раз разберемся. А лучше всего читать в оригинале книжку, которую уже знаешь в переводе.
Правило трех прочтений можно (и нужно) использовать только для книжки целиком. А читать один и тот же абзац по три раза — это какая-то изощренная пытка. Куда важнее держать в голове нить повествования и текущую мизансцену, чтобы новая информация встраивалась в неё, как фигурки паззла. Такой способ действительно помогает воспринимать текст гораздо легче. А если каждый раз отвлекаться на то, в каком порядке идут предлоги в конкретном предложении, то потом придется вспоминать, кто все эти люди и как они тут оказались. И удовольствие превратится в тяжёлую неблагодарную работу.
Но этот метод работает в принципе только для тех, кто любит читать. Если книжка была в школе главным пугалом, а информация усваивается только из видеороликов и подкастов, то смысла мучать себя чтением я не вижу — тут надо сразу переходить к сериалам.
Если много читать, то writing придет сам собой. Не слишком грамотное поначалу, но со временем грамотность можно себе "начитать", точно так же, как и с родным языком. Подрихтовывать правилами все равно придется, но куда меньше чем при стандартной зубрёжке "жи-ши пиши с буквой и".
В 2018 году модуль MPM prefork/mod_php считаются устаревшими, а MPM worker + php-fpm прекрасно работают не хуже конкурентов и никаким "насилием" не являются.
Вот когда вспомните, и найдете хоть один работающий браузер, в котором сработает такое "дописывание" тогда и пишите свои рекомендации. В вебе и так слишком много слухов и суеверий, зачем их ещё плодить? Пишите только если вы действительно знаете, о чем идет речь и можете воспроизвести уязвимость, о которой говорите.
JFYI, на Реддите подобные статьи постят по 2-3 раза в день, индусские аутсорсеры таким образом продвигают свои услуги. "5 причин использовать Ларавель", "Почему РНР такой популярный" и пр. Внутри ничего нового или полезного, сплошная банальщина и протухшие новости. Это называется словом "блогспам" и весьма негативно воспринимается как аудиторией, так и модераторами.
Насколько я знаю ситуацию конрeктно в Баду, это в первую очередь технологическая компания. И учитывая, сколько всего она сделала для РНР сообщества (взять один только php-fpm или фикс проблемы с opcache в 7.0.4), то она не вписывается в нарисованную вами мрачную картину засилья неадекватного менеджмента.
Не говоря уже о том, что отказ от намеренного показа 500 ошибки вместо работающего сайта вряд ли можно назвать вопиющим произволом.
Вы опять сбиваетесь на рассуждения о каком-то абстрактном сферическом менеджменте в вакууме, как раньше рассуждали об абстрактном подходе к обработке ошибок вообще. В то время как в конкретном посте не было ни слова про "закрыть побольше бизнес задач с как можно меньшими проблемами" и негативную реакцию на "инициативы разрабов по поводу инвестиций в будущее". Как раз наоборот — насколько я понимаю все инициативы исходили исключительно от разработчиков.
мы создадим некоторый дискомфорт для малой части пользователей, но это окупится в дальнейшем тем, что у нас не будет фантомных трудноловимых багов, которые будут у 100% юзеров.
Речь шла о том, как отловить фантомные трудноуловимые баги, не создавая дискомфорта для юзеров.
Срок "первые 20 лет" включает в себя не только код 20-летней давности, но и 5- и 3-летней.
Миллиарда у них, насколько я знаю, нет, но величины сравнимые.
1% от 100 миллионов — это миллион. Вам бы хотелось попасть в эту фокус-группу? Пусть даже 10 тысяч — зачем экспериментировать на посетителях, если можно обойтись без этого?
Лично я воспринял абзац про "пропатчить РНР" не как предложение "сделать вид, что ничего не произошло" и оставить все как есть — в этом случае ваше возмущение было бы оправданным — а как graceful refactoring — залогировать ошибки и исправить потенциально некорректный код.
В целом, мне кажется что ваши предложения, будучи формально правильными, являются несколько оторванными от реальности, поскольку не учитывают контекст задачи и требования бизнес-процессов.
функция, уже получившая какие-то некорректные данные, во-первых продолжила работу с ними, а во-вторых, делала какие-то неявные преобразования
Учитывая, что такое поведение являлось абсолютно нормальным в течение первых 20 лет существования РНР, а "неявные преобразования" до сих остаются одной из ключевых фич языка, то предложение, чтобы сайт с миллиардной аудиторией падал при срабатывании type juggling выглядит, на мой взгляд, несколько оторванным от реальности.
Это не "авторскиль стиль", а полное отсутствие стиля и чувства меры. Текстовый варинат веб-дизайна "Страничка на народ.ру с обязательным тегом marquee". Начиная от желтушного заголовка и заканчивая неудержимым словоблудием.
Я голосую за то, чтобы не читать на Хабре этот словесный мусор.
Совет: никогда не нужно прикрываться воображаемым "начинащим пользователем", ради которого все ваши старания :)
Во-первых, это никак не может объяснить плохой код.
Во-вторых, начинающему тоже надо когда-то начинать расти, и получать эти самые "специальные знания".
Никогда так не делайте, ни на коленке, ни на станке с программным управлением:
$new_dir = null;
Если переменная содержит массив, то и должна быть инициализирована, как массив.
Заодно пропадет необходимость в лишнем условии if($new_dir)
Ну и разделить эту кучу-малу не помешало бы.
одна функция собирает в массив абсолютные пути ко всем файлам в дереве, а вторая накладывает водяной знак. И в аккуратном цикле вызывает вторую для результатов первой.
Самый простой сценарий для проверки контроллера на излишний вес я нашел здесь:
Попробуйте написать консольную команду, которая выполняет ту же самую функцию, что и экшен в контроллере. Создание нового пользователя к примеру. Если не пришлось дублировать код из контроллера — всё нормально, контроллер выполняет только свою работу, и не пытается быть моделью. Если код пришлось дублировать — это именно тот код, который должен быть вынесен из контроллера в модель.
Ваша бравада эмоционально оправдана, но со стороны смотрится жалко. Звучит это всё, как "Я не профессионал, я любитель. И поэтому я чихал на традиционные представления, что дважды два равно четыре. У меня будет 7!". И с таким отношением вы никогда не дойдете до квадратных уравнений.
Ой, зря вы взяли этот обиженный тон.
Поймите, ваш код говорит о себе куда больше, чем вы хотели бы сказать оправданиями про "реальный код, в котором все правильно".
Добавления палочки со стрелочкой к вызову функции тоже недостаточно. Оно не делает ваш код объектно-ориентированным, а работу с БД менее унылой.
И ваша реакция на совершенно справедливое замечание о нормализации БД в комментарии выше — это тоже очень, очень печально.
Не стыдно чего-то не знать. Стыдно принимать в штыки критику и отказываться учиться.
Судя по оговоркам ("В качестве СУБД я использую расширение MySQLi", "законодательство, обязывающее хранить информацию о пользователях не менее полугода" в контексте обсуждения автоинкремента и пр.) — вы начинающий программист. Если поставите себе целью подтянуть код до современных стандартов, то через пару лет у вас получится то, что не стыдно показать широкой аудитории.
Сейчас же, уж извините, у вас старый добрый спгетти-код, даром что завернутый в класс. В одну кучу смешались SQL, HTTP, файловая система. Никакой абстракции, никакого разделения ответственности. Обработка ошибок где-то лишняя ('cannot make dir: ' ), где-то отсутствует совсем (mysqli), где-то однозначно вредная (echo $e->getMessage();).
В качестве работы над ошибками попробуйте сделать отдельные сервисы для работы с БД и HTTP. Для работы с таблицей файлов в БД также нужен будет отдельный класс. И ради бога, забудьте уже этот чудовищный mysql_query стайл. А то получается как в анекдоте — "ложечку вынул, а глаз все равно зажмуриваешь". Буковку i к вызовам функций приписал, а все остальное осталось как прежде.
В итоге вместо ручного колупания с SQL должно получиться что-то вроде
$this->repository->save($url, $meta, остальные параметры);
В конкретной реализации тоже много странного (непонятно, зачем отдельный запрос для сохранения хэшей и размера файла; непонятно, почему логика получения файла сделана в РНР, а не в БД, почему вообще по одному и тому же url может оказаться больше одного файла и пр.) но это уже мелочи по сравнению со структурными проблемами.
Главное не пробуйте метод с тремя прочтениями. Книжки надо читать. A не использовать в качестве зубодробительного средства для зубрёжки. Читать — значит получать удовольствие. Быть захваченным перипетиями сюжета. Сопереживать героям. Погружаться в повествование. Всё это невозможно при постоянных пробуксовках на одном месте и сосредоточении на отдельных предлогах. Если слово неизвестное, но примерно понятен смысл из контекста — пофиг, пляшем. Когда это слово встретится еще 5-10 раз — смысл сам выкристаллизуется.
Зато на фоне повышенного эмоционального фона новые слова и — что куда важнее — стандартные грамматические конструкции — укладываются в голове куда лучше. Если какой-то кусок йеликом непонятен — тоже не страшно. В принципе, можно попробовать его разобрать, но я предпочитаю двигаться дальше. Либо дальше из развития событий будет ясно, либо в следующий раз разберемся. А лучше всего читать в оригинале книжку, которую уже знаешь в переводе.
Правило трех прочтений можно (и нужно) использовать только для книжки целиком. А читать один и тот же абзац по три раза — это какая-то изощренная пытка. Куда важнее держать в голове нить повествования и текущую мизансцену, чтобы новая информация встраивалась в неё, как фигурки паззла. Такой способ действительно помогает воспринимать текст гораздо легче. А если каждый раз отвлекаться на то, в каком порядке идут предлоги в конкретном предложении, то потом придется вспоминать, кто все эти люди и как они тут оказались. И удовольствие превратится в тяжёлую неблагодарную работу.
Но этот метод работает в принципе только для тех, кто любит читать. Если книжка была в школе главным пугалом, а информация усваивается только из видеороликов и подкастов, то смысла мучать себя чтением я не вижу — тут надо сразу переходить к сериалам.
Если много читать, то writing придет сам собой. Не слишком грамотное поначалу, но со временем грамотность можно себе "начитать", точно так же, как и с родным языком. Подрихтовывать правилами все равно придется, но куда меньше чем при стандартной зубрёжке "жи-ши пиши с буквой и".
В 2018 году модуль MPM prefork/mod_php считаются устаревшими, а MPM worker + php-fpm прекрасно работают не хуже конкурентов и никаким "насилием" не являются.
Если вы считаете, что "с головой" — это удалить РНР код из изображения, то у меня для вас плохие новости.
Вот когда вспомните, и найдете хоть один работающий браузер, в котором сработает такое "дописывание" тогда и пишите свои рекомендации. В вебе и так слишком много слухов и суеверий, зачем их ещё плодить? Пишите только если вы действительно знаете, о чем идет речь и можете воспроизвести уязвимость, о которой говорите.
не помогает
Не знаю как сейчас, но 6 лет назад эта настройка была включена по умолчанию (Сейчас по ссылке отдается 404, а тогда был вывод РНР скрипта.).
Насколько я могу судить, пока это поведение не поменялось.
Так что я ещё рекомендую переименовывать файлы при загрузке, т.е. защита обеспечивается проверкой последнего расширения + переименованием.
JFYI, на Реддите подобные статьи постят по 2-3 раза в день, индусские аутсорсеры таким образом продвигают свои услуги. "5 причин использовать Ларавель", "Почему РНР такой популярный" и пр. Внутри ничего нового или полезного, сплошная банальщина и протухшие новости. Это называется словом "блогспам" и весьма негативно воспринимается как аудиторией, так и модераторами.
Насколько я знаю ситуацию конрeктно в Баду, это в первую очередь технологическая компания. И учитывая, сколько всего она сделала для РНР сообщества (взять один только php-fpm или фикс проблемы с opcache в 7.0.4), то она не вписывается в нарисованную вами мрачную картину засилья неадекватного менеджмента.
Не говоря уже о том, что отказ от намеренного показа 500 ошибки вместо работающего сайта вряд ли можно назвать вопиющим произволом.
Вы опять сбиваетесь на рассуждения о каком-то абстрактном сферическом менеджменте в вакууме, как раньше рассуждали об абстрактном подходе к обработке ошибок вообще. В то время как в конкретном посте не было ни слова про "закрыть побольше бизнес задач с как можно меньшими проблемами" и негативную реакцию на "инициативы разрабов по поводу инвестиций в будущее". Как раз наоборот — насколько я понимаю все инициативы исходили исключительно от разработчиков.
Речь шла о том, как отловить фантомные трудноуловимые баги, не создавая дискомфорта для юзеров.
Срок "первые 20 лет" включает в себя не только код 20-летней давности, но и 5- и 3-летней.
Миллиарда у них, насколько я знаю, нет, но величины сравнимые.
1% от 100 миллионов — это миллион. Вам бы хотелось попасть в эту фокус-группу? Пусть даже 10 тысяч — зачем экспериментировать на посетителях, если можно обойтись без этого?
Лично я воспринял абзац про "пропатчить РНР" не как предложение "сделать вид, что ничего не произошло" и оставить все как есть — в этом случае ваше возмущение было бы оправданным — а как graceful refactoring — залогировать ошибки и исправить потенциально некорректный код.
В целом, мне кажется что ваши предложения, будучи формально правильными, являются несколько оторванными от реальности, поскольку не учитывают контекст задачи и требования бизнес-процессов.
Учитывая, что такое поведение являлось абсолютно нормальным в течение первых 20 лет существования РНР, а "неявные преобразования" до сих остаются одной из ключевых фич языка, то предложение, чтобы сайт с миллиардной аудиторией падал при срабатывании type juggling выглядит, на мой взгляд, несколько оторванным от реальности.
"собираются" != "производят". Разница огромная!
Это не "авторскиль стиль", а полное отсутствие стиля и чувства меры. Текстовый варинат веб-дизайна "Страничка на народ.ру с обязательным тегом marquee". Начиная от желтушного заголовка и заканчивая неудержимым словоблудием.
Я голосую за то, чтобы не читать на Хабре этот словесный мусор.
Уважаемый Вячеслав. Передайте, пожалуйста, своим литературным неграм, что после гуглоперевода текст требует обязательной правки редактором.
Сто раз это уже обсудили. Принципы корпорации и руководящие указания для сотрудников — это разные несколько разные вещи.
Совет: никогда не нужно прикрываться воображаемым "начинащим пользователем", ради которого все ваши старания :)
Во-первых, это никак не может объяснить плохой код.
Во-вторых, начинающему тоже надо когда-то начинать расти, и получать эти самые "специальные знания".
http://php.net/manual/ru/language.generators.overview.php
Наши предложения в комментариях:
->
Никогда так не делайте, ни на коленке, ни на станке с программным управлением:
Если переменная содержит массив, то и должна быть инициализирована, как массив.
Заодно пропадет необходимость в лишнем условии
if($new_dir)Ну и разделить эту кучу-малу не помешало бы.
одна функция собирает в массив абсолютные пути ко всем файлам в дереве, а вторая накладывает водяной знак. И в аккуратном цикле вызывает вторую для результатов первой.
Самый простой сценарий для проверки контроллера на излишний вес я нашел здесь:
Ну вот, теперь по крайней мере честно.
Ваша бравада эмоционально оправдана, но со стороны смотрится жалко. Звучит это всё, как "Я не профессионал, я любитель. И поэтому я чихал на традиционные представления, что дважды два равно четыре. У меня будет 7!". И с таким отношением вы никогда не дойдете до квадратных уравнений.
Ой, зря вы взяли этот обиженный тон.
Поймите, ваш код говорит о себе куда больше, чем вы хотели бы сказать оправданиями про "реальный код, в котором все правильно".
Добавления палочки со стрелочкой к вызову функции тоже недостаточно. Оно не делает ваш код объектно-ориентированным, а работу с БД менее унылой.
И ваша реакция на совершенно справедливое замечание о нормализации БД в комментарии выше — это тоже очень, очень печально.
Не стыдно чего-то не знать. Стыдно принимать в штыки критику и отказываться учиться.
Году в 2008 вас бы похвалили за такой код.
Судя по оговоркам ("В качестве СУБД я использую расширение MySQLi", "законодательство, обязывающее хранить информацию о пользователях не менее полугода" в контексте обсуждения автоинкремента и пр.) — вы начинающий программист. Если поставите себе целью подтянуть код до современных стандартов, то через пару лет у вас получится то, что не стыдно показать широкой аудитории.
Сейчас же, уж извините, у вас старый добрый спгетти-код, даром что завернутый в класс. В одну кучу смешались SQL, HTTP, файловая система. Никакой абстракции, никакого разделения ответственности. Обработка ошибок где-то лишняя ('cannot make dir: ' ), где-то отсутствует совсем (mysqli), где-то однозначно вредная (echo $e->getMessage();).
В качестве работы над ошибками попробуйте сделать отдельные сервисы для работы с БД и HTTP. Для работы с таблицей файлов в БД также нужен будет отдельный класс. И ради бога, забудьте уже этот чудовищный mysql_query стайл. А то получается как в анекдоте — "ложечку вынул, а глаз все равно зажмуриваешь". Буковку i к вызовам функций приписал, а все остальное осталось как прежде.
В итоге вместо ручного колупания с SQL должно получиться что-то вроде
В конкретной реализации тоже много странного (непонятно, зачем отдельный запрос для сохранения хэшей и размера файла; непонятно, почему логика получения файла сделана в РНР, а не в БД, почему вообще по одному и тому же url может оказаться больше одного файла и пр.) но это уже мелочи по сравнению со структурными проблемами.