Хотя я как бы fullstack (официально), на деле же — законченный backender, знающий фронтэнд лишь настолько, чтобы суметь обойтись без frontender'а, когда надо. Т.е. «по верхам» мы умеем, но чтобы оценить красоту и ценность (если таковые имеются) нового фреймворка этого недостаточно. А поскольку нас таких очень много (разумеется, сужу субъективно по собственному окружению), то мой первый вопрос — а какова кривая обучения в $mol? Например, Vue.js зашел на ура, спасибо его простоте и отличным докам. Angular (пока не было Vue) тоже ничего так, но время погружения дольше (особенно после его второй версии). React вообще создает впечатление зоопарка в зоопарке. А что с $mol в этом плане?
На всевозможных барахолках и частных продажах часто встречается аббревиатура ONO (or near offer). Мол, торг уместен, но в разумных пределах. Например, на дороге можно встретить машину, владелец которой собрался ее продавать и написал на заднем стекле — "$8000 ono".
Еще про «thx» — как минимум в Австралии и Зеландии любят говорить и писать «ta». Это тоже «thank you», но не аббревиатура. Когда впервые увидел такое в корпоративном мессенджере, долго не мог понять, что от меня хотят. )
Но статью все ж переименовали бы на «Паксос простыми словами». mwizard дело говорит — текущий заголовок реально режет слух, особенно если читающий знает правильный перевод словосочетания «something made simple» (примерно как «я есть Вася»).
Линус, [...] резко выражаясь, критикует решения, а не человека.
Было бы ок, если бы это было действительно так. Но Линус как раз очень часто переходит на личности:
There aren't enough swear-words in the English language, so now I'll have to call you perkeleen vittupää just to express my disgust and frustration with this crap.
У меня такая же беда. Добавил плагин на ноуте, подключил, включил синхронизацию — все ок. Затем на другой машине добавил плагин, включил. Получил вопрос «использовать настройки из аккаунта или взять локальные», что логично. Ответил «из аккаунта». С тех пор плагин в статусбаре стал показывать вечную синхронизацию. Через час не выдержал, решил перезапустить IDE — при запуске та же проблема, что у вас.
Вы уже отписались им в трекер, чтобы мне не дублировать?
Я вот на хабре статью написал и теперь имею возможность (и пользуюсь ею) поблагодарить в карму авторов интересных для меня статей. А на ГТ прочитаешь иной раз отличную статью, сходишь в профиль автора и… недостаточно кармы. А мне на ГТ писать банально не о чем. Единая между ресурсами карма была бы в тему.
За статью спасибо, плюсанул вас про запас (вдруг не зря с кармой попрощались), но с выводами не совсем согласен. Общая тенденция стагнации больших компаний в начале статьи описана хорошо. Но дальше пошли сплошные эмоции и притянутая за уши статистика. Ползущая вверх кривая говорит ровно об одном — открывают багов больше, чем закрывают. Причин тому может быть много. Вы поторопились объяснить это тем, что каждая новая версия содержит больше багов, чем предыдущая. А возможно в действительности IDE становится все популярнее => у нее появляется больше юзеров => больше людей, создающих баг-репорты.
Я конечно не утверждаю популярность как причину, я лишь демонстрирую, что причин может быть больше, чем одна. Можно было бы посмотреть на картину более объективно, если сделать и другие кривые, например:
— аналогичные кривые по их severity, чтобы посмотреть, много ли серьезных ошибок, и чтобы «косметика» не портила картину.
— статистику по кол-ву дней, прошедших между opened и closed, также разбитую по severity (чтобы посмотреть, действительно ли IDEA стала реагировать на серьезные ошибки дольше).
Огромное спасибо за статью — плюсую и преклоняюсь перед вашей несгибаемостью. Сам в похожей ситуации, но уже опустил руки. У нас большой enterprise-проект на ASP.MVC (C#). Уровень легаси зашкаливает:
SVN (на Git не переходим, т.к. генеральному нужно редактировать в репозитории некоторые input-файлы, а он не программист, кривая его обучения гиту — большая; на распил репозитория на «код» и «input»-файлы пока не соглашаются).
Deploy ручной на AWS Windows-сервера через RDP.
Низкая компетенция разработчиков — все пришли из мира desktop-разработки, никто не в курсе как работает HTTP в принципе, JavaScript пишется с трудом и в виде ужасных «спагетти».
Бизнес логика в огромных контроллерах (есть экшены по 500 строк и больше).
Генерация HTML местами жестко зашита в бизнес-логике.
Само приложение реализовано stateful (например, entity, выбранный на предыдущей странице, сохраняется в сессии и на следующей странице выбирается оттуда, вместо передачи его ID через URL).
ну и много чего еще...
Есть конечно и плюсы, и даже телодвижения в сторону улучшения и борьбы с legacy, но говнокод растет быстрее, т.к. (лучше и не скажешь):
вы можете кинутся грудью на амбразуру рефакторинга… И погибнуть, поскольку остальная команда будет успевать «говнокодить»
Ни в коем случае не нападаю, просто интересуюсь, а тратить время на эксперименты с вашей библиотекой не хочется. Если есть — отлично. Если нет — имейте в виду. ;)
Сегодня ночью вышел EAP (билд 162.1447.5). В списке фиксов нашел и этот баг (точнее, тот тикет, на который его задупали). Скачал, развернул, проверил — работает. Оперативно, спасибо большое! :)
Самое интересное, что у меня на вашем коде — тоже. Попробовал написать чуть более развернутый пример (с «composer» и нормальным autoload'ом) — тоже все ок.
Снова открыл свой рабочий проект — ошибки есть. Удалил папку ".idea" из корня проекта, переоткрыл проект, проинспектировал — ошибки есть, но их теперь другое число. Попробовав несколько раз получал различные значения от 7 до 13. Такое ощущение, что нужно достаточно большое количество таких импортов в разных файлах, чтобы оно стало воспроизводиться (причем ругается только на некоторые из этих импортов, а не на все подобные).
Поскольку проект opensource, почему бы не воспроизвести прямо на нем:
Поскольку нет папки «vendors», будет очень много «undefined». А если в настройках проекта язык не PHP7, то еще и много errors. Игнорируем, смотрим «unused imports» — они там есть.
6. Закрываем проект.
7. Удаляем папку ".idea".
8. Повторяем шаги 3-5 — снова есть «unused imports», но скорее всего уже другое число.
Иногда, когда в одном файле используется относительно много классов из одного и того же namespace, я делаю «use» только для родительского namespace. Т.е. вместо (пример условный!):
use Foo\Bar\Class1;
use Foo\Bar\Class2;
...
use Foo\Bar\Class10;
$var1 = new Class1();
$var2 = new Class2();
...
$var10 = new Class10();
пишем:
use Foo\Bar;
$var1 = new Bar\Class1();
$var2 = new Bar\Class2();
...
$var10 = new Bar\Class10();
Вчера обновился с 2016.1.2 на 2016.2, прогнал инспекции — PhpStorm ругается на подобные сокращенные «use», как на «unused import». Предыдущая версия (2016.1.2) не ругалась (хотя действительно неиспользуемые импорты находила). Это бага? Бежать в трэкер? Временно отключил соответствующую инспекцию (php-cs-fixer все равно лечит действительно неиспользуемые импорты), но неприятно. :)
Потому что команды и события — разные вещи. Даже если одно можно имитировать через другое, это не означает что так и стОит делать. Подключение внешней компоненты — столь малый «оверхэд», что лично я не вижу смысла акушерствовать через гланды в имитации команд через события.
А вот вопрос «зачем использовать event_bus из третьей компоненты, если в Symfony уже есть EventDispatcher» был бы вполне легитимен. И я бы не стал настаивать — вполне можно использовать команды из SimpleBus, а события — из стандартного EventDispatcher'а. Руки никто не выкручивает.
Да, я бы так и делал. Можно просто кидать ивент, мол, вот файл для парсинга; обработчик ивента во время обработки может накидать аналогичных ивентов — своеобразная рекурсия. А инициатором всего этого может быть команда, которая сама по себе вообще ничего не парсит, а лишь кидает первый ивент для парсинга первого файла.
Полностью согласен с dmrt, что объем ради объема — глупо. Например, не так давно брал (бумажную) книгу «JavaScript: The Good Parts» Дугласа Крокфорда — там всего 153 страницы, из которых остается 115 если выкинуть индекс. Книга шикарна, от маленького объема не проигрывает. Да, она стоит дешевле, чем 500-страничные фолианты. По-моему, все логично. А «книгу потоньше не купят дороже» и «нальем в книгу воды, чтобы было» — нет. При этом я понимаю, что такое контракт с издательством (цель которого — заработать) и как он связывает руки. Я просто не считаю это оправданием.
Плюсанул!!!
Остался нераскрытым один вопрос - где можно скачать результат, тоже давно хотел пересмотреть :)
Еще про «thx» — как минимум в Австралии и Зеландии любят говорить и писать «ta». Это тоже «thank you», но не аббревиатура. Когда впервые увидел такое в корпоративном мессенджере, долго не мог понять, что от меня хотят. )
Было бы ок, если бы это было действительно так. Но Линус как раз очень часто переходит на личности:
Вы уже отписались им в трекер, чтобы мне не дублировать?
Я конечно не утверждаю популярность как причину, я лишь демонстрирую, что причин может быть больше, чем одна. Можно было бы посмотреть на картину более объективно, если сделать и другие кривые, например:
— аналогичные кривые по их severity, чтобы посмотреть, много ли серьезных ошибок, и чтобы «косметика» не портила картину.
— статистику по кол-ву дней, прошедших между opened и closed, также разбитую по severity (чтобы посмотреть, действительно ли IDEA стала реагировать на серьезные ошибки дольше).
Но в целом вброс интересный, спасибо. )
Есть конечно и плюсы, и даже телодвижения в сторону улучшения и борьбы с legacy, но говнокод растет быстрее, т.к. (лучше и не скажешь):
Вопрос: Kontrolio так умеет? В частности:
Ни в коем случае не нападаю, просто интересуюсь, а тратить время на эксперименты с вашей библиотекой не хочется. Если есть — отлично. Если нет — имейте в виду. ;)
Снова открыл свой рабочий проект — ошибки есть. Удалил папку ".idea" из корня проекта, переоткрыл проект, проинспектировал — ошибки есть, но их теперь другое число. Попробовав несколько раз получал различные значения от 7 до 13. Такое ощущение, что нужно достаточно большое количество таких импортов в разных файлах, чтобы оно стало воспроизводиться (причем ругается только на некоторые из этих импортов, а не на все подобные).
Поскольку проект opensource, почему бы не воспроизвести прямо на нем:
1. Качаем исходники архивом — https://github.com/etraxis/etraxis/archive/ce16e0d5fe08fa79b5153f6db2f5e4e6abef1f3c.zip.
2. Распаковываем архив.
3. Открываем проект в PhpStorm.
4. Соглашаемся на autodetect PSR-0 namespaces.
5. Инспектируем папку «src».
Поскольку нет папки «vendors», будет очень много «undefined». А если в настройках проекта язык не PHP7, то еще и много errors. Игнорируем, смотрим «unused imports» — они там есть.
6. Закрываем проект.
7. Удаляем папку ".idea".
8. Повторяем шаги 3-5 — снова есть «unused imports», но скорее всего уже другое число.
пишем:
Вчера обновился с 2016.1.2 на 2016.2, прогнал инспекции — PhpStorm ругается на подобные сокращенные «use», как на «unused import». Предыдущая версия (2016.1.2) не ругалась (хотя действительно неиспользуемые импорты находила). Это бага? Бежать в трэкер? Временно отключил соответствующую инспекцию (php-cs-fixer все равно лечит действительно неиспользуемые импорты), но неприятно. :)
акушерствовать через гландыв имитации команд через события.А вот вопрос «зачем использовать event_bus из третьей компоненты, если в Symfony уже есть EventDispatcher» был бы вполне легитимен. И я бы не стал настаивать — вполне можно использовать команды из SimpleBus, а события — из стандартного EventDispatcher'а. Руки никто не выкручивает.