Нет. Это методология, т. е. подход к разработке. Так же как и TDD не является подходом к созданию языка программирования, так и ваше определение BDD неверно.
Вы вероятно имеете в виду Gherkin. Но это частный случай, и ваша критика, таким образом относится к конкретной реализации, и не стоит её эстраполировать на всю концепцию, ведь теоретически реализации могут быть любыми, более или менее формальным, с разной долей эвристики, и какие угодно.
Ваш изначальный аргумент, я признаться до конца не понял, могли бы его развернуть в примерах?
Действительно глубокое погружение.
И на удивление качественно подготовленный материал, хороший стиль, в сравнении с большинством современных публикаций на Хабре.
Автор, пиши ещё!
Вы только что сформулировали принцип замещения)
Один мой знакомый бросая покупал вместо сигарет шоколад и другие сладости, компенсируя привычку брать пачку на кассе.
Я так понял посыл вводной в том, что смотрите, на какие суммы в баксах может выстрелить если писать не надёжный код. А дальше о том, что в Js про надёжность есть и насколько не с ней не радужно.
1. Docker как раз обеспечивает всё необходимое для запуска приложения окружение. Или мы не поняли друг друга.
2. Про ссылки на инструменты согласен, хорошая идея. Capistrano — наследие, «живых» свидетелей принятия решения не осталось, искать ответ «почему» смысла не имеет.
Deployer — большая часть разработчиков владеет php, и значительная часть приложений содержит php. Это значит можно почти любому поручить поддержку/разработку CI/CD и достигнуть большего единообразия в используемых технологиях. Так проще и дешевле.
Если коротко: администрирование и разработка — отдельные отделы. Группа тестирования (она же QA) входит в отдел разработки. За эксплуатацию отвечают администраторы, за релиз в прод QA. Тема обширная, тут тянет на отдельную «ретроспективу изменений в процессах тестирования и эксплуатации»). Культура взаимодействия, это то что сейчас хочется улучшать, и публикация на подобную тему может стать хорошей совместной работой. Большое спасибо за идею!
PS: За последний год совсем кардинальных изменений не было, так что в целом ты ещё должен помнить что и как =)
На shared грузильщиков как раз быстро банят, если вы про устойчивость его по отношению к хабраэффекту. Так что в чём-то маломощный домашний сервер может и выигрывать по доступности)
Пошёл по ссылкам в конце статьи. Описания и спецификации оставляют желать лучшего. Паста с китайского надмозга вестимо.
Противоречивые чувства. С одной стороны круто что вы вкладываетесь в рекламу здесь, через тематические статьи. С другой грустно, когда качество основного сервиса (сайта) на уровне агрегатора-посредника.
Пытаясь компенсировать эффект от блокирования и замещения рекламы, Brave тестирует систему поощрения издателей "Brave Payments". Эта система даёт пользователям возможность самим установить сумму, которую они готовы пожертвовать для поддержки посещаемых сайтов. Brave будет — с помощью особого алгоритма — вычислять процент от этой суммы, приходящийся на каждый конкретный сайт, который издатель получит в виде криптовалютного перевода, если он создал такую возможность. https://ru.m.wikipedia.org/wiki/Brave_(%D0%B2%D0%B5%D0%B1-%D0%B1%D1%80%D0%B0%D1%83%D0%B7%D0%B5%D1%80)
Как бы стартап от опытного игрока, с такой вот модной молодёжной бизнес моделью.
Сам webrtc под потоковое p2p заточен, если я верно осведомлён.
Можете развернуть ваш тезис, как именно вещи из области анонимности и децентрализации требуют webrtc?
Спасибо за качественную публикацию на актуальную тему.
Краткая суть: Думайте прежде чем делать.
Чем все и занимались до нашествия гибких методологий.
И, внезапно, описанный подход работает сотни лет в строительстве, машиностроении и других инженерных дисциплинах: Предсказуемый результат в рамках известного бюджета.
Почему в it последние годы есть тенденция к уходу от глубокого проектирования и планирования? Могу предположить, что эта мода оттуда, где есть незанятый капитал, готовый на серьёзный риск ради быстрой сверхприбыли.
Нет. Это методология, т. е. подход к разработке. Так же как и TDD не является подходом к созданию языка программирования, так и ваше определение BDD неверно.
Вы вероятно имеете в виду Gherkin. Но это частный случай, и ваша критика, таким образом относится к конкретной реализации, и не стоит её эстраполировать на всю концепцию, ведь теоретически реализации могут быть любыми, более или менее формальным, с разной долей эвристики, и какие угодно.
Ваш изначальный аргумент, я признаться до конца не понял, могли бы его развернуть в примерах?
Не могу согласиться с вами, поскольку BDD вовсе не язык программирования. Это методология. Поэтому ваш аргумент не уместен.
Действительно глубокое погружение.
И на удивление качественно подготовленный материал, хороший стиль, в сравнении с большинством современных публикаций на Хабре.
Автор, пиши ещё!
ReactPhp, релизится, ну надо же. Почти всю историю следил за развитием и участвовал по мере сил. Крутая новость!
Можете аргументировать?
Вы только что сформулировали принцип замещения)
Один мой знакомый бросая покупал вместо сигарет шоколад и другие сладости, компенсируя привычку брать пачку на кассе.
Я так понял посыл вводной в том, что смотрите, на какие суммы в баксах может выстрелить если писать не надёжный код. А дальше о том, что в Js про надёжность есть и насколько не с ней не радужно.
2. Про ссылки на инструменты согласен, хорошая идея. Capistrano — наследие, «живых» свидетелей принятия решения не осталось, искать ответ «почему» смысла не имеет.
Deployer — большая часть разработчиков владеет php, и значительная часть приложений содержит php. Это значит можно почти любому поручить поддержку/разработку CI/CD и достигнуть большего единообразия в используемых технологиях. Так проще и дешевле.
Если коротко: администрирование и разработка — отдельные отделы. Группа тестирования (она же QA) входит в отдел разработки. За эксплуатацию отвечают администраторы, за релиз в прод QA. Тема обширная, тут тянет на отдельную «ретроспективу изменений в процессах тестирования и эксплуатации»). Культура взаимодействия, это то что сейчас хочется улучшать, и публикация на подобную тему может стать хорошей совместной работой. Большое спасибо за идею!
PS: За последний год совсем кардинальных изменений не было, так что в целом ты ещё должен помнить что и как =)
inlcude, ещё не видел этой фичи. В некоторых случаях это действительно может помочь.Пошёл по ссылкам в конце статьи. Описания и спецификации оставляют желать лучшего. Паста с китайского надмозга вестимо.
Противоречивые чувства. С одной стороны круто что вы вкладываетесь в рекламу здесь, через тематические статьи. С другой грустно, когда качество основного сервиса (сайта) на уровне агрегатора-посредника.
Тоже интересный показатель, имхо, лучше чем ничего.
Это да. С этим приходится дополнительно бороться.
В копилку моего футуристического концепта.
Просто не пользуйтесь.
Я вот не пользуюсь.
Как бы стартап от опытного игрока, с такой вот модной молодёжной бизнес моделью.
Сам webrtc под потоковое p2p заточен, если я верно осведомлён.
Можете развернуть ваш тезис, как именно вещи из области анонимности и децентрализации требуют webrtc?
Спасибо за качественную публикацию на актуальную тему.
Краткая суть: Думайте прежде чем делать.
Чем все и занимались до нашествия гибких методологий.
И, внезапно, описанный подход работает сотни лет в строительстве, машиностроении и других инженерных дисциплинах: Предсказуемый результат в рамках известного бюджета.
Почему в it последние годы есть тенденция к уходу от глубокого проектирования и планирования? Могу предположить, что эта мода оттуда, где есть незанятый капитал, готовый на серьёзный риск ради быстрой сверхприбыли.