bisect'у можно скормить скрипт для проверки «этот коммит хороший?» и уйти пить чай, а потом прийти и увидеть тот самый коммит-проблему. При условии что не будет false-negative кейсов, как например если мы просто пробуем делать make, а у нас есть коммиты откровенно хламовые.
https://www.redblobgames.com/grids/hexagons/Мне очень понравилось применение такой интерактивности в статьях, прям какойто особый кайф от UI когда ты жмешь радиобаттон, меняется и визуалка и формулы расчетов.
Тоже приобрел Dyson. Да цена конечно ой-йой, но брать Xiaomi или аналогичных - ну по мощам они сильно слабее вроде.
Если по делу - Dyson очень хорошо себя показал на коврах. На ламинате, плитке - ну такое.
Недавно для своего ходи докупил еще Karcher WD3 (8000руб) - сосет он как не в себя, стружку деревянную, котов, детей - все. Но на ковре, все же если потом пройтись Dyson - можно еще 1 контейнер выкинуть всякой грязи.
Однако Dyson дает комфорт уборки - теперь как-то не хочется таскать за собой "тачку-бочку" и переодически переключать в другую розетку (хотя есть обычные пылесосы, которые имеют длинные провода). Ну и нет у Dyson мешков - лишние бабки не нужно на них тратить, так сказать "уже включено" =)
По мне так connexion лучше выглядит с этой стороны, начиная с того что сам подход spec-first выглядит более удачным, так ещё и вся эта история с роутингом, парсингом аргументов из коробки формируется из полноценной спеки, которую можно показать заинтересованным в нашем api.
Вот только не знаю насчёт генерации статичной доки.
Паттерны, «стандарты» — это все нужно применять тогда, когда они дадут пользу.
Однозначно сказать когда их нужно применять сложно — нужен опыт который даст «чутье».
Для себя считаю что такие практики нужны когда кодовая база подкрадывается к 50000 строк и разработчиков более одного.
Другая метрика — это наличие roadmap проекта. Если он запланирован на год вперед, в планах расширять штат разработчиков, тогда стоит задуматься над этими практиками.
В тоже время, есть история с микросервисами. Там все эти шаблоны и стандарты лежат в другой плоскости, там уже больше решений в плане «делать асинхронно или синхронно?», «какими данными владеет сервис?» и так далее. Но на уровне 1 сервиса, если это действительно «микро» (тоже субъективно, но допустим до 10к строк), можно обойтись процедурным программированием и применение SOLID, чистой архитектуры, паттернов — спорно.
В продерном подходе нет ничего плохого, просто некоторые решение проще построить на ООП, где-то возможно — ФП.
Я не смотрю на проект по принципу — написано без применения ООП — не поддерживается. Нужно смотреть код. Если читается легко и структура понятна, то пусть хоть на на чем угодно будет написан, главное что это оправдано. =)
Мы — только технические паттерны. Проект не большой и по началу все эти темы казались лишним усложнением обычного CRUD. Когда начала подъезжать бизнес логика — начали появляться свои паттерны, которые не найти у gof, а паттерны дяди Боба начали понемногу приносить пользу.
Сейчас наш «DDD State of the art” — это активное общение с заказчиком и редкие поболтушки на тему архитектуры всей командой.
Напоминает проект Drone.io, где также сборка происходит в контейнере. В начале осени присматривался, но отказался, т.к. фронтенд был(все ещё?) приколочен к CDN.
bisect'у можно скормить скрипт для проверки «этот коммит хороший?» и уйти пить чай, а потом прийти и увидеть тот самый коммит-проблему. При условии что не будет false-negative кейсов, как например если мы просто пробуем делать make, а у нас есть коммиты откровенно хламовые.
В основном да, и.к. Я туда за ними пришел. Но и А* мне тоже было приятно изучать.
Для меня лично, наглядные таие интерактивчики помогли лучше усвоить материал.
https://www.redblobgames.com/grids/hexagons/Мне очень понравилось применение такой интерактивности в статьях, прям какойто особый кайф от UI когда ты жмешь радиобаттон, меняется и визуалка и формулы расчетов.
Тоже приобрел Dyson. Да цена конечно ой-йой, но брать Xiaomi или аналогичных - ну по мощам они сильно слабее вроде.
Если по делу - Dyson очень хорошо себя показал на коврах. На ламинате, плитке - ну такое.
Недавно для своего ходи докупил еще Karcher WD3 (8000руб) - сосет он как не в себя, стружку деревянную, котов, детей - все. Но на ковре, все же если потом пройтись Dyson - можно еще 1 контейнер выкинуть всякой грязи.
Однако Dyson дает комфорт уборки - теперь как-то не хочется таскать за собой "тачку-бочку" и переодически переключать в другую розетку (хотя есть обычные пылесосы, которые имеют длинные провода). Ну и нет у Dyson мешков - лишние бабки не нужно на них тратить, так сказать "уже включено" =)
По мне так connexion лучше выглядит с этой стороны, начиная с того что сам подход spec-first выглядит более удачным, так ещё и вся эта история с роутингом, парсингом аргументов из коробки формируется из полноценной спеки, которую можно показать заинтересованным в нашем api.
Вот только не знаю насчёт генерации статичной доки.
Однозначно сказать когда их нужно применять сложно — нужен опыт который даст «чутье».
Для себя считаю что такие практики нужны когда кодовая база подкрадывается к 50000 строк и разработчиков более одного.
Другая метрика — это наличие roadmap проекта. Если он запланирован на год вперед, в планах расширять штат разработчиков, тогда стоит задуматься над этими практиками.
В тоже время, есть история с микросервисами. Там все эти шаблоны и стандарты лежат в другой плоскости, там уже больше решений в плане «делать асинхронно или синхронно?», «какими данными владеет сервис?» и так далее. Но на уровне 1 сервиса, если это действительно «микро» (тоже субъективно, но допустим до 10к строк), можно обойтись процедурным программированием и применение SOLID, чистой архитектуры, паттернов — спорно.
В продерном подходе нет ничего плохого, просто некоторые решение проще построить на ООП, где-то возможно — ФП.
Я не смотрю на проект по принципу — написано без применения ООП — не поддерживается. Нужно смотреть код. Если читается легко и структура понятна, то пусть хоть на на чем угодно будет написан, главное что это оправдано. =)
Мы — только технические паттерны. Проект не большой и по началу все эти темы казались лишним усложнением обычного CRUD. Когда начала подъезжать бизнес логика — начали появляться свои паттерны, которые не найти у gof, а паттерны дяди Боба начали понемногу приносить пользу.
Сейчас наш «DDD State of the art” — это активное общение с заказчиком и редкие поболтушки на тему архитектуры всей командой.
Напоминает проект Drone.io, где также сборка происходит в контейнере. В начале осени присматривался, но отказался, т.к. фронтенд был(все ещё?) приколочен к CDN.