В таких благостных постах как назло всегда не хватает одной маленькой детали: хотя бы самой завалящей догадки, о причинах столь удивительной разницы. Я понимаю, что чукча - писатель, а не разработчик, и ответы на неудобные вопросы не входят в круг его профессиональных обязанностей. Но здесь надо понимать, что без объяснения столь драматического эффекта любые писания просто теряют смысл. А статья превращается в известный анекдот "тараканы слышат ногами". Потому что на таких неправдоподобных цифрах может быть всё что угодно. "Кэш включили, а он не включился". "Конфигурацию сервера поменяли, а перезапустить забыли", "Nginx собран с ненужным модулем", и т.д. - несть числа таким "чудесам".
Я вполне допускаю, что причиной столь значительных цифр действительно может быть принципиальное превосходство тестируемого сервиса, а не кривые руки тестировщика. Но тогда надо эти причины наглядно показать. Объяснить, почему вдруг у одного пик потребления памяти офигиллиард бегамайт, а второй вообще не видно без микроскопа. А без такого объяснения любые попытки следования этим рекомендациям превратятся в очередной самолёт из соломы.
Хотя я понимаю логику предыдущего комментария и даже с ним по большому счёту согласен, статья мне очень понравилась. Да, Ларавель олицетворяет собой подход раннего РНР, "фигак-фигак - и в продакшен". Но если знаешь как правильно, то прогибаться под его идеологию тоже вряд ли будет хорошей идеей. Но главное - разбор кейсов в статье просто замечательный, хоть сейчас в учебник. И, скажем, если не рассматривать её в качестве руководства "как писать на Ларавле", а как аналог знаменитейшей "Symfony versus Flat PHP" - то есть как статью для тех, кто например переходит с Лары на Симфони (или просто хочет расти как разработчик) - то она оказывается супер-полезной, поскольку языком Ларавли говорит о подходах Симфони и чистой архитектуры в целом.
Я знаю, что вы можете подумать: «Почему бы просто не использовать Elasticsearch?» или «А что насчёт Algolia?» Это вполне рабочие решения, но у них есть нюансы. Нужно разбираться с их API
Напомнило старый анекдот:
Мужик пилит ножовкой дерево, мимо проходит другой
-- мужик, ты что, есть же бензопила, с ней быстрее! -- да я не умею, нужно разбираться -- там научиться - час времени! -- мне некогда, мне лес валить надо!
.bak - это откуда-то из глубоко 80-х. Редактор Lexicon 😂 Я уж и забыл про такое. И как-то дико оно смотрится в контексте кодовой базы если честно. "Не оставляйте на проде" - это типа значит на деве норм? И все эти баки едут в CVS?
Мне кажется, статья написана искусственным интеллектом. Наряду с дельными советами идёт какой-то треш.
Serialize, eval и плагины уордпресс - это малоизвестные уязвимости? YAML, как альтернатива serialize - это вот прям серьёзно? 😂 allow_url_fopen = Off непонятно каким боком к безопасности (и к примеру, приведённому выше) Весь раздел №4 - это один сплошной кринж
не показана собственно уязвимость, а только выстрел себе в ногу
$key = (string)$key; ШТА? Числовые ключи резко превратятся в строковые? Массив из 5 элементов схлопнется не в 1, а в 3? Это, конечно огромный прогресс!
при чём здесь === , если мы говорим про обращение к ключам массивов, при котором имплицитно используется нестрогое сравнение? Вот здесь явно видна логика Искусственного Попугая, как и в случае с YAML - притащить то, что вроде часто упоминается в схожем контексте.
№5 непонятно, а уязвимость-то в чём? №6 это такой универсальный шаблон, можно применить к любой библиотеке, используемой каким-либо расширением PHP, непонятно, почему свет клином на Intl сошёлся. Чем Imagick или GD например хуже? №12 не очень понятно. Возможно, это я не въезжаю, буду рад внятному объяснению.
В целом, статья бы выиграла, если бы контент-менеджер дал почитать сгенерированный ИИ контент программисту.
В этом-то и вопрос: с какого перепугу "NULL" вдруг заменился на NULL? Почему ни у кого не заменяется, а здесь заменилось? Из какого места должны расти руки, чтобы заменилось? Что сделать, чтобы не заменялось? Без ответов на эти вопросы статья теряет весь смысл. Остаётся беллетристика "Жила-была девочка, ей пришло письмо". Ну очень интересно
К сожалению, там мамаша сказала не "строки", а "входные данные". Впрочем, одно другого не сильно лучше, и оставляет огромный простор для добавления дыр. Лучше бы она посоветовала "параметризованные запросы" (и белые списки до кучи).
А на мой взгляд вы просто пишете случайные слова, пришедшие в голову. Комментатор выше прав - не справившись с асинхронным запросом вы почему-то начали рассуждать о микросервисах. Что изначально делает ваш текст бессвязным потоком сознания.
И даже опечатку с Git не заметили, а она сильно добавляет статье шизофреничности.
Статья - просто бомба! Использование (относительно) новой фичи в РНР, а не пережёвывание старого. Практически реальный, а не совсем академический пример. Толковая подача. Спасибо большое! Всем корпоративным блогам брать пример со СберЗдоровья!
Немного обидно за пхп. В Питоне и FastAPI, и красивый логгер, а в пыхе echo 'Curl error: ' кишками наружу. И сам курл без единого враппера, голенький как в первый день творения знакомства с языком.
Мне всё-таки кажется, что это слишком широкое толкование конвейеризации через контейнеризацию. Этак любой прокси-сервер будет unix-style. Из красивых слов тут скорее подошла бы микросервисная архитектура.
Интересно, что буквально только что из ниоткуда появился ещё один вундеркинд, который в качестве дипломного проекта написал асинхронный пхп. Вызвав искренний респект у автора TrueAsync.
Спасибо, действительно! Изучаю код текущего лидера. Пока совершенно непонятно, за счёт чего он оторвался от конкурентов...
В таких благостных постах как назло всегда не хватает одной маленькой детали: хотя бы самой завалящей догадки, о причинах столь удивительной разницы. Я понимаю, что чукча - писатель, а не разработчик, и ответы на неудобные вопросы не входят в круг его профессиональных обязанностей. Но здесь надо понимать, что без объяснения столь драматического эффекта любые писания просто теряют смысл. А статья превращается в известный анекдот "тараканы слышат ногами". Потому что на таких неправдоподобных цифрах может быть всё что угодно. "Кэш включили, а он не включился". "Конфигурацию сервера поменяли, а перезапустить забыли", "Nginx собран с ненужным модулем", и т.д. - несть числа таким "чудесам".
Я вполне допускаю, что причиной столь значительных цифр действительно может быть принципиальное превосходство тестируемого сервиса, а не кривые руки тестировщика. Но тогда надо эти причины наглядно показать. Объяснить, почему вдруг у одного пик потребления памяти офигиллиард бегамайт, а второй вообще не видно без микроскопа. А без такого объяснения любые попытки следования этим рекомендациям превратятся в очередной самолёт из соломы.
Хотя я понимаю логику предыдущего комментария и даже с ним по большому счёту согласен, статья мне очень понравилась. Да, Ларавель олицетворяет собой подход раннего РНР, "фигак-фигак - и в продакшен". Но если знаешь как правильно, то прогибаться под его идеологию тоже вряд ли будет хорошей идеей. Но главное - разбор кейсов в статье просто замечательный, хоть сейчас в учебник. И, скажем, если не рассматривать её в качестве руководства "как писать на Ларавле", а как аналог знаменитейшей "Symfony versus Flat PHP" - то есть как статью для тех, кто например переходит с Лары на Симфони (или просто хочет расти как разработчик) - то она оказывается супер-полезной, поскольку языком Ларавли говорит о подходах Симфони и чистой архитектуры в целом.
Напомнило старый анекдот:
Зато скидки поражают воображение!
За весь проект не скажу, но раздел про обфускацию позабавил. Впечатляющие методы защиты от несуществующих угроз 😂
.bak - это откуда-то из глубоко 80-х. Редактор Lexicon 😂
Я уж и забыл про такое.
И как-то дико оно смотрится в контексте кодовой базы если честно. "Не оставляйте на проде" - это типа значит на деве норм? И все эти баки едут в CVS?
Мне кажется, статья написана искусственным интеллектом. Наряду с дельными советами идёт какой-то треш.
Serialize, eval и плагины уордпресс - это малоизвестные уязвимости?
YAML, как альтернатива serialize - это вот прям серьёзно? 😂
allow_url_fopen = Offнепонятно каким боком к безопасности (и к примеру, приведённому выше)Весь раздел №4 - это один сплошной кринж
не показана собственно уязвимость, а только выстрел себе в ногу
$key = (string)$key;ШТА? Числовые ключи резко превратятся в строковые? Массив из 5 элементов схлопнется не в 1, а в 3? Это, конечно огромный прогресс!при чём здесь
===, если мы говорим про обращение к ключам массивов, при котором имплицитно используется нестрогое сравнение? Вот здесь явно видна логика Искусственного Попугая, как и в случае с YAML - притащить то, что вроде часто упоминается в схожем контексте.№5 непонятно, а уязвимость-то в чём?
№6 это такой универсальный шаблон, можно применить к любой библиотеке, используемой каким-либо расширением PHP, непонятно, почему свет клином на Intl сошёлся. Чем Imagick или GD например хуже?
№12 не очень понятно. Возможно, это я не въезжаю, буду рад внятному объяснению.
В целом, статья бы выиграла, если бы контент-менеджер дал почитать сгенерированный ИИ контент программисту.
Так это же не настоящий проект, а выдуманный. Просто беллетризованная информация о минимальной версии.
В этом-то и вопрос: с какого перепугу "NULL" вдруг заменился на NULL? Почему ни у кого не заменяется, а здесь заменилось? Из какого места должны расти руки, чтобы заменилось? Что сделать, чтобы не заменялось? Без ответов на эти вопросы статья теряет весь смысл. Остаётся беллетристика "Жила-была девочка, ей пришло письмо". Ну очень интересно
Самое важное осталось за кадром. Конкретный механизм этого "иногда превращаются" остался совершенно неясен, а без него ценность статьи близка к нулю.
К сожалению, там мамаша сказала не "строки", а "входные данные". Впрочем, одно другого не сильно лучше, и оставляет огромный простор для добавления дыр. Лучше бы она посоветовала "параметризованные запросы" (и белые списки до кучи).
А на мой взгляд вы просто пишете случайные слова, пришедшие в голову. Комментатор выше прав - не справившись с асинхронным запросом вы почему-то начали рассуждать о микросервисах. Что изначально делает ваш текст бессвязным потоком сознания.
И даже опечатку с Git не заметили, а она сильно добавляет статье шизофреничности.
Частичное. То, что вы хотели сказать, называется словом "частичное", а не "частное", как будто Илон Маск заказал его для своей вечеринки.
Спасибо! Хорошая статья прямо косяком в ленте пошла - позавчера массивы, вчера общая память и FFI, сегодня файберы!
Статья - просто бомба! Использование (относительно) новой фичи в РНР, а не пережёвывание старого. Практически реальный, а не совсем академический пример. Толковая подача. Спасибо большое! Всем корпоративным блогам брать пример со СберЗдоровья!
Немного обидно за пхп. В Питоне и FastAPI, и красивый логгер, а в пыхе echo 'Curl error: ' кишками наружу. И сам курл без единого враппера, голенький как в первый день
творениязнакомства с языком.Мне всё-таки кажется, что это слишком широкое толкование конвейеризации через контейнеризацию. Этак любой прокси-сервер будет unix-style. Из красивых слов тут скорее подошла бы микросервисная архитектура.
Просто интересно, как безопасность этого элемента реализуется в django? Там по умолчанию уродуется строка, путём отрывания у неё javascript: спереди?
Не надо кликушествовать. Нигде там не написано, что это "рекомендация".