Comments 265
У меня есть для вас непростое задание. Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка.
Можно было бы пройти через тягомотину написания собственного автозагрузчика, но раз мы выбрали Composer для управления сторонними зависимостями, а в нём уже есть очень удобный автозагрузчик, то его мы и будем использовать.
обьясните мне пожалуйста почему первая цитата не исключает действия из второй? почему в первом случае нас агитируют заниматься тягомотиной, а во втором случае нет?
Потому что фреймворк это не загрузчик, наверное :)
С одной стороны как человек который таки да, писал все с нуля, и действительно серьезно подтянул скилсы в чужих фрейворках — да, это как-то странновато использовать готовые пакеты пытаясь написать «с нуля». Тем более что внутрянку пакетов не затронули. С другой стороны… ну вот минимальный базовый функционал, так чтобы оно реально было применимо в продакшене — меньше 20килобайт кода не завесит. Плюс PSRы разобрать, объяснить. Тесты и т.п… В общем статей сорок уйдет на примерно тоже самое.
А так хоть стандарты людям будут известны.
Итого: Да, статья не очень соответствует заголовку и началу, но полезно. Местами.
Работать на таком монстре будет сильно сложнее, понимания работы конкретных элементов он не добавил; в итоге получился просто фреймворк из компонентов других фреймворков (правда без нормальной работы с базой), полезность которого сомнительна
Вообще вы конечно правы, это я что-то затупил под вечер.
У меня мой фреймворк занимает чуть больше мегабайта кода.
Неоднократно порывался выложить в паблик, кратенько писать «историю создания» примерно в таком стиле и т.п.
И тут на автопилоте ощущения от того масштаба работы взял, да и сравнил с вот этим вот куцым описанием процесса сборки из кусочков.
Действительно, если так по верхам описывать как здесь, то будет ничуть не больше. Правда и ничуть не понятнее).
Вопрос работы с бд тоже довольно холиварная тема, поэтому ее и не описывал автор. Сложно будет доказать когда оправдан ActiveRecord, а когда DataMapper. И там тоже все на магии, если самому реализовывать.
Данная статья удобна для стажеров. Буду давать ее для изучение перед изучение полноценных фреймворков.
В отличие от этого поверхностного «воткните штекер А в гнездо Б», у Дмитрия Елисеева идёт детальный разбор того, как каждый компонент работает и почему это устроено именно так.
1. Разная философия пакетов (ларавель использующий колбек вызов свифт мейлера, когда мне нужно было на лету что-то модифицировать в отправке).
2. Пакеты, не заточенные под композер, в которых настройки прошиты где-то в их папке и вынести нормально эти настройки не было возможности.
Может быть сейчас все изменилось, но все-равно не думаю, что правильно собирать такого Франкенштейна, ведь плюс любого хорошего фреймворка в однотипном написании всех его компонентов.
двушка симфы изначально так и писалась, из зенда на уровне 1.х можно было брать либы. из ларавеля и из юи брать не имеет смысла из-за зависимостей и уникальности, я правильно понимаю? Тогда зачем изобретать надуманные кейсы? Как и в js и pythone есть независимые либы, которые независимо и подключаются(свифт), а плагины(пакеты) писались и пишутся под конкретный фреймворк. Я скажу про питон, что если мне нужно что-то простое, я возьму бутылку, и точно не буду к ней использовать джанго пакеты, так же как в реакте не буду пользовать ангулар пакеты.
В экосистеме Symfony есть три основных типа либ: бандлы, бриджи и компоненты. Компоненты — самодостаточные либы, не зависящие от фреймворка, которые можно брать и использовать практически в любом приложении. Бриджи обычно — низкоуровневые адаптеры над либами, прежде всего сторонними, приводящие их к Symfony-way API/UI и(или) обратно (родные компоненты Symfony по понятным причинам обычно в них не нуждаются). Бандлы — обычно тесно интегрированы с фреймворком, в том числе с девтулсами, активно взаимодействуют с событийной моделью Symfony, с флоу пути запроса-ответа. часто имеют собственный веб-UI вплоть до предоставления единственного UI приложения. Собственно сам фреймворк — лишь бандл. С другой стороны, нередко они лишь тонкие адаптеры к компоненту/бриджу, например, просто регистрирующие сервисы в контейнере и конфигурирующие их в Symfony-way. С последними релизами Symfony (3.4 и 4.0 прежде всего) нужды в таких бандлах стало значительно меньше, регистрацию и конфигурирование можно делать автоматически, лишь "натравив" контейнер на нужную папочку.
Бандлы — практически полнофункциональные, пускай и узкоспециализированные, приложения, сильно зависят от фреймворка, очень часто являются пакетами тесной интеграции компонентов или сторонних библиотек в фреймворк. Когда достаточно простые обертки, когда заметно сложнее собственно оборачиваемой либы (полноценное внедрение в девтулсы, например) или имеют свой собственный UI типа бандла для RAD админок. Собственно сам фреймворк — это тоже бандл.
С Symfony (особенно текущие версии) можно написать огромное приложение так, что только с десяток (грубо) строк кода (не считая конфигов) будут зависеть от собственно Symfony Framework. Все остальные зависимости Symfony будут от компонентов, многие из которых поддерживают PSR стандарты, а те, что не поддерживают (прежде всего по причине отсутсвия таких стандартов) самодостаточны с одной стороны, а с другой могут быть изолированы за более специфичными для приложения абстракциями. При переходе на другой фреймворк или отказе от фреймворка в принципе, практически не нужно будет переписывать код, только выкинуть связи с Symfony и как-то реализовать ту функциональность, что реализовывалась Symfony.
- Composer
- PHP-DI
- Zend Diactoros
Готово — мы вывели «Hello, world»!
Ага, современный бэк — бессмысленный и беспощадный :D
Лучше уж готовый фреймворк, чем такой борщ из библиотек (которые и не библиотеки на самом деле а микро-фреймворки). И преемственность выше и код понятней и обслуживать проще и документация по всем компонентам сразу.
Нет, я конечно понимаю что здесь чисто «как нарисовать сову», но тем не менее…
Хотя да, по здравости если подумать. Добавил в закладки чисто потому что «потом когда-то решу причухать свой фреймворк и выпустить в паблик, тогда загляну сюда, поменяю часть своих велосипедов на что-то более PSRистое». А так то наверняка бы половину не понял в статье, если бы все это не знал раньше.
Ага, современный бэк — бессмысленный и беспощадный :D
А Вы на фронте были?
которые и не библиотеки на самом деле а микро-фреймворки
Нет, это именно библиотеки. А Вы не понимаете разницу между библиотекой и фреймворком.
Статья — норм, заголовок — вполне точен.
И хотя по сути автор описывает, как создать свой микрофреймворк из стандартных библиотек, это нормально, так как любое более-менее структурированное приложение держится на некоем каркасе, готовом или самописном.
А Вы не понимаете разницу между библиотекой и фреймворком.
Для меня отличие библиотеки от фреймворка в том, что библиотека выполняет четко только одну задачу, микрофреймворк — задачу и смежные с ней (близкие по функционалу).
На примере композера — грубо — он выполняет и проверку зависимостей и автозагрузку классов и установку модулей — для меня это — микрофреймфорк. Т.к. все эти задачи, хоть и близкие по функционалу, все-таки различны.
Ноу проблем — укажите мне, где я ошибаюсь.
Но на самом деле пост то не про это был, а про то, что человек слепил свой собственный фреймворк из кучи модулей и утверждал, что обошелся без фреймворка.
А на самом деле он слепил свой собственный неуклюжий фреймворк, за бортом осталась шаблонизация (а без нее в современном вебе никак), нормальная авторизация, настройки, хранилище и т.д. — когда он все это прилепит — у него и получится обычный фреймворк, только зависящий от кучи разных библиотек, не протестированных на четкую работу вместе, отсутствие единого вектора в развитии (библиотеки будут развиваться отдельно и по разным векторам, так как они все от разных разработчиков), отсутствие единой документации и единого хранилища и т.д.
При этом все, что указывалось как недостаток обычных фреймворков будет точно также.
Тогда смысл? :D
«Главное отличие библиотек от фреймворков в том, что фреймворк запускает ваш код, и, в общем случае, контролирует свое собственное окружение; в то время, как библиотека – это нечто, что вы используете из своего кода, контролируя свое окружение самостоятельно»
Т.е если упрощать, то фреймворк управляет кодом приложения, а при использовании библиотек, код самого приложения управляет библиотекой. Под спойлером картинка.
микрофреймворк — задачу и смежные с ней
Нет, смысл совсем не в размере, охвате и пр.
Суть в направлении контроля. Фреймворк вызывает Вас. Вы вызываете библиотеки.
А на самом деле он слепил свой собственный неуклюжий фреймворк, за бортом осталась шаблонизация… не протестированных на четкую работу вместе
Почему это он неуклюжий? Зачем мне шаблонизация, если у меня строго JSON API? Суть — с введением PSR можно самому собрать собственный фреймворк, делающий ровно то, что нужно и ничего больше, из кода разных производителей.
Тем более разговор был про микрофреймворки, не так ли?
Можно ссылку почитать такое определение для микрофреймворков?
Ибо ИМХО push/pull — это модель работы, но ни как не определение.
Единственное, с чем согласен — что фреймворк (не микрофреймворк) всегда идет со своим окружением, которое он постоянно поддерживает в актуальном состоянии — на то он и «каркас».
Интересное определение, а если библиотека вызывает Ваш callback (любой eventer) — она сразу же становится фреймворком?Я бы сказал что всё зависит от «масштабов бедствия»: если подавляющее большинсво кода, использующего библиотеку не является кодом callback'ов, то, конечно нет. От того, что вы callback на три строки в qsort передали libc не станет фреймворком.
А вот если у вас большая часть приложения, общающаяся с библиотекой и состоит из этих callback'ов… тогда да. Скажем GTK обычно позиционируется как библиотека виджетов, но на практике — это скорее фреймворк.
Хотя да, конечно, бывают и пограничные случаи…
А на самом деле он слепил свой собственный неуклюжий фреймворк,… у него и получится обычный фреймворк, только зависящий от кучи разных библиотек, не протестированных на четкую работу вместе
В этом-то и идея PSRов, что реализуя интерфейс, не нужно тестировать взаимодействие, потому что оно гарантировано контрактом и тестами самой реализации.
Современный фронт ещё более бессмысленный
После этого решил, что не зачем выпендриваться — минусов больше чем плюсов.
но для обучения полезно, спору ет
Спасибо за ссылки для дополнительного чтения.
Про луковицу в качестве метафоры для middleware не верное предложение, middleware как раз позволяет соединить несколько луковиц, независимых между собой, связанных только диспетчером.
Луковица подразумевает сильную связность внутри слоя и слабую связность между слоями, а самое главное уникальность функционала для каждого слоя.
В то время как одно middleware может проводить анализ данных, так и следующие middleware может проводить анализ тех же самых или уже изменённых данных, то есть слой анализа дублируется в разных middleware.
Про микро-фреймворки очень справедливое замечание, я знакомился со Slim-ом, он умеет две нужные вещи:
- роутинг,
- конвейнер мидлвэер
и больше ни чего, то есть весь функционал того что есть в статье. Свой велосипед делать не надо.
Что касается луковицы, то я думаю, что метафора скорее относилась к принципу работы pipeline (когда массив middleware сворачивается в рекурсивный вызов через array_reduce), нежели к "луковой архитектуре". И действительно
$response = $middlewareA($middlewareB($middlewareC($request)));вполне себе "луковица".
<?php
$app = new \Slim\App();
$mw = function ($request, $response, $next) {
$response->getBody()->write('BEFORE');
$response = $next($request, $response);
$response->getBody()->write('AFTER');
return $response;
};
$app->get('/', function ($request, $response, $args) {
$response->getBody()->write(' Hello ');
return $response;
})->add($mw);
$app->run();
то есть перед вызовом (вместо
$response->getBody()->write('BEFORE');$request, $response$response->getBody()->write('AFTER');$request, $responseфизически оно запускается как луковица, но если подумать то можно сделать последовательную логику работы:
<?php
$app = new \Slim\App();
$mw1 = function ($request, $response, $next) {
// business logic BEFORE with mutate $request, $response
$response = $next($request, $response);
return $response;
};
$app->add($mw1);
$mw2 = function ($request, $response, $next) {
$response = $next($request, $response);
// business AFTER logic with mutate $request, $response
return $response;
};
$app->add($mw2);
$app->run();
Без фреймворка хорошо писать только в целях саморазвития для своего личного проекта где вы будете сами это все поддерживать, но для коллективной разработки лучше всетаки использовать фреймворки так как они вносят свои стандарты построения приложений.
Ну т.е. скажем так. Некоторая часть фрейма отлично выдирается: Контейнер, саппорт, пагинатор и проч., а некоторую даже при всём желании адекватно не получится.
Мой месадж был о том что какраз эта прибитая гвоздями организация кода и позволяет командам писать код в пределах фреймворка который будет понятен всем. Когда при кастомном решении новому человеку пришедшему на проект надо будет вникать во все ньюансы самописного решения и думать как ему встроить что то новое чтобы не сломать старое.
А насчет Laravel впервые слышу что там что то прибито гвоздямида цитирование просто забыл. Теперь будете знать, что не всё в Багдаде спокойно, хотя казалось бы… =)
P.S. ну и да, доп пакеты типа пасспорта, довольно жестко завязаны на ёлку.
У меня конечно осталось ощущение переусложненности. Ну например, зачем делать объект "вызываемым" через invoke, когда можно сделать обычный, немагический метод? Ради чего? Такое ощущение, что они используют invoke просто чтобы он был.
Насчет DI контейнера — по моему, Pimple проще. Там определение сервисов делается просто через анонимные функции, без этих громоздких конструкций \DI\create(Some::class).
Зачем нужно тут middleware? По моему, проще роутер просто вызывать напрямую и обойтись тем самым без библиотеки Relay. Или целью автора было использовать очередной PSR?
А так, конечно, я не вижу ничего плохого. В той же Симфони мне например не нравится куча конфигов, модуль security и неявные вещи, вроде всяких обработчиков событий, из-за которых мы не можем легко проследить, как выполняется код, начиная с index.php.
Где в Symfony сильная связанность
Ну на самом деле куча бандлов, идущие как стандартные, представляют собой месиво, гвоздями приколоченное к некоторым основным компонентам (типа Доктрины). Как будто сделано все, чтобы показать, что наличие интерфейсов еще не означает слабую связанность :).
И относиться к этому надо именно так. И особенно разрабатывать код. И выбор фреймворка не что-то судьбоносное, а просто «мне нравится дефолтный выбор компонентов», «но если что — полностью перепахаю за денёк».
Нет, писать свои велосипеды очень плохо. Сколько раз не приходилось сталкиваться с кодом, который был написан не на основе фреймворка или другого готового решения, это всегда был ужасный неподдерживаемый код.
Человек, не способный разобраться в чужом фреймворке, сделать на его основе высокоэффективное решение, не сможет создать свое решение, которое превосходит готовый фреймворк хоть в чем-то. Это аксиома.
Имеет смысла писать без фреймворка для того, чтобы понять, как оно все работает. На учебных проектах. Можно личный блог написать без фреймворка, или какой-нибудь другой игрушечный проект. Но ни в коем случае не production код.
Еще раз повторюсь: я еще ни разу не видел, чтобы человек, строящий велосипеды, смог сделать велосипед лучше существующего. Ни разу. Кроме тех, кто построил уже существующие фреймворки, но эти люди не начинали с нуля, у них уже был огромный опыт, и они понимали зачем строят фреймворк.
Кроме того, свой велосипед:
а) не будет иметь документации (в 99% случаев)
б) не будет иметь тестов (в 99% случаев)
в) будет использовать непонятные большинству сторонних разработчиков соглашения об именах, расположениях файлов, конфигурации, и т.д. и т.п.
г) не будет совместим с имеющимися батарейками для других фреймворков, всю дополнительную функциональность придется писать всегда с нуля
Я помню, как в одном проекте разработчик создал свой мета-фреймворк над фреймворком. Все функции и классы в нем назывались одной-двумя буквой для краткости. Например:
T -> render_to_response
R -> redirect
RV -> redirect_to_view
E -> return HttpResponseError()Это все было понятно ему, но когда он ушел из проекта, а на его место взяли меня, мне пришлось выучить около 20-30 этих сочетаний, причем не всегда они именовались логично. А дальше я столкнулся с тем, что он определил несколько модулей utils в разных пакетах, и в некоторых из них однобуквенные функции переопределялись, причем с немного иной семантикой… Тут начался ад, и я постоянно сталкивался с ошибками, так как мало того, что надо было вспоминать, что, например, обозначет RV('people-list'). Надо было еще каждый раз смотреть в начало файла, чтобы посмотреть, из какого именно пакета это сокращение импортируется. Затем надо было вспомнить или посмотреть, что именно делает RV в данном пакете.
Через месяц мучений, я выкинул все это, и переписал на обычных вызовах методов фреймворка. Мне не сложно вместо T написать render_to_response, тем более, что сейчас все редакторы и IDE поддерживают autocomplete или дополнение по образцу (Alt-/ в Idea). Зато абсолютно любому человеку, приходящему в проект, сразу понятно, что делает код.
TLDR: Изобретать велосипеды очень плохо, всегда получаются квадратные колеса. Всегда.
PHP исполняет серверные приложения в цикле запрос/ответ. Всё взаимодействие с приложением — из браузера, командной строки или REST API — приходит в него в качестве запросов. При получении запроса приложение загружается, обрабатывает запрос и генерирует ответ, который передаётся обратно клиенту, а приложение закрывается. И так происходит при каждом обращении.
Не всегда, не нужно быть столь категоричным. Не забывайте, что php-приложение может запускаться БЕЗ запроса и при этом ничего не отправлять клиенту, запускается по крону, к примеру, собирает данные из нескольких баз, обрабатывает и складывает их в другую базу. И не стоит забывать, что php-скрипт вполне можно демонизировать, тогда оно завершаться будет только в исключительных случаях.
PSR-7 + PSR-15 позволили решать часть типовых задач отвязано от фреймворка X, на котором нравится писать. Самое ценное то, что благодаря стандартизации стало реально заменять реализации и использовать интерфейсы, без написания собственных адаптеров или интеграций. Как выше упоминалось, разработка простого приложения, действительно, сводится к скачиванию пакетов и выстраиванию цепочки их выполнения через PSR-15.
Но мне что-то не приходит в голову кейс где будут множественные проверки существования класса, так чтобы не городить уж очень кривое что-то.
Проверка существования класса как по мне должна в случае его отсутствия объявлять ему замену. Других кейсов я не вижу.
Какие-то попытки автоматического внедрения зависимостей по цепочке воркараундов?
Ну это само по себе глупо. Ну в смысле цепочки делать. Пойди найди потом какое из умолчаний у тебя сработало.
Нет, возможно я что-то упускаю. Можете привести пример? Любопытно.
Или вы имеете ввиду не кеширование внутри сессии, а кеширование МЕЖДУ сессиями, типа сохраняем список несуществующих классов в файлик и при запуске автозагрузчика загружаем только этот файлик с отлупами?
Вы замеры делали? На сколько это реально тормозит систему?
А то мне это напоминает оптимизацию через одинарные кавычки.
Я раньше пытался бороться с этим, даже удачно. Но сейчас решил что дешевле сменить хостера.
Может у вас кэшировался — у меня вот нет. У меня быстрые скрипты без фреймворков — там весь скрипт менее чем за 1мс выполняется, причем большую часть занимают запросы к БД. Так вот xhprof явно указывал что выполнялось много лишних файловых операций проверки file_exists из автолоадера.
Сейчас точно не вспомню, но мне кажется в phpmailer была как раз проблема у меня в консюмере, что автолоадер там с ума сходил.
Не знаю на счет кеша в разных сессиях (не проверял), но в пределах одной у меня он всегда работал.
Может у вас не настроен realpath_cache_size?
В контексте composer, например, есть несколько уровней вариантов оптимизации автозагрузки: https://getcomposer.org/doc/articles/autoloader-optimization.md. Этот же механизм позволяет легко отлаживать проблемы, которые могут быть вызваны некорректной автозагрузкой классов.
Сейчас кодить без Фреймворка — это что-то сложное и признак мастерства?
А не получается без фреймворка.
В принципе не получается.
Один раз вкусил и всё. Без него уже не можешь. Как наркотики.
Сколько раз я уже начинал «простенький проект, будем без фреймворка делать». Какой-то MVP-одностраничник, или просто расколупать шаблон перед натягиванием (большой шаблон, типа AdminLTE, но все равно) — чисто разобраться во внутренностях, порезать на куски…
Потом вдруг очнешься посередине, а у тебя уже микрофреймворк написан.
Минимальный шаблонизатор на 20 LOC, минимальный функционал мультиланг на 50 LOC, ассетсы на 20 LOC, сахарная функциональщина ко всему этому на пару дюжин строк, а дальше уже просто не можешь удержаться и не сделать роутер на дюжину строк, и потом в это все внести хоть в структуру MVC. И всё. По сути это уже не «без фреймворка». а пусть и совсем крошечный и не полноценный, но фрейиворк.
Но банальный DRY вынуждает писать шаблонизатор. Иначе будет капец.
Потом еще что-то, еще что-то и просыпаешься с готовым фреймворком.
Буквально пару десятков разных страниц, пару дюжин UI-компонент (часто со своими зависимостями) и всё, приехали. Разобраться в портянке невозможно.
CSS на полсотни килобайт листать для каждой правки. Потом потерянный мертвый код, ад зависимостей (всякие js/css библиотеки… кому они нужны? Может я уже удалил это давно? А что это за css-класс такой? Где он используется?).
Начинаешь таки упорядочивать.
Хоть минимально чтобы css/js и подгрузка внешних файлов для них лежали в одном месте с шаблоном который их использует. И компилировались на лету.
А значит уже минимальный ассет-менеджер.
Потом понимаешь что все равно придется делать двуязычную версию. Да и клиент захочет править всякие строки отдельно, не заглядывая в код.
Выносим все строки в json-ы к одноименным шаблонам.
Готов еще один класс в наш фреймворк.
Нет, нет, я не буду писать роутер. Нет, у меня только одна страница всего. Ну хорошо две, языки еще разные, но я могу это одной строчкой написать.
Ну ок, есть еще чуть другой интерфейс для админа, но что ради этого роутер писать? Не буду! Статические файлы? Кишки «фреймворка» спрятать в хтаксесс? Все равно не буду. Черт, еще форма фидбека и страница ЧАВО. Ну хорошо, хорошо, пять строчек роутера это не фреймворк…
Контроллеры? Ну блин, есть же контроллеры в ангуляровской части! Ну ладно, ладно, напишу, а то будет как с роутером.
Черт, как все-таки удобно когда формы генерятся из модели автоматом. И валидация…
Даже и не думай! Не думай я тебе сказал!
Вот как-то так было у меня в голове крайнюю неделю.
И то что вышло в итоге — уже микроскопический, но фреймворк.
Ну не получается у меня без фреймворков. Не получается.
не надо разбираться с фреймворками, который каждые пару лет меняются и помирают, в которых находят дыры и надо держать руку «на пульсе» чтобы сайты на их основе не подвергать риску
Этому явлению есть давно устоявшееся название: «Неуловимый Джо» называется.
Есть такая известная атака из класса «человек посередине». Подобную уязвимость находили во многих фреймворках. У вас не находили.
Атака заключается в уводе сессии или просто XSRF вскрывая токен безопасности манипулируя юзерконтентом и анализируя степень сжатия страницы.
Как у вас с этим? Наверняка продумали...)
Ну и я не стану придираться к «У меня SSID генерится на основе useragent+remote_ip (и немного соли, но не суть)». Предположим что вы просто неудачно выразились, а имели ввиду нечто иное.
У меня несколько иной чем у вас уровень проработки подобных вопросов, но я уверен что если бы я выкатил свой фреймворк в паблик то сразу бы получил парочку пулреквестов по безопасности. Вот 100% уверен!
Вот каждая фраза в вашем комментарии. Каждая. Отстает лет на пять от современного веба. Ай, ладно. Пошел я пить в общем…
Кажется вы не читали: https нет
Еще раз. Восстановим логическую цепочку. Наш спор начался с того что я вам сказал что вы Неуловимый Джо. Дальше в принципе можно не продолжать. В «молодости» регулярно осуществлял MITM. Это было еще во времена махрового диалапа. То таки да линию слушали, чего уж там. То знакомый у провайдера работал, с коровского маршрутизатора сливали. То еще что.
Бывало и наоборот. Аську мою шестизнак именно через MITM увели. Про корпоративные сети/точки доступа я в принципе молчу как и про интернет-клубы.
В эпоху вайфая… просто вайфая, не обязательно публичного/бесплатного — говорить о том, что я защищен настолько что MITM мне не важен, значит быть Неуловимым.
Я не буду с вами спорить, объяснять и т.п.
Я помню как мне объясняли примерно тоже самое.
Это было аккурат в 2007-м. Сейчас стыдно. Но есть понимание почему стоит таки закончить спор.
ПС: дизайн конечно зачетный. Даже без учета что тогда это было не настолько ретро. Жаль что эту мешанину из невалидного кода построенную на таблицах не очеловечить (я понимаю, 2007-год, без сарказма, тогда оно было норм). Так бы клянчил шаблон в паблик).
"сколько сил вы затратите на подмену IP (либо отправку от клиента) и выуживание инфы из кук конкретного браузера у пользователья?"
Очень часто в условиях дороговизны IP адресов тысячи пользователей сидят под одним IP адресом за NAT или прокси — коллеги, семья, соседи. И довольно часто именно они заинтересованы в доступе к личной информации типа переписки, с одной стороны, а, с другой, имеют множество возможностей для применения методов социальной инженерии, чтобы получить заветную куку, вплоть до физического доступа к девайсам.
Внедриться посередине на сегодня вообще не проблема. Если раньше надо было иметь доступ к сети провайдера (не всегда, но хорошо бы), то сейчас всегда есть возможность внедриться.
А вот провайдерский NAT даст не так много возможностей. Ну в плане того что да, у меня шаред-айпи, да у всех моих соседей по дому тот же айпи. Да, некоторые из них могут социальной инженерией затащить меня на сайт с которого были вызовы разных страниц. Но ответа то нет. И даже по стороннему каналу (размер ответа) тут не получить информацию.
Существует очень много векторов атаки с человеком посередине. И как правильно вам сказали — очень часто интерес к доступу к вашим данным может быть не у далекого пользователя, а у человека имеющего с вами физический контакт — коллега, сосед, родственник… Нет, если мы говорим о админе говносайта или красивого хомяка с ретро-шаблоном, то да, тут кроме как автоматическим сканерам уязвимостей вы не интересны никому. Но если это живой проект. Не Неуловимый, то всё. Без сертификата жизни нет.
И речь не только о банках, ERP и т.п. Почта, социалки, форумы… все что угодно. А хомяки, простенькие статейники и т.п. — да, они никому не интересны, и атаковать никто не будет.
Ну а когда разработчик переходит во взрослую жизнь, то вот эта вся неуловимость быстро заканчивается…
Вообще, крайне не ясно как обсуждение «без фреймворка можно все реализовать точно такое же, но за чужим кодом надо следить в плане обновлений в силу их распространенности» скатилось что я — Неуловимый Джо. Вы хотите поспорить что можно все написать без фреймворка? Или то что реализация в нем сильно отличается от своего кода настолько, что «безфреймворковский» код априори более дыряв?
Можно написать «без фреймворка», просто выйдет свой фреймворк. Без вариантов. И реализация в фреймворках примерно такая же. Только в несколько раз больше вещей продумано. И продумали они не потому что какие-то особенные люди их пишут, а потому что больше опыта, больше людей пишут, больше пулреквестов присылают или уязвимостей находят. У них просто больше ресурс.
Писать без фреймворков конечно можно. Когда у тебя уже есть большой пул своего кода, который учитывает большое колво нюансов, написан с учетом регулярного переиспользования, имеет хорошую инкапсуляцию (по степени коровости, по уровням абстркции, по разному функционалу и т.п.).
Тогда ты можешь взять этот свой бутстрап, дописать то что нужно в этом проекте и все будет ок.
Да, если кто-то возьмет проект после тебя, то у него будет головная боль, но часто это допустимо.
Проблема в том, что реально это и будет фреймворк. Только свой.
А процедурная лапша написанная каждый раз почти с нуля для каждого проекта, без тестов, без документации, с ограниченным функционалом и т.п… Ну это для обучения/развлечения. Нет, можно и на вордпрессе писать. Он хоть неплохо отлажен.
Синтаксический сахар — это, скорее, библиотеки. Фреймворк — это, всё же, имплементированный набор архитектурных решений, в рамках которого создаётся приложение.
Если вы новое приложение начинаете с пустого каталога, в подкаталог lib которого постепенно по мере надобности копируете прошлый наработки типа роутеров, валидаторов и т. п. (при этом они друг от друга не зависят), то это не фреймворк. Если же вы копируете прошлый проект, удаляете из него всё специфичное для прошлоги и ненужное в новом, а потом в основном дописывате нужную функциональность, не меняя общий поток данных, используя те же умолчания, те же, пускай и немного подправленные конфиги и т. п., очень грубо, оставляете тот же index.php, изменяя только то, что он внутри себя вызывает, оставляете ту же структуру каталогов, на которую ваш код рассчитывает для, например, вычисления полного имени шаблона как './templates/' . $action_name, то ваши наработки — суть фреймворк, а не просто набор библиотек, которые часто переиспользуются в разных проектах.
Уже на второй дюжине проектов ядро будет переписано так, чтобы повысить его инкапсуляцию, чтобы было проще обновлять. вот нашли багу у себя. И что с прошлыми проектами? Должна быть четкая граница между прикладным кодом и ядром. Желательно конечно в контексте композера.
Ну и граница «копируешь нужные либы» и «копируешь проект целиком» не очень формализована.
Ведь индекс.пхп тоже может быть либой).
Мне больше нравится определение: отделен от прикладной логики и создает окружение, а не вызывается из окружения.
Тут более формализовано.
Изначальный мой тезис был в том, что если этот опыт есть, то что не делай, у тебя все равно фреймворк выйдет. Ты отделишь ядро для переиспользования. Ты сделаешь компоненты удобными для тестирования и т.п. Понимаешь как важны стандарты. Начинаешь с PSR-1/2/4, потом и прочие подтягиваются. Будешь регулярно добавлять разные вещи, в том числе и защиту от BREACH и прочего.
В ответ я слышу привет из девяностых. Мол хттпс не нужен, это лишнее. Так где ваш опыт то?
В любом роутере есть возможность или свой ДНС прописать или указать конкретные данные для конкретных доменов. Тут в принципе любой эникейщик справится.
Можно банально положить родной роутер и поднять рядом свой. С теми же данными доступа. Или даже не с теми. А с любыми какие есть у вас в сохраненных.
Этого достаточно.
Положить роутер? Ну кнопочку ресет зажать на две секунды, пока вышел в туалет (или хозяин в туалет вышел, не суть). Физически заменить на той же марки, только с другими настройками… Да мало ли вариантов? В каждом конкретном случае будет свое решение. Я ведь не говорю о чем-то требующем каких-то минимальных усилий, типа врезаться в ваш провод (в 70% случаев ничего и не надо, просто показываем на одном интерфейсе МАС клиента, на другом МАС провайдерского роутера, и перекидываем все с одного на другой попутно глядя что нам интересно).
Вся ваша защите строится на приемлемом уровне неуловимости, и в современном мире этот уровень очень низкий. Буквально какие-то хомпейджи и не более. Все остальное уже могут и будут ломать. Нет, всегда можно сказать «клиент сам дурак», и так оно и будет — видел ведь что у вас сертификата нет, а зарегистрировался. Но… непрофессионально.
Я думал у вас уровень Милторга.
А тут совсем школота.
Ок. Из простенького, что сразу в глаза бросается — у вас XSRF везде. Под рукой нет ни одного тестового домена без https, так что дать рабочую ссылку не могу, но от своего имени я проверил.
Демонстратор выглядит например так:
<form action="http://desksoft.ru/index_r.php?inline=mchat" method="post">
<textarea name="mchat_rep">Hello World!</textarea><br>
<input value="Send" type="submit">
</form>
Я так понимаю там еще баг с редиректом назад, по идее если будет незащищенный хост в который класть закладку, то будет норм. Но в любом случае такие вещи кладут в невидимый ифрейм и отправку формы делают из жс, так что даже в таком виде вполне нормально работает.
С учетом вашего уровня знаний я уточню:
Для взлома человека залогиненного на вашем сайте нужно чтобы он зашел на какой-то сайт, где будет данный експлоит.
В целом можно почти любые действия организовать.
Рассылка в личку, смена пароля и т.п.
В целом это основы. Что очень хорошо показывает насколько можно быть неуловимым. Галочка «запомнить» есть, так что пользователи с живой сессией тоже есть. Были бы вы кому-то интересны, вас бы уже давно вскрыли.
Ну и собственно весь остальной ваш бред про то что все вокруг ничего не понимают, один вы в танке — из той же оперы.
Допустим, есть пользователь, который при логине на ваш сайт поставил галочку «Запомнить меня». Некто отправляет ему ссылку «посмотри». По ссылке открывается страница с котиками и с кодом, который выше. И пользователь выполняет некое действие на сайте, даже не подозревая об этом — отправка сообщения, изменение пароля, отправка платежа. Это в чистом виде XSRF.
Максимум можно сделать все то, что доступно текущему залогиненому пользователю. Если вы залогинены администратором и откроете ту ссылку, сообщение будет от вашего имени. Именно поэтому вы и являетесь Неуловимым Джо, так как у вас функционала-то и нет, чужие мессаги не нужны никому.
Неважно, какая у вас проверка в формах, если это не аналог CSRF-токена на каждый запрос. Можете подробнее ее описать? Подозреваю, что и ее можно обойти аналогично.
1 день, каждую форму? Вот еще один плюс фреймворка. При правильной организации кода токен проверяется в одном месте. Создается тоже в одном, в какой-нибудь функции
beginForm(). Контролируется флагами. Проставить флаги для нужных действий дело нескольких минут. А с учетом того, что проверка csrf есть по умолчанию, надо просто найти и убрать все выражения вида 'enableCsrfValidation = false'Laravel Yii2 Symfony Zend
хорошая тренировкаДля тренировки можно много чего сделать, но для рабочих проектов это не подходит. Фреймворки люди используют не чтобы 'играть в «ООП ради ООП»', а чтобы не тратить время на реализацию того, что уже реализовано, и не исправлять ошибки, которые уже исправлены. А чтобы всем этим управлять, используется то, что описано в статье.
Про уровень «мы ничего не сможем сделать без фрейма» там вообще ничего нет. Наоборот, речь идет о полностью своем коде, который получается похожим на фреймворк, а не об использовании известного фреймворка. Так что логическую цепочку переворачиваете вы.
Можно? Можно. Просто никому не нужно. Ну кроме тех, кто не захотел хотя бы в одном фреймворке разобраться. Поэтому они используют «свой движок для сайтов», который по факту тоже фреймворк, только с очень ограниченным функционалом.
который по факту тоже фреймворк
Если бы. Я уверен что там под капотом жуткий WET, процедурщина в лучших традициях вордпресса (что тогда было уместно, но не сейчас), и гремучая смесь логики и представления.
Я думаю что то что там под капотом фреймворком можно назвать с большой натяжкой, ибо с таким подходами к архитектуре какие мы тут слышали — закладывать переиспользование кода человек явно не умеет.
и сказал это тот самый человек, который
Ну да. А еще этот самый человек в свое время находил закладки в обслуживаемой им инфраструктуре которые ставили СБУшники. А еще у этого человека в его собственном фреймворке XSRF нет, и проблем с «пользователи жаловались что в разных окнах...» тоже нет, поскольку этот самый человек чуть знаком с тем как работают сами уязвимости, аналитикой по этому поводу, и знает что не стоит дуть на воду с кучей «всегда новый токен», и ради этого оставлять кучу уязвимостей.
Т.е. человек утверждает что без них абсолютно никуда.
Именно. Именно это и утверждает, да.
Цитата из начала треда, где я это утверждаю:
Сколько раз я уже начинал «простенький проект, будем без фреймворка делать».
…
Потом вдруг очнешься посередине, а у тебя уже микрофреймворк написан.
Не говнокод, который пишут
инвалиды-формошлепы какие-то
а именно фреймворк, потому что даже когда решил по быстрому что-то набросать, руки уже сами пишут DRY и SOLID.
и да, не стыдно писать говнокод. Все когда-то говнокодили, и все мы (ну кроме вас конечно) через некоторое время глянув на свой текущий код будем испытывать стыд, что такое писали. Это норма.
Ненормально застревать в этом говне.
Похоже СБУшники ваши сами не далеко ушли
Недалеко ушли от кого? От вас? От меня?
Ну да, они использовали довольно простую уязвимость.
И да, я также само как и вы упирался, мол «да нет там никаких дыр, явно люди сливают». Но все равно проверил. И нашел. Не то, чтобы это был прям какой-то серьезный уровень, я бы даже сказал что не большой, но в отличии от вас кое-какой реальный опыт в безопасности у меня есть, да.
А вообще этот тред, хоть и «несколько затянулся», и думаю именно за это мне прилетают «то о чем нельзя говорить», но очень психологии.
Вам объяснили где у вас проблемы с безопасностью. Вы возразили мол безопасность канала вообще не нужна. Вам дали кейсы. Вы сказали мол «все это сложно, а кто говорит что просто — выпендривается». Ок, вас ткнули носом в простенькую уязвимость в вашем сайте. Вы сказали что это не баг, а фича. И вообще оппонент не понимает что такое XSRF. Ну и вишенкой на торте — оценка квалификации особистов, причем со слов, в ситуации о которой вы вообще не в курсе. Браво!
Так толсто, что даже тонко. А мы упорно продолжаем что-то доказывать, объяснять…
И я сказал что изъяны в безопасности для указанных сайтов допустимы
Ну мне то вы сказали, да. Но я не нашел на сайте предупреждения о том, что поскольку вы умеете писать без фреймворков, то возможность выполнения любых действий любым пользователем, от их имени на этом сайте является допустимым.
К тому же шифрование вы быстренько поломали (BREACH), потому от него толку нет
Ну я встречал велосипеды в которых BREACH закрыта. А так то все фреймворки закрыли эту уязвимость еще в 2013-м.
BREACH я упомянул лишь потому что она с одной стороны достаточно известна, с другой стороны велосипедисты про нее часто не знают. При этом она проста, и вполне себе реализуема «в быту».
Я не говорю об относительно взрослых вещах вроде того почему в пхп появилась функция password_verify.
Почему ваш сайт просуществовал с такой огромной дырой двадцать лет? Потому что вы Неуловимый.
Почему дырЫ вообще появились? Потому что вы:
а) пишете без фреймворков,
б) не имеете достаточной квалификации чтобы писать без фреймворков.
Всё.
Да и в принципе о чем можно говорить если дыра на виду, и владелец сайта считает что это не баг а фича?)
все ваши попытки за последние дни увеличили ежедневный лог атак в полтора-два раза
Вот это да, любопытно. Учитывая что попыток как таковых в принципе не было. Отсутствие защиты от XSRF я заметил сразу, когда заглядывал на верстку, на вопрос того можно ли что-то почерпнуть. Так что попыток как таковых и не было. Просто открыл в браузере код страницы, скопировал форму в жсфидл, убрал незначащие атрибуты, нажал кнопку, браузер отказался переходить в связи со смешанным контентом, так что к вам она не прилетела. Следующее действие было с своего тестового поддомена, она была удачной, и собственно все. Т.е. ровно одна запись в логе увеличила колво атак в полтора-два раза. Итого выходит в среднем менее одной атаки в день? Маловато как-то. Я думал сайт более посещаемый.
Он же уже прямо сказал что он Неуловимый. Что все что там есть он спокойно вытирает. Бекап наверняка есть.
Последствий не будет.
XSS он худо-бедно закрыл. Может не везде конечно, но и без того дырявых сайтов хватает.
Увод клиентских аккаунтов? Ну да, у смены пароля тоже нет XSRF-токенов, но ведь он прямо сказал что пользователи его не интересуют. Увести его акк?
Ну если он наврал что ходит через отдельное соединение, то возможно. Но опять же — бекап решает.
Нет, можно вскрыть его капчу, благо для таких капч есть готовые библиотеки, да и вполне вероятно что есть и другие уязвимости у нее. Тогда можно спам рассылать будет. Но… да кому оно надо с этим играться? Хостер быстрее забанит его, чем ты вскроешь капчу…
Ну нет там ничего кроме идеи.
Верстка ужасна. Да и если бы была нормальная — проще сохранить хтмл и разметить под себя, чем разбираться в чужом коде.
Может SQL-иньекция есть. Наверняка там только самые примитивные методы используются. Наверняка без PDO (а уж свои параметризированные запросы делать он точно не способен), так что если покурить, то наверняка можно будет что-то придумать. Но… результат какой? Откатит из бекапа и будет дальше рассказывать о том какой он неуловимый.
Не думаю что кто-то еще найдется такой же отмороженный как я, чтобы колупаться.
Примерно сразу. Например многократно упомянутый тут BREACH был найден у всех без исключения фреймворков. в 2013-м. И у всех же был закрыт. Примерно тогда же.
Сейчас 2018-й год, и чувак рассказывает о том, что XSRF во всех формах клиентов включая смену пароля это фича такая, ведь он не смог придумать удобный вариант защиты а потому защитил только админку… в 2018-м. XSRF. Не баг, а фича. Если мы говорим о любом адекватном фреймворке то такого у них нет лет пятнадцать как минимум.
Насчет нужности тоже все просто. Если на форуме хоть кто-то сидит — значит, он ему нужен.
Есть задача — сайт должен быть написан быстро, и его характеристики (в том числе и безопасность) должны не слишком уступать большинству современных сайтов.
Фреймворк — быстро, минимум глюков.
Велосипед — медленно, много глюков.
А чье несовершенство — уже не важно. Вообще не важно.
Кому понадобится внедряться в хостинг / провайдер / постороннюю квартиру для организации MitM против простенького сайтика?
Ну примерно с этого все и началось. Антонн утверждал что у него все чики-пуки и без фреймворков, и без нормальной квалификации, я говорил что лишь постольку поскольку никто его и не ломает.
А кому надо? Ну вот есть у Антона форум, есть личка там. Решит муж или жена посмотреть с кем и о чем в личке на этом форуме переписывается благоверный… ну или коллега захочет узнать секрет о том, как в Делфи что-то сделать. А секрет ему гуру Антонн в личке написал. Мало ли?
И да, насколько мне помнится, достаточно долгое время XSRF очень многими гигантами индустрии и программирования расценивался именно как фича, а не баг.
На Хабре тоже было. Помню смотрел, увидел что есть, попробовал. Не сработало. Забил. Через год вижу статью. Кто-то не забил, расколупал, что оно работало только если запрос аяксовый). Но!
1) ТМ оперативно закрыли дыру а не стали рассказывать басни
2) это ж когда было то? Еще при царе Горохе
Если бы в NASA писали на фреймворках, то, боюсь, до сих пор ни одного спутника запущено бы не было, всё ждали бы, пока программисты доведут прошивку до production-ready
А если бы все писали всё самостоятельно, без чужих библиотек, то ваше сообщение я бы читал с перфокарты.
А вот вылез какой-то страшный баг во фреймворке, и ты сидишь и думаешь — как же теперь эту сборную солянку из непонятных библиотек, полных магии, обновлять?
Так а что сложного то? Просто берешь и поступаешь как Антонн — говоришь что это не баг а фича, и всё, проблема решена.
А если серьезно — да, с некоторого уровня квалификации свой код будет не сильно уступать, а местами и выигрывать. Но при этом он будет сильно ограничивать тебя в скорости разработки чего-то более-менее серьезного.
Впрочем, в любом случае, любая система при должной на то необходимости легко ломается
Не так давно случившийся новогодний коммит в OpenSSL должен служить тому хорошим подтверждением.
И далеко не так прекрасен код во всех этих молодёжных фреймворках и библиотеках.
но стремись они за модой
Это как-то влияет на преимущества использования фреймворков или на необходимость защиты от уязвимостей?
Это как-то доказывает необходимость использования своей системы шифрования вместо OpenSSL?
А кто говорит о том, что он прекрасен? И как из этого следует, что в своем коде будет лучше архитектура или меньше ошибок?
А кто говорит о моде?
В критических приложениях автор должен знать и понимать, что делает каждый байт его приложения
Эм, обсуждаемый сайт критическое приложение?
Из того, что есть приложения, которые лучше писать без сторонних фреймворков, не следует, что любое приложение надо писать без сторонних фреймворков.
Свой код можно обновлять по мере необходимости и атомарно.
Представьте себе, сторонний тоже.
как же теперь эту сборную солянку из непонятных библиотек, полных магии, обновлять? — ибо всё начинает рассыпаться
Для того, чтобы так не было, используется семантическое версионирование. Например, изменение последней цифры означает, что изменения не ломают обратную совместимость.
А вот как обновлять свой движок, скопированный на 20 сайтов в разных версиях, это непонятно.
Потому что свой код лучше изучен и понятнее его автору. Да, это может создать излишние издержки для бизнеса, но и добавит безопасности и маневренности.
Безопасности скорее убавит в теории — меньше людей проводят аудит. Насчёт маневренности спорно: в теории может и увеличить, но на практике у самописного кода гибкости меньше, чем у популярных фреймворков, меньше готовых точек для изменения поведения.
В том-то и дело, что никак абсолютно. Наплевать на фреймворки, от них ничего не зависит.
Зависит. Время разработки и наличие уязвимостей. Из того, что любую систему можно сломать, не следует, что любую систему не надо защищать. Фреймворки дают средства защиты сразу на старте.
Потому что свой код лучше изучен и понятнее его автору.
В рабочих проектах как правило более одного автора, а также время от времени появляются новые авторы. И для них этот код не свой. А если автор не знает про уязвимость, или сделал кривое средство защиты, то знание кода ее не уберет.
но и добавит безопасности и маневренности.
При этом подразумевается, что автор эксперт по безопасности. Никто не может предусмотреть все возможные уязвимости, и не каждый может грамотно написать защиту от них. И недавний коммит в OpenSSL это подтверждает.
И даже маневренности в большинстве случаев он не добавит. Потому что из-за большого объема работы появляется стремление срезать углы, и в результате получается нерасширяемый монолит.
Ну и что ж вы тогда так паритесь по поводу его уязвимости?
Парятся не по поводу уязвимости, а по поводу высказывания автора про уязвимости. А в данном случае я говорил про ваше высказывание, а не автора. Аргумент про критические приложения здесь не подходит.
Ага, в идеальном мире все и следуют семверу, и там никогда ничего не ломается из-за обновления зависимостей.
А идеальный мир здесь ни при чем. Вы сказали, что непонятно как обновлять. Я указал на то, что способ "обновлять понятно" есть. И в 99% случаев исправление бага в фреймворке не приводит к тому, что все начинает рассыпаться. Поэтому этот аргумент тоже не подходит.
ибо использование фреймворка никакой гарантии не дает
Некоторые гарантии оно дает. Весь фрейм ревьюить не надо, его уже отревьюили другие, проверили в работе, и на него даже есть тесты. Собственно, про такие высказывания я и сказал.
И про "из пушки по воробьям" тоже. Это экономия времени и других ресурсов, а не чьи-то прихоти. Никто вам не запрещает прописывать все вручную и кидать 400 на кавычку в запросе. Просто для рабочих проектов это не подходит. Никакой пушки тут нет, это именно правильное использование инструментов для достижения нужных целей.
Что он подтверждает? Что не надо пользоваться OpenSSL, а надо писать свое шифрование? Ни один специалист по безопасности такое не порекомендует.
Их обещания никакой силы иметь не должны
А обещания и не нужны. Нужен код, предотвращающий уязвимости, и код, исправляющий баги. А также код, проверяющий правильность работы того кода. Во фреймворке он уже есть, в самописном коде его еще нет.
Что не надо уповать на других незнакомых людей, которые не несут ответственности за свои правки.
Я же уже сказал, что ответственность других людей тут ни при чем. Важен только код. Так какой вывод-то из примера с OpenSSL, используем или нет? Если используем, понимаем что так лучше чем своя защита, значит это ничем не отличается от ситуации с фреймворками.
Если у вас нет — напишите, в чем проблема?
Хм, причем здесь я? Я разве что-то говорил про свой код?
Проблема в том, что его надо написать. А на это нужно время. И написать его надо качественно. А для этого нужна хорошая квалификация в задаче, которую решает этот код.
Ваш пример с кавычкой в запросе подтверждает мои слова про качество и про "срезать углы". Раз уж вы спросили про мой код, в моих программах пользователь может вводить все, что ему нужно, данные валидируются на соответствие бизнес-требованиям, ошибки показываются рядом с полями, введенный в форму текст не сбрасывается при ошибках, XSS и CSRF нет, так же как и SQL injection. И на все это я не пишу ни строчки кода, который это делает, разве что для валидации надо указать названия правил, которые применять к полю. То есть я получаю рабочую систему за 0 единиц времени.
А ну да, в квалификацию упирается. Фреймворк позволяет снизить порог вхождения.
Хм, может вы не будете играть словами? Я имел в виду квалификацию в задачах. Если задача кода связана с безопасностью — это квалификация в вопросах безопасности. Занимаясь 4-мя разными вопросами программирования по 2 часа в день вы априори меньший специалист в каждом, чем 4 специалиста, кто занимается каждый своим вопросом полный рабочий день. Потому что у вас ресурсов меньше.
какой мой «пример с кавычкой в запросе»?
Вот этот: http://desksoft.ru/index.php?search=%22test%22&f_a
На любое значение в GET-параметре с кавычкой у вас возвращается ошибка 400.
Вы уверены в этом исключительно потому что уповаете что «Фреймворк Джо» просмотрело множество «экспертов в безопасности» и нашли все уязвимости.
Сколько раз мне еще нужно повторить, чтобы вы обратили внимание? "Уповаю" я на наличие кода и тестов. То, что кто-то посмотрел фреймворк, лишь способствует появлению этого кода. То, что много людей проверило его в работе, уменьшает вероятность наличия ошибок.
Выше я вам привел OpenSSL, в котором эксперты тоже должны были посмотреть.
Я вам уже 2 раза задал вопрос по этому примеру. Из него следует, что пользоваться OpenSSL не надо, а надо писать свое шифрование, или не следует? Или есть какой-то третий вариант?
Раз вы его проигнорировали, значит понимаете, что ответ для вас неудобен. А ответ этот — пользоваться надо, потому что качество своего шифрования будет еще хуже. И примеров тому много.
Вот и с фреймворками так же. Нет никаких 100% гарантий, есть 2 варианта, и выбирают тот, который лучше. И чем больше код проверен в разных рабочих ситуациях, тем вероятность его правильной работы ближе к 100%.
Что именно пропускать в URL — исключительно желание моей левой пятки. Это не является ни багой, ни уязвимостью
Я разве с этим спорю? Я говорил о том, что мне вообще нет необходимости писать специальный код чтобы что-то ограничивать в URL. Это не является ни багой, ни уязвимостью, просто вы выдаете ошибку на валидный символ, так как опасаетесь, что где-то случайно пропустите его туда, где он нарушит безопасность.
Тесты пишут те, кто допускают ошибки.
Ну вот, теперь у вас и тесты не нужны, можно сразу без ошибок писать. Несмотря на то, что все известные опытные программисты говорят об их необходимости. Тесты пишут те, кто не хочет допустить ошибки.
Полагаю вы не разделяете однозначное суждение «фреймворк всегда надежнее»
Фреймворк всегда надежнее на момент старта. Если у кого-то есть ресурсы, он может написать свой фреймворк, который будет делать то же самое. Но как правило всех устраивает существующий функционал.
Прекратите передергивать, пожалуйста.
Я допускаю что тесты могут не найти всех ошибок
Ну как же это передергиваю, когда вы сами так написали? "Тесты пишут те, кто допускают ошибки" и "Тесты могут не найти всех ошибок" это неравнозначные утверждения.
Из первого следует, что те, кто не допускает ошибок, может тесты не писать.
У вас же наличие кода на руках и тестов — нет необходимости в ревью кода
Тесты дают достаточную гарантию, что оно работает, то есть защищает от тех уязвимостей, на которые есть тесты. 0-day уязвимости даже ревью может не найти. И ваш пример с OpenSSL это подтверждает.
Это не момент старта, это уже отлаженный код. Момент старта — это на коленке собрать за вечер сайт и опубликовать его.
Так вот чтобы получить отлаженный код, нужно затратить некоторые ресурсы. О чем вы спорите-то? Есть время и деньги — пишите хоть 2 года то же самое, тестируйте в разных условиях, и т.д. и т.п.
Момент старта есть у любого приложения. Вы утверждаете, что любое приложение создавалось за вечер на коленке и сразу было опубликовано? Думаю нет, следовательно ваше утверждение неверно.
На любое значение в GET-параметре с кавычкой у вас возвращается ошибка 400.
Михаил, ну что вы как маленький. Какое 400?)
Там 200. Вернуть 400 мы не умеем, или «а зачем? люди писавшие стандарты дураки, лучше редиректить на 200».
404 и 403 чувак тоже не умеет, везде 200. Так что про SEO можно забыть. Ну и так далее.
А еще мы с вами не понимаем, что лучше всего верстать таблицами. Ну а мобильная верстка для слабаков.
В общем это дешевый закос под Милторга.
Только с Андреем не понять он действительно дурачек или талантливо тролит, а тут все понятно.
А ну да, в квалификацию упирается. Фреймворк позволяет снизить порог вхождения. Не удивительно что такой «наркотик» затягивает людей…
Именно в нее и упирается. И даже вашей квалификации хватило бы чтобы писать грамотно.
А чуть позже можно было бы и попробовать что-то свое сваять. Накосячить как у вас, но получить опыт. попросить коллег ревью. Услышать замечания. Переписать. Еще раз. И еще раз. Потом посмотреть на то как у других, и написать лучше.
Вы хуже зеленого новичка.
Полного нуба можно взять стажером и сделать из него программиста. Из вас уже нет. Школьник понимает что он ничего не знает и не умеет, и готов учиться. А вы только упрямствовать. Фу таким быть.
Если у вас нет — напишите, в чем проблема?
Действительно. В чем проблема написать код который закрывает уязвимость? Тем более у всех она закрыта лет пятнадцать назад, и можно подсмотреть как это делают остальные если не осилил сам.
Мне например не стыдно было подсмотреть как в Yii BREACH закрыли, ибо сам не сообразил.
А вот оставить уязвимость потому что не додумался как ее закрыть — было бы стыдно.
но из-за защиты от которой отваливаются сторонние клиенты (ПО), ибо не умеют в токены (это предложение читать два раза)
Нет, и никогда не было ПО которое «не умеет в токены».
Зато есть разработчики которые не умеют в токены.
Для работы токенов достаточно работы сессии. Для сессий нужны или куки, или замусоревать урл.
Любой сайт написанный прямыми руками будет работать с защитой XSRF даже при выключенных куках и жаваскрипте. А если не будет (не верен что все текстовые/консольные браузеры нормально отработают, но вроде бы да, работали), то и авторизации пользователей у вас не будет.
Далее — проблема «открыл два окна» связана с тем что вы параноите, используя разные токены, хотя один токен на сессию вполне себе надежное решение. Но даже паранойя у вас выходит кривая. Да, необходимость в разных токенах никем доказана не была, но тем не менее, некоторые ее реализуют, и подобные реализации как правило не имеют проблему «открыл в другом окне, и в первом окне форма не работает».
Есть и всегда было ПО которое не умеет в токены.
Приведите пример ПО которое не умеет работать с токенами (в простейшем случае, с доп.полем в форме), и при этом будет работать авторизация (такая как у вас).
Ну хоть один. Можно такой который не существует сейчас, но был актуален когда вы начинали писать сайт.
Один пример. Всего один.
Вы запутались
У всех работает. У меня работает. У вас не работает. Но запутался я. Л — логика.
так как токен меняется после каждого POST
А зачем? просто потому что вы не разбираетесь в безопастности, в стандартах и т.п. но использовать код написанный теми кто разбирается вы не хотите — велосипед важнее.
Потому что так безопасней. Потому что более умные люди рекомендуют так делать (даже тут на хабре есть статьи с рекомендациями, именно менять токен после постинга)
Пруф?
DMclient
Из того что удалось найти — проприетарный офлайн-клиент для одного конкретного сайта/движка(?) работающий по неизвестному протоколу и заброшенный девять лет назад. Я правильно понял? Хорошая попытка. Еще варианты будут?
Про скорость разработки — утверждение спорное.
Если спорное, значит вы могли привести аргументы. Что ж не привели?
Если в случае А надо разрабатывать средства защиты, а в случае B они уже есть, то случай A займет больше времени, так как в силу законов природы мгновенно ничего не происходит. ЧТД.
Про остальное всё легко парируется тем же принципом неуловимого Джо.
Я об этом и говорю. Для своих проектов и если пофиг на пользователей и их наличие на ресурсе, можно делать что угодно. Но для рабочих проектов это не подходит. Именно это является причиной использования сторонних средств, а не мода или ООП ради ООП.
И у пользователей может быть другое мнение по поводу нужности их данных. Вряд ли кто-то предупреждает при регистрации — "безопасности нет, ваш аккаунт могут увести, просто это никому не надо, правда-правда".
А код фреймворка, вот эти все сотни мегабайт сторонних библиотек для Вас — свои?
"Потому что свой код лучше изучен и понятнее его автору."
"В рабочих проектах как правило более одного автора, а также время от времени появляются новые авторы. И для них этот код не свой."
Как ваш вопрос выше связан с этим диалогом? По каким причинам код фреймворка для меня или еще кого-то должен быть "свой"?
Вы сказали, что свой код лучше изучен. Я сказал, что это не аргумент, так как для не-авторов кода он не изучен вообще.
И да, код фреймворка, с которым человек раньше работал, знаком ему больше, чем самописный код, с которым он до этого ни разу не сталкивался.
А что, авторы фреймворка — могут?
А код фреймворка могут просматривать много разных людей. В том числе и эксперты по безопасности. И код фреймворка проверяется в работе на гораздо большем количестве сайтов, чем самописный.
Если Вы не умеете выстроить грамотно архитектуру приложения, то никакой фреймворк Вам не поможет.
В архитектуре средств защиты или других задач, которые решаются фреймворком — поможет. И даже даст пример, как сделать правильно.
Ну и зачем они тогда такие красивые вообще нужны, если ничего критического с их помощью не сделать?
Простите, вы вообще следите за диалогом?
"Обсуждаемый сайт критическое приложение?"
"Ну и что ж вы тогда так паритесь по поводу его уязвимости?"
"Парятся не по поводу уязвимости. Аргумент про критические приложения здесь не подходит."
Кто "они", фреймворки? Из того, что ваш аргумент не содержит обоснованные причины неиспользования фреймворка в некритических приложениях типа обсуждаемого сайта, не следует, что они не нужны. Наоборот, они как раз будут полезны на некритических приложениях.
Из этого даже не следует, что с фреймворками ничего критического не сделать, просто надо больше времени. А еще лучше использовать отдельные проверенные компоненты. О чем и статья.
Это всё уже какая-то левая лирика. Есть множество примеров, когда из-за обновлений ломалась куча кода.
В смысле, "левая"? Semver это именно средство решения проблемы "когда из-за обновлений ломалась куча кода". Средство решения проблемы никак не связано с проблемой?
И никто не мешает обновлять по требованию, обновлять на нужную версию, обновлять только совместимый граф зависимостей.
Например, где-то с год назад в одной npm-«библиотеке», состоящей всего из пары строк, допустили баг, а потом выяснилось, что от неё зависели десятки тысяч пакетов.
Да, хороший пример. Показывает, что цельный фреймворк гораздо лучше, чем куча библиотек, неизвестно как переиспользующих друг друга.
Мда, вы непробиваемы. Молодец, возьми с полочки фреймворк.
Ну ок, ок. Ну вот например SamDark — взял фреймворк «с полочки» и счастлив :). И таких тут много.
Semver это именно средство решения проблемы "когда из-за обновлений ломалась куча кода".
Всё же это средство уменьшить количество проблем "когда из-за обновлений ломалась куча кода". Гарантий, что даже при патчевом обновлении не сломается BC — нет. Стараются ломать только в мажорных обновлениях, но не всегда получается.
Так это понятно, ничего идеального нет, но придуман-то он был с этой целью. То есть явно не "как же теперь эту сборную солянку из непонятных библиотек, полных магии, обновлять? — ибо всё начинает рассыпаться". Не раз запускал composer update, ничего особо не рассыпалось.
Не раз запускал composer update, ничего особо не рассыпалось.
Особенно когда есть хоть мало-мальски покрытие тестами, да хоть какое-то подобие CI настроено…
композер аптейт, идем запарить чай пока тесты пройдут, коммит в мастер, на тестовом/деве по вебхуку вытягиваются свежие коммиты, бегло пробежались что не только синтетические тесты живы, но и глазами (ну не делают большинство разработчиков полноценного покрытия интеграционными тестами, не делают), дальше или отдаем QA (если есть), или на прод сразу.
Потому что свой код лучше изучен и понятнее его автору. Да, это может создать излишние издержки для бизнеса, но и добавит безопасности и маневренности.
Безопасности и маневренности… для автора. Просто в силу того, что код лучше знаком… автору. Что делает его относительно незаменимым. Ну и bus factor равный единице это круто да. Просто мечта любого бизнеса.
Только когда дело доходит до расширения выходящим за рамки фреймворка либо отлавливание багов — становится печально.
А можете пример привести, что там выходит за рамки фреймворка, да еще так, что он мешает за них выходить?
Например, ORM фреймворка, на которую завязаны генераторы форм, валидация, сериализация и десериализация и т. д., и т. п. А вроде хочешь простую вещь — при дегидрации заполнять одно свойство из связанной 1:1 таблицы как ValueObject, а не как ActiveRecord.
В принципе это не расширение, а вопрос связности, и архитектуры, но… а зачем? Вот чем так принципиально мешает активрекорд? Ведь по сути вы хотите заменить ORM на другой, с такой же функциональностью (активформ и все такое), но с другой логикой. Вы можете взять другой ORM, но у него не будет соответствующего функционала. Придется дописать.
Если фреймворк имеет нормальную структуру, то вполне найдутся интерфейсы которые нужно реализовать и все будет ок. А то что «никто до меня не реализовал ORM с теми требованиями что мне надо»… ну да, не реализовал. Но это ведь не трудности расширения, это отсутствие того что хочешь.
Ну можно вот так сделать:
public function getSomething()
{
return (new Query())
->from('{{%table}}')
->where(['id' => $this->table_id])
->one();
}
// $model->somethingЕще наверно afterFind() какой-нибудь есть. В крайнем случае можно переопределить функцию создания объекта модели.
Можно писать велосипеды.
Можно верстать таблицами (ну а чЁ? В девяностых же прокатывало).
Можно не использовать сертификаты.
Все можно.
Когда ты Неуловимый.
И да, можно оставаться Неуловимым довольно долго.
Вот буквально сегодня обсуждали один портал.
В свое время он был лидером в своей нише.
Сейчас тихо умирает. Но свои пару десятков тысяч пользователей еще сохранили.
Есть у них веб-почта.
Из инсайда известно что есть какие-то проблемы с безопасностью, у клиентов почту регулярно уводят. Саппорт стандартно рассказывает что это не мы, это вы, но поскольку там все в состоянии тихого умирания, то большего и не будет. Обсуждали совсем другой вопрос связанный с этим сервисом. И тут я чисто автоматом забиваю их адрес. Ну давно я там не был. И понимаю, что замочек зачеркнут красной полоской… Действительно, почему у клиентов почту уводят? Админ то наверняка через надежный канал заходит (как вы)…
В общем на данной веселой ноте я пожалуй произнесу волшебную фразу «Ой, всё!».
Что касается таблиц. Ну ок. Сколько времени у вас уйдет исправить свою верстку чтобы она нормально смотрелась на моей мобилке? ах да, в вы же из девяностых. В девяностые мобильных браузеров не было…
А чего не тридцать секунд?
Переделать табличную верстку под резину, чтобы не просто ресайз, но сохранялась эргономика, и структура подстраивалась под размер экрана?
А вы онкологию взглядом случайно не лечите?)
Ну деградируете вы степень сходства с виндой при маленьком экране. Не велика потеря.
Я делал нечто похожее, только не такое красивое, и не ретро.
Например таксбар внизу с «открытыми страницами» превращался в кнопку с выпадающим списком. Верстка не то чтобы существенно изменялась. В основном все в CSS жило.
А кроме мобильных пользователей никого больше нет?
Я например часто сворачиваю браузер в половину.
Там вполне бы нормально смотрелись ваши окна. Если бы они были сверстаны руками.
Нет, я понимаю что когда оно писалось я писал на примерно таком же уровне. Может даже хуже.
Это нормально.
Не нормально что вы там и застряли.
Может быть оверкилл, может быть "а почему бы и нет", может быть "надо же на чем-то учиться", но может быть и "технико-экономический анализ предоставленного "Бизнес-плана развития ресурса на ближайшие 10 лет" показал, что первую фазу "MVP" (далее "хелловорлд") можно создать и ввести в эксплуатацию за 1(один) час (без учёта времени прохождения платежей, обновления DNS-записей и прочих действий третьих лиц), но при реализации второй фазы "SUPERMEGASOFT" (далее "убийца") результаты работ по "хелловорлд" переиспользовать не представляется возможным. Рекомендуем начать работы по фазе "хелловорлд" на базе современных инструментов разработки проектов уровня фазы "убийца" (см. Приложение 1), что увеличит время реализация фазы "хелловорлд" на 1(один) час, но позволит переиспользовать его код на 100% и сократить расчётное время ввода в эксплуатацию фазы "убийца" на 1(один) час, то есть до 9999 (девять тысяч девятьсот девяносто девять) часов.
Никто не говорит, что в процедурном стиле с глобальными переменными нельзя сделать. Я много лет так сам делал во времена массового распространения PHP3. Но даже тогда как-то более поддерживаемыми получались приложения, которые по сути эмулировали ООП подход. Грубо, вместо объектов были ассоциативные массивы, которые функции с именами типа ClassName_MethodName получали в качестве первого параметра $this :)
Личные сайты в профиле — в этом стиле и сделаны (там и БД, и юзеры/профили, форм навалом, файлы и превьюшки, защита от XSS...)
А можете пару ссылок скинуть?)
Чисто по статистике?)
Ну вот я делаю сейчас одностраничник. Интерфейс для смартконтракта эфировского.
На ангуляре. Ну плюс немного преферанса и поэтесс, но по сути одностраничник.
Фреймворк тащить — смысла нет.
Взял старый проект. MVP лендинга. Ну не делаю я одностраничники.
По сути минимальный набор для одностраничника на котором был сделан ровно один сайт, но все универсальное лежало в отдельной папке, так что пиши не хочу.
Каркас? Каркас. Для множества? Спорно. Можно было, но не использовалось.
Сейчас быстренько освежил, чтобы глаза не мазолило (писалось два года назад).
С заделом на то, чтобы можно было потом опять использовать.
Но скорее всего та же участь постигнет, и умрет оно, только в виде учебных примеров разве что будет использоваться…
В общем не нравится мне такая классификация)
Т.е. с небесным телом ничего не поменяется, только контекст изменится. И тогда они станут другими объектами.
Считаю такую классификацию чистым легаси, и надеюсь ее таки пересмотрят (предпосылки есть). Ну и Плутон нам вернут, чего уж там (доминирует, не домнирует… нечеткое определение, зависимость от окружения..).
Не люблю определения которые зависят от контекста.
Ну или давайте возьмем другой мой проект, он не такой пограничный, там явно фреймворк. MVC, ORM (ActiveRecord), отдельно логика вьвов от шаблонов, СервисЛокатор, RBAC, авторизация, куча типовых модулей (почта, АктивФорм, кодогенерация… ну почти) и т.п.
На первых версиях было несколько десятков сайтов. По кодовой базе они были существенно разными, но по функционалу умеренно отличались.
Плюс еще биллинг одной компании я на нем делал.
Так что по вашему критерию явно выходит фреймворк.
Потом я очень существенно переделал АПИ, плюс название поменял,
дописал ему еще большую пачку модулей чисто CMS-ных, значительно переработал типовые шаблоны под большую модульность и гибкость.
В общем по факту вышел новый фреймворк «на базе» старого.
Ну и на нем было сделано полсотни сайтов.
Разных. Визитки, статейники, магазины, лендинги.
Но по коду они были все идентичны (я просто от тех кому нужны были сильные изменения в дизайне которые я не мог выжать в админке отказывался, ибо по цене часа работы я с вордпресоидами конкурировать не стану).
Все чисто данные (да, это были конфиги, но все редактировалось из админки, и хранилось в json а не в базе чисто ради скорости).
Так что реально можно сказать что это был один проект, просто много копий.
Так что по вашему критерию фреймворком он не являлся. И только когда я на нем написал очередной биллинг — спустя полсотни сайтов и полгода времени, он вдруг стал фреймворком. Вот только мне не совсем понятно — он стал фреймворком в день когда я начал писать биллинг? Или когда выкатил клиенту MVP? Или бету? Или в день релиза? В какой день он превратился в фреймворк?
Я бы сказал, что в любом нормально структурированном проекте есть фреймворк, а есть прикладная часть. Более менее четко можно говорить о том что «тут есть фреймворк» когда архитектор провел границу где ядро а где прикладное. Но по хорошему если архитектура кошерная, то это напрашивается само собой. Как минимум потому что модули разной степени «коровости» имеют разный уровень чувствительности к изменению внутреннего АПИ и совместимости, при развитии проекта.
Огромное количество проблем в работе, совместимости и эксплуатации уязвимостей на моей памяти были связаны со словом «автоматически». А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.
Вы гораздо больше наделаете ошибок, если будете загружать файлы руками.
А если не подгрузит «автоматически»? С инклудом хоть сразу видно будет.
Просто надо знать, как работает твой инструмент. И тоже все будет сразу видно.
Статья хорошая, но посыл отказаться от фреймворков для коммерческой разработки странен. Дома можно/нужно велосипедить как хочется, а в команде нужны договоренности и стандарты.
Тут кстати больше повезло приложениям, которые перешли на PSR пакеты из состояния легаси PHP-приложение с «include-oriented архитектурой». Вот они действительно не зависят от фреймворка.
Раньше использовал Symfony и радовался как ребенок, но когда потребовалось реализовать действительно нестандартный проект — это оказалось ужасом. Сейчас Symfony мне кажется медленным монстром, 90% кода которого непонятно для чего использовать. Конфиги-ради-конфигов.
Последнее время перешел на Silex: используется тот же самый функционал, но он гораздо меньше и соответственно проще и быстрее. Фреймворк используется только для самых базовых вещей, а все остальное реализуется библиотеками + своим кодом.
Вы немного опоздали с переходом на Silex: https://symfony.com/blog/the-end-of-silex
Для использования базовых вещей фреймворка на сегодняшний день можно успешно пользоваться Symfony MicroKernel и не тянуть за собой ненужные зависимости. При этом, у вас будет возможность легко и быстро подключить необходимый функционал буквально парой строк. И он будет соответствовать общепринятым стандартам/практикам, понятен всем и лёгок в дальнейшей поддержке. Symfony Flex подталкивает к этому подходу.
Раньше у symfony было что-то подобное в документации, объясняли все по полкам что и зачем. Как это сделать самому и как это сделано в symfony.
А вот в документации по yii вообще все грустно… Не рекомендовал бы для новичков, хотя и простой инструмент.
Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка
Это полумеры, когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP.
реальность: неймспейсы, компосер, сторонние компоненты других разработчиков
I am confused.
но на минуточку
О возможности стать лучше как разработчик
Возможно, главным плюсом отказа от фреймворка станет знание, как всё работает под капотом. Вы будете видеть, что происходит, не полагаясь на фреймворк, который заботится о вас настолько, что вы не можете что-то отладить или до конца понять.
интересный разбор «как все под капотом», заюзав готовые компоненты без анализа.
статьи из категории «Выпендрежь» и «Не как все».
У меня такого количества времени нет. Да и скилы норма.
В итоге получаем тот же продукт, который не хотим использовать.
А иногда даже крупнее популярных продуктов и вероятно менее надежно/оптимизированно.
Можно было бы пройти через тягомотину написания собственного автозагрузчика
А чего там писать? Если надо быстро грузить нужные классы, достаточно использовать три строчки.
set_include_path(get_include_path(). PATH_SEPARATOR.__DIR__.'/classes/'); # или даже set_include_path(__DIR__.'/classes/');
spl_autoload_extensions('.php');
spl_autoload_register();Тут, конечно, PSR-а никакого нет, зато минимум кода, работает автозагрузка из коробки, включая пространства имён, работает чрезвычайно быстро и не загружая лишний раз железо сервера. Маленькое неудобство есть — имена файлов должны быть названы в нижнем регистре (сами классы и пространства имён могут быть названы как угодно). Расширение файла или даже суффикс можно прописать во второй строке, например, '.class.php'.
Кстати, странно, что в PHP до сих пор не сделали штатную автозагрузку по всем правилам PSR.
Когда в следующий раз начнёте новый проект, постарайтесь обойтись без PHP-фреймворка
А потом задумайтесь сколько слёз прольёте и Вы, и ваши коллеги и может быть те, кому этот проект потом достанется. И как вы обоснуете своё решение об отказе от стандартизации разработки (в данном контексте использование популярного фреймворка) в пользу велосипеда? Ну вот представьте, пролетают 2 года, проект выстрелил, нанимаем на работу ещё 2 программистов. Это обычные парни (или девушки). Они тебя спросят, а почему собственно тут велосипед. Вы им реально скажите что-то типа «Ну я хотел прокачать скилл, поэтому». Я думаю никому тут не нужно объяснять, что разработка на фреймворке это априори быстрее чем разработка велосипеда и разработка на велосипеде. Своим решением начать новый проект не на фреймворке вы подставляете и себя и коллег. И ещё интересная мысль, а почему собственно работодатель должен оплачивать Ваши дополнительные часы разработки за свой счёт. Или Вы уже все сами решили и за коллег и за работодателя? По факту это деньги за дыру и за Ваш скил. В общем на мой скромный взгляд вся эта идея — проявление эгоизма. И очень надеюсь, что все
Делали так на одном проекте (rest api). Очень понравился результат. Код стал намного чище и гибче.
Судя по плюсам к данной статье, похапешники продолжают оставаться программистами низшего сорта. Ты можешь вытащить похапешника из говнокода, но говнокод из похапэшника не выведешь никогда.
Плюс количество новичков существенно выше ибо порог вхождения ниже.
Но если отбросить пласт «динозавров» которые плачут что в пхп7 убрали совместимость с синтаксисом пхп4, и им подобных, если убрать тех кто говорит «я чуть чуть знаю пхп… ну как знаю — могу правильно расставить пхп-теги в шаблоне вордпресса», то картина будет абсолютно одинаковая.
Ну ок, давайте для строгости введем определение — первые будут пхп4-программистами, даже если они и используют функционал пхп5, но идеологически застряли в старом апи, вторые будут пхп-верстальщики, а уже «полноценые» это будут пхп7-программисты.
Вот у пхп7-разработчиков (особенно если с включенным стрикт-режимом и покрытием тестами) все ок.
Но определённая доля рынка у него есть.
Плюс требует установки бинарных расширений PHP. А на тех же шаред-хостингах обычному клиенту его сложно установить (вернее добиться установки).
Обобщение по теме статьи: fornit.ru/50628
Современный PHP без фреймворков