Открою для вас тайну — все DSL-и так или иначе интерпритируются. И да, кукубрер это не совсем java. Да, есть кукумбер для JVM но реализация геркина есть под все языки. Просто где-то (c# — > SpecFlow например) оно называется не огурцами.
Так что нет. соль не в этом. Вся мощь геркина в specification by example. А то что рекомпилить не надо — ну реализация стэпов меняется чаще чем сценарии. А e2e тесты можно и не на java писать для удобства.
просто напомню. Это допущение нужно по одной простой причине — нет никакой возможности убать ложно-положительное срабатывание вот тут:
if (!is_file($filePath)) {
return;
}
// 99.99% ситуаций тут будет строка,
// но psalm об этом никак не узнает и будет думать что string | false
$fileContent = file_get_content($filePath);
То есть увы — все это поиски компромисов в условиях языка, конструкции которого плохо дружат с выводом типов. С чем я несогласен — так это с невозможностью переопределить тайпинги легко и просто. Но думаю это как раз пофиксят в ближайшем будущем.
Хочешь красивый вывод типов с минимальным количеством ложных срабатываний — добро пожаловать в дивный новый мир отказа от любых if-ов, while-ов и прочих вещей (ну то есть привет ФП с их Maybe и Either, map fold и т.д.)
увы это единственный способ внедрять подобные вещи в пых в силу того что мы не можем просто включить строгость в настройках и надеяться что все наши вендроные либы хорошо написаны.
Очень часто можно встретить это противопоставление — типа 100% покрытие кода vs статический анализ. Это противопоставление в корне не верно.
Во первых 100% покрытие кода тестов ничего нам не гарантирует. Точно так же как и 100% покрытие кода типами (есть суровый внешний мир, и он может нести много сюрпризов и несоответствий с типами о которых мы узнаем только в рантайме, да и пых уж простите не хаскель и не окамл).
Незаслуженно никем не упомянут стат. анализатор в зенд студио.
если я правильно помню — он там совсем простенький, без вывода типов и в целом примитивный был. Даже по сравнению с тем что дает phpstorm.
Да и потом, просто раз уж вы ухватились за слова "Zend" — Phan например — творение Расмуса.
но когда стат. анализатор и бьютифайер непосредственно интегрированы в среду разработки
У такой стратегии развития есть несколько очевидных минусов:
сложно расширять
у каждой IDE должен быть свой анализатор.
Сегодня в целом есть тренд чуть другой, более рациональной стратегии — интеграция статического анализатора прямо в компилятор языка (language server). Профит — вам не надо ждать обновлений IDE что бы у вас появились все новые плюшки после обновления компилятора.
Да и потом, интеграция в PhpStorm того же psalm — дело не хитрое, можете даже плагин написать. Просто оно как бы не особо надо. А претифайеры и прочее — это вообще делается на раз два — добавляете ватчеры на файлы и вжух.
И повторюсь — основной плюс независимых инструментов — расширяемость.
строгая и статическая типизация — разные вещи. Строгая — запрет на неявные касты типов в рантайме. Увы и ах поменять поведение операторов даже с волшебными declare уже не выйдет. Слишком много кода сломается. Тут надежда как раз на анализаторы типа psalm и других, которые подобные касты могут отловить в компайл тайме и наругать человека.
статическая типизация имеет смысл только при наличии возможности описывать все типы (с чем в php все плохо даже на уровне анализаторов, опять же потому что нет никаких стандартов и все выдумывают свои) + возможность вывода типов (мы же ленивые, да?) + проверка этих типов самим PHP на этапе компиляции/трансляции в опкоды.
PHP давным давно принял довольно странное решение — проверять типы в рантайме. Что это означает? Да все просто — вся информация о типах обязана быть в рантайме. А это дополнительные накладные расходы, начиная с увеличения количества занимаемой памяти (что невилирует все старания для php7 в этом плане), заканчивая накладными расходами на рантайм (на вход передается массив чисел, но нам надо в этом убедиться. Либо нужно мутить какие-то хидден классы для типов либо O(n)). Именно по этой причине до сих пор нет ни дженериков ни uniton/intersection types ни чего-быто нибыло еще что хоть немного упростило бы жизнь разработчикам инструментов типа того же psalm.
это я к тому что в целом фича с тайпхинтами для пропертей вообще ничего не добавляет с точки зрения возможности описания типов. От слова совсем. Без дженериков, без алгебры типов (хотя бы простые штуки типа type Foo = "foo" | "bar", без array shapes и прочего — ни о какой "полной типизации" даже речи быть не может.
А с учетом того что пых любые проверки типов обязан еще и в рантайме делать (потому что так повелось и делать иначе будет уже не консистентно), сложность всего этого вырастает на несколько порядков.
Геркин сценарии используются для описания приемочных тестов, а не «я кликаю на кнопку». То есть если проще — геркин сценарии не должны быть привязаны к UI. UI — это самая изменчивая штука в приложении, тогда как геркин сценарии пишутся часто (ну или должны писаться) задолго до того как у вас мокапы какие-то появятся. Геркин это вообще отличный инструмент для уточнения требований.
Типичная история — люди видят геркин и думают «о, я смогу заставить своих QA писать тесты! круто!» Хотя попросите вы их писать тесты хоть на PHP с готовыми стэпами — разницы особо не будет. Зато сами по себе сценарии будут значительно более стабильны, проще контролировать что происходит, больше свободы в плане оптимизации стэпов, ну и все плюшки от того что вы пишите более специализированные вещи а не пытаетесь втиснуть все в рамки геркина.
Так что могу сказать что и так выдумывать ничего не надо. Геркин не должен с page object хоть как-то рядом работать. А вот реализации стэпов — могут, но это ничем не отличается от просто использования page object-ов которые уже покрывает дока.
Как вы одновременно обновляете бекенд и iOS приложение
зачем одновеменно? нужно же независимо
то профессионалом будет тот, кто углубился в своей области
Мне не нравится что вы смешиваете понятие "обучаемость", "узкой специализации" и "профессионализм". Я понимаю что имелось ввиду, но категорически не согласен с формулировкой.
Да, конечно если мы говорим о людях с одинаковым уровнем обучаемости и мотивации, то значит объем знаний у людей одинаковый. И у отдельно фронтэнд и отдельно бэкэнд разработчика по идее было бы шире покрыта та часть работы с которой он работает.
Только не стоит забывать что большая часть знаний и опыта из одной сферы прекрасно ложится на другую. Что делает все чуть сложнее.
Не в этом идея, а в полном отделении провайдеров данных от UI компонентов. Уж извините, но все эти виджеты из yii морально устарели, плохо скейлятся и я не вижу никакого смысла их использовать в 2018-ом году. Почти все эти компоненты доступны независимо под любой UI фреймворк.
Что до отдельных репозиториев — у меня вот монореп, где лежат рядом и бэк, и фронт, и андроид и ios. И нет никаких проблем, и удобно, и все такое. И фулстэк не фулстэк — проблема yii в том что php файлики влияют на отображение js компонентов и вообще отвечают за рэндринг. Фу.
> Даже в научных журналах раз в 5 лет печатают ошибочную статью.
1. важен не факт отсутствия ошибочной информации а частота встречаемости. Все же 1 статья в 5 лет и 4 ложных/вырванных из контекста утверждений меняющих смысл из 5-ти это разная статистика.
2. важна так же реакция на выявление подобной ошибочной информации.
Если что, это были ребята из Xerox Parc, и речь шла о графическом интерфейсе. Изначально оно вообще должно было называться Model-View-Editor-Controller но уж больно любил Тругве (я наверное сейчас снова изуродовал имя) аббривиатуры в 3 буквы. Занятно что в списке литературы есть отсылки на все это, но создается впечатление что автор их не очень то читала.
Вообще наискосок прочитал — польза от данного доклада только в ключевых словах для гугла. Не более.
Да, и не стоит этот термин переводить (либо переводить как сцепленность а не зацепление, это семантически ближе).
Причем у кого-то кохижен это зацепление (из того что помню сходу — лекции Немчинского) а у кого-то (википедия например) кохижен это связанность, а зацепление это coupling. Короч каша полная.
Что грустно ибо это одни их самых важных концептов в контексте разделения системы на модули.
интегрированы так плохо, что жрут в сумме куда больше чем ide
А вы как давно пробовали? Сегодня есть классная штука — language server, и по моим ощущением (опять же, если сам language server реализован нормально, что пока не всегда правда но это дело наживное) какой-нибудь neovim + language server для какого-нибудь typescript работает получше нежели всякие там webstorm.
Я лично жизнь не представляю без IDE, особенно для языков типа Java или, в моем случае, PHP. Но помимо "редакторы с плагинами жрут больше чем IDE с плагинами" я бы скорее сказал что проблема в другом — я просто привык к продуктам jetbrains за 5 лет. И как-то тот же vscode мне пока дается с трудом. А перелесть на neovim я так и не смог (хотя пытался). И дело не в том что мне не хватает каких-то фич (каких-то не хватает, но не могу сказать что они координально влияли на мою продуктивность) а скорее в том что речь о выходе из зоны комфорта.
Но в целом тренды (тот же language server) мне нравится. Помню лет 5 назад когда поднималась популярность такого языка как D многие не хотели его пробовать банально в связи с отсутствием поддержки оного в какой-либо из IDE. Гиганты вроде Jetbrains инвестировать в подобное будут только, если на это есть существенный спрос, которого нет потому что нет инструментов. Да и опять же, штуки типа рефакторинг браузер под каждый редактор имплементить как-то странно. А так — запилили бы ребята из команды разработчиков D сразу language server поставляемый вместе с компилятором, и вжух — у всех все есть, все новые фичи всегда доступны вместе с обновлением компилятора, и язык продвигать можно и много чего еще.
Или, скажем, PHP. Не секрет что PHP как язык убожество. И что бы это минимально исправить существуют проекты типа yay и preprocess.io. Вот только ждать суппорта IDE для таких вещей глупо, что тормозит развитие таких идей. А был бы language server — да в том же шторме люди могли бы пользоваться на равне с людьми которые привыкли к vi.
Есть, значится, у нас апишка для обновления каких-то данных. На вход принимает json, на выход — 204 если все хорошо (когда все плохо пока не рассматриваем). После того, как мы успешно что-то обновили, нам надо отправить всем подписавшимся по вэбсокетам обновление (много пользователей мониторят одни и те же данные, потому только так).
Как подобное вписывается в вашу «архитектуру»? Что будет где? И главный вопрос — вэбсокеты — как это все вписывается в ваши эти MVCS?
начните с простого — дайте определение "сервисному слою".
Например у меня контроллеры — это тоже сервисы, что усложняет трактовку этого термина (я нахожу его бесполезным ровно настолько же, насколько бесполезно говорить о MVC в модели request/response).
Если подразумевать некие прикладные сервисы (application layer) в которых реализация юзкейсов, то опять же они не всегда нужны (особенно если вам нравятся event driven подходы, не путать с хуками аля вордпресса).
Словом, попробуйте для себя хотя бы сформулировать определение недвусмысленное.
хз что обсуждалось… То что вы привели никакого отношения не имеет к тому о чем говорит Fantyk. Ощущение что вы просто закидываете людей ссылками не понимая о чем речь.
Идея в том что для с точки зрения изучения вещей важно получить первый работающий результат как можно скорее. Потому почти всегда в документации упрощенные примеры. Документация фреймворка не то место где людей надо декомпозиции и разделению ответственности учить.
Еще есть нюанс — если мы говорим о каком-то дальнейшем разделении — уже есть масса вариантов (помимо ваших "сценариев", которые у кого-то называются интеракторами (дядя Боб) а у кого-то обработчиками команд (и CQRS тут не причем еще).
Вариантов разделения отвесвенности внутри приложения очень много. И что самое главное — фреймворк редко на это все влияет. Вы привыкли делать интеракторы (под стиль clean architecture) — делайте, фреймворк вас не должен в этом ограничивать. Вы привыкли больше к event driven подходам и eventual consistency — да не вопрос. Вам нужно бложик запилить — тут можно и в контроллере все сгрузить. А еще есть мидлвары, и если мы наши контроллеры от http абстрагируем необходимости в отдельном сервисном слое тоже может не быть.
Потому еще раз — документация к фреймворку не должна нести в себе информации о том как делать что-то что к этому фреймворку не привязано.
Все так, Михаил этого даже не отрицает)
Открою для вас тайну — все DSL-и так или иначе интерпритируются. И да, кукубрер это не совсем java. Да, есть кукумбер для JVM но реализация геркина есть под все языки. Просто где-то (c# — > SpecFlow например) оно называется не огурцами.
Так что нет. соль не в этом. Вся мощь геркина в specification by example. А то что рекомпилить не надо — ну реализация стэпов меняется чаще чем сценарии. А e2e тесты можно и не на java писать для удобства.
просто напомню. Это допущение нужно по одной простой причине — нет никакой возможности убать ложно-положительное срабатывание вот тут:
То есть увы — все это поиски компромисов в условиях языка, конструкции которого плохо дружат с выводом типов. С чем я несогласен — так это с невозможностью переопределить тайпинги легко и просто. Но думаю это как раз пофиксят в ближайшем будущем.
Хочешь красивый вывод типов с минимальным количеством ложных срабатываний — добро пожаловать в дивный новый мир отказа от любых
if-ов, while-ов и прочих вещей (ну то есть привет ФП с их Maybe и Either, map fold и т.д.)увы это единственный способ внедрять подобные вещи в пых в силу того что мы не можем просто включить строгость в настройках и надеяться что все наши вендроные либы хорошо написаны.
Очень часто можно встретить это противопоставление — типа 100% покрытие кода vs статический анализ. Это противопоставление в корне не верно.
Во первых 100% покрытие кода тестов ничего нам не гарантирует. Точно так же как и 100% покрытие кода типами (есть суровый внешний мир, и он может нести много сюрпризов и несоответствий с типами о которых мы узнаем только в рантайме, да и пых уж простите не хаскель и не окамл).
На эту тему вообще есть замечательный докладик: Ideology — Gary Bernhardt from Strange Loop 2015
если я правильно помню — он там совсем простенький, без вывода типов и в целом примитивный был. Даже по сравнению с тем что дает phpstorm.
Да и потом, просто раз уж вы ухватились за слова "Zend" — Phan например — творение Расмуса.
У такой стратегии развития есть несколько очевидных минусов:
Сегодня в целом есть тренд чуть другой, более рациональной стратегии — интеграция статического анализатора прямо в компилятор языка (language server). Профит — вам не надо ждать обновлений IDE что бы у вас появились все новые плюшки после обновления компилятора.
Да и потом, интеграция в PhpStorm того же psalm — дело не хитрое, можете даже плагин написать. Просто оно как бы не особо надо. А претифайеры и прочее — это вообще делается на раз два — добавляете ватчеры на файлы и вжух.
И повторюсь — основной плюс независимых инструментов — расширяемость.
declareуже не выйдет. Слишком много кода сломается. Тут надежда как раз на анализаторы типа psalm и других, которые подобные касты могут отловить в компайл тайме и наругать человека.это я к тому что в целом фича с тайпхинтами для пропертей вообще ничего не добавляет с точки зрения возможности описания типов. От слова совсем. Без дженериков, без алгебры типов (хотя бы простые штуки типа
type Foo = "foo" | "bar", без array shapes и прочего — ни о какой "полной типизации" даже речи быть не может.А с учетом того что пых любые проверки типов обязан еще и в рантайме делать (потому что так повелось и делать иначе будет уже не консистентно), сложность всего этого вырастает на несколько порядков.
Типичная история — люди видят геркин и думают «о, я смогу заставить своих QA писать тесты! круто!» Хотя попросите вы их писать тесты хоть на PHP с готовыми стэпами — разницы особо не будет. Зато сами по себе сценарии будут значительно более стабильны, проще контролировать что происходит, больше свободы в плане оптимизации стэпов, ну и все плюшки от того что вы пишите более специализированные вещи а не пытаетесь втиснуть все в рамки геркина.
Так что могу сказать что и так выдумывать ничего не надо. Геркин не должен с page object хоть как-то рядом работать. А вот реализации стэпов — могут, но это ничем не отличается от просто использования page object-ов которые уже покрывает дока.
зачем одновеменно? нужно же независимо
Мне не нравится что вы смешиваете понятие "обучаемость", "узкой специализации" и "профессионализм". Я понимаю что имелось ввиду, но категорически не согласен с формулировкой.
Да, конечно если мы говорим о людях с одинаковым уровнем обучаемости и мотивации, то значит объем знаний у людей одинаковый. И у отдельно фронтэнд и отдельно бэкэнд разработчика по идее было бы шире покрыта та часть работы с которой он работает.
Только не стоит забывать что большая часть знаний и опыта из одной сферы прекрасно ложится на другую. Что делает все чуть сложнее.
Монорепы это хорошо.
А вот сейчас обидно было.
Не в этом идея, а в полном отделении провайдеров данных от UI компонентов. Уж извините, но все эти виджеты из yii морально устарели, плохо скейлятся и я не вижу никакого смысла их использовать в 2018-ом году. Почти все эти компоненты доступны независимо под любой UI фреймворк.
Что до отдельных репозиториев — у меня вот монореп, где лежат рядом и бэк, и фронт, и андроид и ios. И нет никаких проблем, и удобно, и все такое. И фулстэк не фулстэк — проблема yii в том что php файлики влияют на отображение js компонентов и вообще отвечают за рэндринг. Фу.
религиозных.
На самом деле конкуренция никому не повредит, но вот делать тоже самое что было и раньше — плохая инвестиция как по мне.
1. важен не факт отсутствия ошибочной информации а частота встречаемости. Все же 1 статья в 5 лет и 4 ложных/вырванных из контекста утверждений меняющих смысл из 5-ти это разная статистика.
2. важна так же реакция на выявление подобной ошибочной информации.
Меня больше возмущает следующее:
Если что, это были ребята из Xerox Parc, и речь шла о графическом интерфейсе. Изначально оно вообще должно было называться Model-View-Editor-Controller но уж больно любил Тругве (я наверное сейчас снова изуродовал имя) аббривиатуры в 3 буквы. Занятно что в списке литературы есть отсылки на все это, но создается впечатление что автор их не очень то читала.
Вообще наискосок прочитал — польза от данного доклада только в ключевых словах для гугла. Не более.
Причем у кого-то кохижен это зацепление (из того что помню сходу — лекции Немчинского) а у кого-то (википедия например) кохижен это связанность, а зацепление это coupling. Короч каша полная.
Что грустно ибо это одни их самых важных концептов в контексте разделения системы на модули.
А вы как давно пробовали? Сегодня есть классная штука — language server, и по моим ощущением (опять же, если сам language server реализован нормально, что пока не всегда правда но это дело наживное) какой-нибудь neovim + language server для какого-нибудь typescript работает получше нежели всякие там webstorm.
Я лично жизнь не представляю без IDE, особенно для языков типа Java или, в моем случае, PHP. Но помимо "редакторы с плагинами жрут больше чем IDE с плагинами" я бы скорее сказал что проблема в другом — я просто привык к продуктам jetbrains за 5 лет. И как-то тот же vscode мне пока дается с трудом. А перелесть на neovim я так и не смог (хотя пытался). И дело не в том что мне не хватает каких-то фич (каких-то не хватает, но не могу сказать что они координально влияли на мою продуктивность) а скорее в том что речь о выходе из зоны комфорта.
Но в целом тренды (тот же language server) мне нравится. Помню лет 5 назад когда поднималась популярность такого языка как D многие не хотели его пробовать банально в связи с отсутствием поддержки оного в какой-либо из IDE. Гиганты вроде Jetbrains инвестировать в подобное будут только, если на это есть существенный спрос, которого нет потому что нет инструментов. Да и опять же, штуки типа рефакторинг браузер под каждый редактор имплементить как-то странно. А так — запилили бы ребята из команды разработчиков D сразу language server поставляемый вместе с компилятором, и вжух — у всех все есть, все новые фичи всегда доступны вместе с обновлением компилятора, и язык продвигать можно и много чего еще.
Или, скажем, PHP. Не секрет что PHP как язык убожество. И что бы это минимально исправить существуют проекты типа yay и preprocess.io. Вот только ждать суппорта IDE для таких вещей глупо, что тормозит развитие таких идей. А был бы language server — да в том же шторме люди могли бы пользоваться на равне с людьми которые привыкли к vi.
Есть, значится, у нас апишка для обновления каких-то данных. На вход принимает json, на выход — 204 если все хорошо (когда все плохо пока не рассматриваем). После того, как мы успешно что-то обновили, нам надо отправить всем подписавшимся по вэбсокетам обновление (много пользователей мониторят одни и те же данные, потому только так).
Как подобное вписывается в вашу «архитектуру»? Что будет где? И главный вопрос — вэбсокеты — как это все вписывается в ваши эти MVCS?
начните с простого — дайте определение "сервисному слою".
Например у меня контроллеры — это тоже сервисы, что усложняет трактовку этого термина (я нахожу его бесполезным ровно настолько же, насколько бесполезно говорить о MVC в модели request/response).
Если подразумевать некие прикладные сервисы (application layer) в которых реализация юзкейсов, то опять же они не всегда нужны (особенно если вам нравятся event driven подходы, не путать с хуками аля вордпресса).
Словом, попробуйте для себя хотя бы сформулировать определение недвусмысленное.
хз что обсуждалось… То что вы привели никакого отношения не имеет к тому о чем говорит Fantyk. Ощущение что вы просто закидываете людей ссылками не понимая о чем речь.
Идея в том что для с точки зрения изучения вещей важно получить первый работающий результат как можно скорее. Потому почти всегда в документации упрощенные примеры. Документация фреймворка не то место где людей надо декомпозиции и разделению ответственности учить.
Еще есть нюанс — если мы говорим о каком-то дальнейшем разделении — уже есть масса вариантов (помимо ваших "сценариев", которые у кого-то называются интеракторами (дядя Боб) а у кого-то обработчиками команд (и CQRS тут не причем еще).
Вариантов разделения отвесвенности внутри приложения очень много. И что самое главное — фреймворк редко на это все влияет. Вы привыкли делать интеракторы (под стиль clean architecture) — делайте, фреймворк вас не должен в этом ограничивать. Вы привыкли больше к event driven подходам и eventual consistency — да не вопрос. Вам нужно бложик запилить — тут можно и в контроллере все сгрузить. А еще есть мидлвары, и если мы наши контроллеры от http абстрагируем необходимости в отдельном сервисном слое тоже может не быть.
Потому еще раз — документация к фреймворку не должна нести в себе информации о том как делать что-то что к этому фреймворку не привязано.