Возможно ли отложить инициализацию приложения?

vasIvas: у меня события по сути генерит только ui layer, обработчики событий дергают методы контроллеров, те дергают модель, модель возвращает результат, ui layer реагирует на изменение данных и подстраивается. Идеальный цикл, все как в MVC. Никаких проблем и расхождений с вашей теорией всего или игроделаньем.

Возможно ли отложить инициализацию приложения?

vasIvas: события это хорошо, но далеко не всегда. Там где можно явно вызвать метод а не кидать событие и надеяться что его кто-то обработает - лучше вызвать метод.

Возможно ли отложить инициализацию приложения?

vasIvas: танки на флеше? Вы видимо с ума сошли. Да и все самое сложное там было и остается на сервере. А клиент это так, фигня. Тут больше работы дизайнера чем программиста (движки то не писали свои)

Просто поймите что мир разнообразен и есть масса разных подходов. Ни в JS ни в Python нет таких вещей как классы, как глобальная единица доступная везде и всюду, там все объекты, и люди спокойно себе живут. Просто все чуть чуть по другому.

Если вам хочется взглянуть как лучше жить с JS рекомендую почитать как с этим сражаются питонщики. Они это делают намного дольше и у них все подходы отработаны уже годами.

Возможно ли отложить инициализацию приложения?

vasIvas: и хватит пытаться меня убедить в том что JS плохой язык и все такое. Альтернативы нет, даже тот же TypeScript не дает мне того что я хочу, А перестать писать на JS только из-за какихто мелочей в реализации языка свидетельство ограниченности мышления. Я работаю не для того что бы кодить в свое удовольствие, а что бы решать задачи. JS (и все его сапсеты) сейчас единственный вариант писать WEB приложения, и в принципе недостатка в том как управлять кодом там нет.

Словом... осталю вам цитату одного англичанина: a foolish consistency is the hobgoblin of little minds

Возможно ли отложить инициализацию приложения?

vasIvas: я не согласен с утверждением что игры в сотни раз сложнее чем сайты, так как регулярно вижу ваши вопросы. Как же вы игры тогда писали...

По поводу иньекции зависимостей - это иньекции зависимостей. для JS лучше сервис локатор какой-нибудь, чем по сути $inject и является.

По поводу связей и тд. - каждый файл импортирует то, от чего он зависит, и не больше. Построить на основе этого граф может более-менее вменяемая IDE или отдельные инструменты для статического анализа. Посмотрите на python сообщество, они живут так уже десятилетия, и у них все хорошо, и инструменты они пишут посложнее ваших там игр. Как минимум у world of tanks игровой сервер написан как раз таки на python. И подходы там примерно такие же как в модульном js, разве что просто развито это сильнее.

Возможно ли отложить инициализацию приложения?

vasIvas: модуль меню должен явно зависить от модуля маршрутизации. Не надо придумывать извращений и ивентами и т.д. Темболее что $injector для всего приложения один и тот же, так что в любом случае эти сервисы будут вам доступны.

Что такое "артефакт" в рамках Сontinuous Delivery PHP приложений?

kalya: есть такая штука как continuous integration сервер, который выполняет сборку. Структура та же что и у вас локально, тут как хотите. Просто скопируйте директорию вашего проекта в другое место и она будет работать.

Для деплоймента можно использовать штуки вроде capifony.

Как правильно спроектировать REST приложение на Ruby on Rails + Angular JS?

Mikhail Osher: Ну начнем с того что реализаций сериализаторов и мэпперов уже достаточно так что возьни в принципе мало. Ну и закончим тем что я не использую часть про гипермедиа, просто использую рекомендации по формированию URL и т.д. Гипермедиа часто использую только для пагинации и прочего. У меня только два проекта где была использована jsonapi причем это была одна из последних версий драфта, а не 1.0. Все руки никак не доходят.

Какой язык выбрать для автоматизации тестирования?

если речь идет о E2E тестах то их пофиг на чем писать. А вот юнит тесты должен писать исключительно программист который написал код.

Какой язык выбрать для автоматизации тестирования?

Вот не надо, лучше взять python, это намного более простой и выразительный язык.

Возможно ли отложить инициализацию приложения?

vasIvas: ну.... смотря что вы хотите сделать в конфигурации... я только не понимаю зачем вам это.

Что такое "артефакт" в рамках Сontinuous Delivery PHP приложений?

kalya: вы поймите, ключевое тут "артефакт это любой результат сборки". Зачем вы делаете сборку решать вам. У меня это прогон тестов, сборка билда и его деплоймент. В этом случае артефакты это репорты и билд. В случае с докером допустим у меня собирается docker-контейнер, на нем прогоняются тесты и он пушится в репозиторий. По сути артефактом будет новая ревизия в репозитории докер имиджей, а не файл который можно заархивировать. Хотя репорты всеравно остаются.

Что такое "артефакт" в рамках Сontinuous Delivery PHP приложений?

kalya: посмотрите список исключений, мы берем рабочий код и убираем все то что не нужно для его запуска (например app_dev.php на сервере уже не нужен, или кэши или .git). composer.json так же не надо, у вас уже должны быть установлены все вендоры и сгенерирован и autoload.php и bootstrap.php.cache.

По сути это билд. Он загружается на сервер, распаковывается, туда добавляется parameters.yml (или как альтернатива все параметры могут быть в параметрах окружения и разруливаться через ENV), и должен работать сразу после этого. Никаких дополнительных действий кроме cache:clear -e=prod и накатки миграций производиться не должны

Как прокинуть Callback в Go из под Ruby?

Обычно такого рода задачи решаются через организацию pub/sub или через MQ (ZeroMQ например). Хотя идея писать расширения для ruby на go это конечно приколько.

Как реализованно это меню хабрахабра?

Therapyx: дебагер браузера и вперед. Там все довольно примитивно если что.

С чего начать изучение написания TDD - тестов?

abcd0x00:

При TDD тестового кода по количеству больше программного в десять раз.

У вас выборка не репрезентативна. Я понимаю еще в два раза, но в 10... Опять же TDD не регламентирует вам сколько у вас должно быть покрыто тестами кода, 10% или 100%. Когда у вас тестов в 10 раз больше чем кода, это повод задуматься. Либо у нас мегакритичная часть приложения которая должна учитывать все позитивные и негативные сценарии на всех пограничных случаях, либо большая часть наших тестов бесполезна для нас.

Вообще доводы в духе "жалко удалять" это смешно. Если делать все небольшими итерациями то вам никогда не придется удалять насктолько большое количество тестов, что бы стало жалко, так как вместе с развитием наших требований, которые будут постоянно уточняться или меняться, будет эволюционировать и код и тесты.

С чего начать изучение написания TDD - тестов?

То есть сами тесты фиксируются, их нельзя менять/удалять, потому что они контролируют этот непричёсанный код.

Тесты фиксируются ровно на тот момент, когда вы редактируете код. То есть алгоритм такой:

- чуть чуть поправили код
- прогнали тесты и убедились что ничего не сломали
- чуть чуть подправили тесты
- прогнали тесты и убедились что вы не сломали ничего в тестах, в этом случае гарантом того что все работает выступает ваш код

Ну и так до бесконечности. Разбиение процесса на маленькие итерации позволяет вам менять код и тесты чаще, чем у вас могут меняться требования. Тесты и код выступают взаимным гарантом того что все работает. При таком подходе расходы на поддержание тестов значительно сокращаются. А когда вы месяц писали тесты без кода, вы выходит этот месяц и рефакторить их не могли.

Ну конечно может быть ситуация с истеричным клиентом, который будет заваливать вас письмами об изменениях в функционале каждые 15 минут, но для решения этой пролемы есть другие методики, такие как скрам, когда вы можете взять задач на неделю и ложить болт на все хотелки клиента, рассматривая их только на грумингах. TDD это методология, которая относится только к разработчикам. Если у вас проблемы на других уровнях конечно TDD вам не поможет.

Я понял, что там почти ничего нет, деланного с нуля.

Ух... как все запущено...

Какой инструмент выбрать для интеграционных тестов C++?

gherkin язык больше для описания бизнес-сценариев.

С чего начать изучение написания TDD - тестов?

Это делается затем, что если требования меняются к коду, чтобы переписать только тесты под новые требования

Ну предположим я понимаю, но... Например в моем случае мы минимум раз в две недели, а то и чаще выкатываем билды клиенту. То есть с момента старта проекта через 2 недели он уже должен что-то увидеть, пощупать. При таком раскладе делать месяц только тесты это не продуктивно. От реализации бэкэнда могут зависить другие компоненты и т.д. Да и когда мы пишем только тесты мы не можем рефакторить их, так как нет кода, нет возможности проверить что мы случайно не поломали эти тесты. Словом... в реалиях всяких там скрамов/канбанов подход когда пишут сразу сотню тест кейсов это как-то странно. Даже QA тесткейсы/чеклисты формируют для своей работы в процессе разработки а не до нее.

В тестах-то они выдумываются.

Опять же, разница в процессах. Для того что бы получить реальные данные я просто организую релизы как можно чаще. тесты в моем случае понижает риск регрессий, что позволяет с меньшими рисками вносить изменения и чаще релизиться.

А ты когда-нибудь поднимал версии программ?

Да, это бывает обидно дропать фичу над которой ты сидел 3 месяца, но от этого никуда не уйти. Вообще с учетом того что весь код в VCS хранится, удалять что-то не так страшно. Жалко только потраченного времени но это быстро проходит.

Там они (америкосы) предлагают оставлять говнокод до рефакторинга

Вот я пытался бороться с говнокодом, вводили кодревью и прочее.... и в итоге я всеравно пришел к тому что в этом нет никакого value, пусть себе будет до рефакторинга. Работает и ладно. На эту тему мне очень нравится высказывание аля "everybody poops but doing it in one place". То есть, говнокод допустим если он закрыт красивым интерфейсом, изолирующим реализацию извне. Тогда рефакторинг не будет болью и его можно отложить.

В любом случае, если ты видешь что тебе надо поменять интерфейс и это вызывает кучу изменений в тестах, это значит что надо рефакторить тесты. Устранять дублирование. Как только мы это сделаем, мы можем приступать к реализации сломанного теста и делать дела.

Ты просто так не перекинешь эту инфраструктуру в другие программы

Инфраструктура покрыта функциональными/e2e тестами. Ты же не будешь покрывать тестами реализацию репозитория для базы данных, мокать query builder-ы и т.д. Это тупо, скучно, занимает много времени и несет мало ценности. Замокать репозиторий - да, замокать зависимости репозитория - не выйдет нормально. С точки зрения оптимизации времени разработки это наиболее выгодный подход. Бизнес логика не так часто меняется на уровне интерфейсов объектов и да даже если она меняется, это никогда не приносить каких-то мегабольших изменений вроде "блин надо добавить еще аргумент в тысячу тесткейсов", обычно изменение сигнатуры одного метода затрагивает только тесты, которые этот метод юзают, а это не может быть много тестов. Обычно такие изменения разве что у репозиториев бывают.

Повторюсь, у меня есть 3 слоя:
- domain layer - сущности, vo, сервисы. Все это покрыто юнит тестами. Чем сложнее бизнес логика, там удобнее применять TDD для разработки. Этот слой редко подвержен изменениям на уровне интерфейсов и т.д. А если интерфейсы и меняются, то затрагивают не так много тест кейсов, так как все максимально независимо друг от друга.
- application layer - сервисы уровня приложения, задача которых принять DTO запроса, дернуть другие сервисы что бы регламентировать флоу, и сформировать DTO ответа. Этот слой можно покрыть юнит тестами но это довольно скучно, так как по сути сам по себе этот слой не выполняет логику, он лишь регламентирует последовательность действий. Этот слой часто меняется и удобнее покрывать его интеграционными/функциональными/E2E тестами
- UI layer - в моем случае это довольно тонкая прослойка, чья задача состоит только в том что бы сконвертить запрос (обычно это http запрос) в DTO в нужном формате. У нас могут быть разные версии API или еще чего, да и код там обычно довольно тупой - замэпить объект на объект. Так же покрывается функциональными/E2E тестами.
- Слой инфраструктуры, он сквозной и реализует все интерфейсы, объявленные на предыдущих слоях. Например Domain layer регламентирует интерфейс репозитория где хранятся данные, а этот слой его реализует. На 90% этот слой - это фреймворк и/или сторонние библиотеки который мы используем, он уже покрыт юнит тестами. Оставшиеся 10% того что пилем мы - функциональные тесты.

Да, главное, что-нибудь посложнее написать, чтобы потом никто в этом не разобрался. :)

Да ладно, это может звучит сложно, по факту это все очень легко и красиво поддерживать.

С чего начать изучение написания TDD - тестов?

abcd0x00:

Не идёт оно вразрез. Просто вместо одного теста ты пишешь сто.

Ну и зачем так делать? Можно например написать не 1 тест а 10, я так иногда делаю когда более-менее уверен в том что как должно быть. Но 100 тест кейсов... это явно перебор. Less is more, как говорится.
Ты пишешь тест, пишешь код, а потом оказывается, что это всё не нужно, потому что вообще не подоходит ко всему остальному. Вопрос мативации и скуки к слову у Кента Бэка хорошо раскрывается.
На высоком уровне представление в голове должно быть, это да, но на уровне интерфейсов - не обязательно. Для этого мы и пишем тесты, что бы оформить требования. Тут еще все зависит от того как писать код. Скажем есть концепция "единого языка", когда ты просто берешь требования и переписываешь их в виде теста максимально близко к исходной формулировке. В этом случае написание теста не требует сильно много времени, так как мы берем требования клиента и просто их записываем в тестах, а интерфейс формируется из терминов клиента, которые определяются в требованиях. В голове такие штуки довольно сложно держать, особенно если предметная область не привычна для разработчика.

Речь идёт про реальные данные, которые нужны, а не про составленные.

А в чем разница то? Реальные данные вы получите не раньше чем выкатите разрабатываемый функционал в продакшен или как минимум на стэйджинг, все остальное и так составные данные. В случае же со сложной бизнес логикой написание тестов способствует открытию кейсов о которых вы раньше не подумали и не обсудили.

а она не подходит к тем фичам, которые уже есть.

Как? По архитектурным причинам? Маловероятно, либо у нас система с очень большой связанностью, чего я лично стараюсь избегать. Если фича не подходит потому что идет в разрез с уже заимплеменченными фичами, эта проблема устраняется еще на этапе планирования или бизнес анализа, когда хотелка приходит в бэклоги, на грумингах, сторимэппингах и прочих штуках.

Тот интерфейс, который получается, формируется при создании тестов.

У Дяди Боба скажем довольно жесткие правила:

- You are not allowed to write any production code unless it is to make a failing unit test pass.
- You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
- You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

И ни слова о интерфейсах и прочего. Следовать этим правилам слепо иногда глупо конечно, здравый смысл иногда подсказывает что можно их нарушать, но придерживаться стоит. Интерфейс действительно формируется через тесты, но это побочный эффект а не правило.

потому что пишешь не для себя, а чисто продал и забыл

Требования к моим проектам меняются по паре раз в неделю. Это обычное дело. А еще есть суппорт приложений, новые версии, новые итерации... Я совру если скажу что всегда придерживаюсь этих правил, или там... всегда практикую TDD, но все же стараюсь придерживаться этого. Скажем мой тестовый фреймворк который я использую для юнит тестирования имеет средства кодогенерации (добавление несуществующих методов например), удобный сахар для моков и тд. И практиковать при таком раскладе TDD становится довольно удобно. Да и юнит тестами у меня покрывается только слой бизнес логики и ооочень редко инфраструктурный слой. Так что я так же пишу только самые необходимые тесты, негативные сценарии и прочее, что подкидывают QA, добавляются и хэндлятся уже позже.

Вот представь себе частое изменение требований, когда тесты надо выкидывать, потому что программа поменяла интерфейс.

Так программа или UI? У интерфейса добавился еще один аргумент? Ну... я вообще стараюсь избегать интерфейсов методов с более чем двумя аргументами, все дробится на VO и объекты-конфигурации и т.д. Так же я люблю для каких-то сложностей пихать через дабл диспатч сервисы в методы моих бизнес-объектов.

Вообще все несколько сложнее. Я загоняюсь по DDD и прочим веселым штукам, так что TDD для меня никогда проблемы не составляло. А вот для CRUD или там для транзакционных скриптов да, тут грустно...