>работать с проектами на смеси языков — и считать метрики по ним всем
то же самое для Php Inspections, только анализ других языков будут делать другие плагины, а запускаться inspection из одного места
>предоставлять метрики
>рапортовать технический долг (ой как врёт, зараза)
эти фичи очень странно и некорректно работают, к сожалению(
Не знаю как для других ЯП, но для php в связке c PHPStorm гораздо лучше подходит Php Inspections (EA Extended) plugins.jetbrains.com/plugin/7622?pr=phpStorm, тк и больше типов issue поддерживает, и меньше телодвижений при установке и настройке.
Использовал yii/yii2, ларавел, симфони, симфони2, зенд и фалкон (это не потому что я такой многостаночник, на фрилансе разное бывает). Почти каждый из них определю, если разработчики не переопределяли поведение ключевых компонентов и используют минимальный набор компонентов ядра фреймворков по которому можно определить.
ps навешивать ярлыки некомпетентости не разбираясь в вопросе это верх некомпетентности.
На самом деле многие фреймворки можно определить, если немного покопать. Например по ответам js-валидации, подключаемым js-либам, входящим в ядро фреймворка, способу именования ассетов/сборок ассетов, роуту к капче, самой капче и тд. Можно попробовать сгенерировать запрос таким образом, чтобы попасть на экшен обработчик ошибок и понять по нему.
Бесполезная статья (начиная от названия — ожидал увидеть список планируемых нововведений с их кратким обзором ) и только запутает новичков, автор либо брезгует документацией и чтением исходников, или просто ленится разобраться, и додумывает свои объяснения непонятным ему моментам. Я не хочу задеть или обидеть автора, но тем не менее.
Приведите, пожалуйста, пример проблем при конфигурировании модулей, хочется разобраться с этим вопросом.
Спасибо, получилось после плясок с бубном. В моем случае заработало если не конвертировать файл в XML, а перенести его на рабочий стол, отредактировать и перенести обратно в папку.
Было бы неплохо иметь автогенерацию и down от нее. А применение этой миграции уже на совести прогера. Можно сделать так, чтобы код внутри ф-ии был закомментирован, и если программист его раскомментировал, значит он понимает и согласен с тем что сгенерировалось. А выстрелить в ногу можно и вручную, допустив ошибку в запросе.
На самом деле текущей документации вполне достаточно на данный момент, для написания проекта практически любой сложности. Насколько помню даже ведется активный перевод на русский язык.
то же самое для Php Inspections, только анализ других языков будут делать другие плагины, а запускаться inspection из одного места
>предоставлять метрики
>рапортовать технический долг (ой как врёт, зараза)
эти фичи очень странно и некорректно работают, к сожалению(
в остальном согласен с вами.
ps навешивать ярлыки некомпетентости не разбираясь в вопросе это верх некомпетентности.
Приведите, пожалуйста, пример проблем при конфигурировании модулей, хочется разобраться с этим вопросом.
Особенно радует поддержка эластика и сфинкса из коробки.