Вначале разрабы Gradle (Yarn, etc, подставить по вкусу) убивают кучу времени, чтобы правильно кешировать артефакты, и серьезно ускорять сборку, вплоть до секунд.
Потом приходят разрабы Gitlab (Github, etc, подставить по вкусу), которые положили болт на файловые кеши.
И в итоге конечным разрабам приходится придумывать обходные решения как скрестить ужа и ежа. ;)))
зы
и это еще хороший вариант, те кто поленивее, просто ждут 10 минут и больше на каждый билд.
Сторипоинты у разработчиков, это примерно как кубометры кирпичной кладки у каменщиков.
Сторипоинты, (и прочие измерения, типа маек) появились, т.к. у разработчиков отсутствуют простые способы измерения результатов их работ. Вследствие этого, сторипоинты не идеальны, в сравнении в кубометрами кладки, увы.
Чем плохо мерить в часах?
Тем же, что каменщиков мерить в человеко-часах. У каменщиков разная производительность. Один и тот же объем будет сделан за разное время. Поэтому оцениваем объем в кубометрах (в ит - сложность задачи в сторипоинтах). Потом с учетом производительности конкретных исполнителей можно получить затраты времени.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
Только один комментарий. Микросервисы - это не про технологии, микросервисы - это про бизнес, про способ организации работы большого количества разработчиков. И основной значимый критерий сервис микро или нет - одна ИТ команда (5-7 человеков) полностью отвечает за сервис, от разработки до сопровождения. Работает плохо этот сервис? Только эта команда его чинит.
Является ли микросервис - подой в кубере или OSGI-модулем в большом java-приложении - в общем случае неважно. Хотя в экстремуме микросервис должен обладать своими собственными ресурсами, которые никакой другой сервис забрать не может.
1) большого проекта с большим количеством провайдеров данных и нескольких фронтов (например, пара мобилок, веб-десктоп, терминал - все они похожи, но у каждого свои нюансы)
2) команда(-ы) хорошо знает GraphQL в принципе, тогда можно использовать и на более мелких проектах, но основанных на микросервисах.
GraphQL, очевидно, не панацея, и как любую другую технологию надо использовать с умом. И как любая другая технология, при использовании с умом - приносит только пользу.
Теперь, проектируя интерфейсы для фронта вы будете знать, что на фронте есть не только время, но и таймзона. И время с бека нужно отдавать/принимать с таймзоной. Фронт в свою очередь, должен работать с этим с учетом своей локали. Так надо делать всегда.
А вот надо ли хранить время в бд вместе с таймзоной - вопрос открытый.
И оба вопроса хоть и пересекаются между собой, но друг другу не мешают.
утверждение: "всегда хранить время c таймзоной", тоже может создавать нетривиальные проблемы.
например, изменение таймзоны в конкретной географической точке.
и тогда получается, что события сохраненные вчера в 17ч (+3), сегодня эти же события стали 16ч (+2), потому что сегодня ночью таймзона сменилась.
вообще, в случае микросервисов, и взаимодействия бд только с одним приложением, проблема с таймзоной внутри бд перестает быть актуальной. конкретное приложение становится ответственным за правильную работу с таймзоной. и соответственно можно хранить время в бд без таймзоны.
Да и честно говоря, слабо представляю как поженить честную БД транзакционность относительно сложного приложения и реактивность. Концепции друг другу прямо противоположные, прямо скажем. Безотносительно с Hb или без
По опыту, наблюдая проекты в которых API Gateway запилен на базе java-фреймворков, пришел для себя к предположению, что выбор решения был за чуваками, шарящими в java, но не шарящими чуть в сторону.
Это не хорошо, не плохо. Просто наблюдение. Нельзя шарить везде и во всем. А других шарящих чуваков в команде не оказалось.
В требованиях только вот это "Гейтвей должен маршрутизировать запросы в сервисы разных версий в зависимости от версии клиентского приложения" относительно нетривиально. Остальное штатным готовым API Gateway'ем решается.
Скрам применим тогда, когда есть возможность доставлять ощутимый результат до потребителя относительно короткими итерациями.
Может завод по производству чайников каждые две недели выпускать и доставлять до магазина модифицированную версию чайника - завод вполне может жить по скрам-рельсам.
Аналогично и в обратную сторону. Не может команда разработки каждые две недели релизить стабильную версию своего ПО, значит не надо им в скрам.
Вначале разрабы Gradle (Yarn, etc, подставить по вкусу) убивают кучу времени, чтобы правильно кешировать артефакты, и серьезно ускорять сборку, вплоть до секунд.
Потом приходят разрабы Gitlab (Github, etc, подставить по вкусу), которые положили болт на файловые кеши.
И в итоге конечным разрабам приходится придумывать обходные решения как скрестить ужа и ежа. ;)))
зы
и это еще хороший вариант, те кто поленивее, просто ждут 10 минут и больше на каждый билд.
Говорят, если SM перевести на Kotlin DSL, то и разрабы улетают в космос вместе со стульями
Сторипоинты у разработчиков, это примерно как кубометры кирпичной кладки у каменщиков.
Сторипоинты, (и прочие измерения, типа маек) появились, т.к. у разработчиков отсутствуют простые способы измерения результатов их работ. Вследствие этого, сторипоинты не идеальны, в сравнении в кубометрами кладки, увы.
Чем плохо мерить в часах?
Тем же, что каменщиков мерить в человеко-часах. У каменщиков разная производительность. Один и тот же объем будет сделан за разное время. Поэтому оцениваем объем в кубометрах (в ит - сложность задачи в сторипоинтах). Потом с учетом производительности конкретных исполнителей можно получить затраты времени.
Сторипоинты (кубометры у каменщиков) не отменяют учет трудозатрат. И то, и другое нужно мерить, и управлять.
И условно старый gradle процентов на 80 декларативный.
Дефолтный конфиг обычно выглядит как список плагинов, список репозитариев и список зависимостей. Это в чистом виде декларативность.
Я тоже практически всю жизнь скептически смотрел на mysql.
Пока в силу обстоятельстве в одном HL, HA проекте не был использован Oracle MySql 8
С тех пор кардинально изменил мнение об mysql в частности. И какой либо технологии в общем.
зы
у mysql - вагон форков, возможно далеко не все форки хороши. моя оценка про оракловый mysql
легко
В целом с большинством тезисов согласен.
Только один комментарий. Микросервисы - это не про технологии, микросервисы - это про бизнес, про способ организации работы большого количества разработчиков. И основной значимый критерий сервис микро или нет - одна ИТ команда (5-7 человеков) полностью отвечает за сервис, от разработки до сопровождения. Работает плохо этот сервис? Только эта команда его чинит.
Является ли микросервис - подой в кубере или OSGI-модулем в большом java-приложении - в общем случае неважно. Хотя в экстремуме микросервис должен обладать своими собственными ресурсами, которые никакой другой сервис забрать не может.
Свои сборки jdk есть у многих крупных компаний Китая и Европы.
И не только jdk.
Camunda 8-й версии научилась "из коробки" не выпадать в осадок, если вызываемые синхронные сервисы замедлились или таймаутят?
GraphQL окупается в случае:
1) большого проекта с большим количеством провайдеров данных и нескольких фронтов (например, пара мобилок, веб-десктоп, терминал - все они похожи, но у каждого свои нюансы)
2) команда(-ы) хорошо знает GraphQL в принципе, тогда можно использовать и на более мелких проектах, но основанных на микросервисах.
GraphQL, очевидно, не панацея, и как любую другую технологию надо использовать с умом. И как любая другая технология, при использовании с умом - приносит только пользу.
Есть БД, которые умеют хранить время с регионом таймзоны в одном поле?
Это просто опыт.
Теперь, проектируя интерфейсы для фронта вы будете знать, что на фронте есть не только время, но и таймзона. И время с бека нужно отдавать/принимать с таймзоной. Фронт в свою очередь, должен работать с этим с учетом своей локали. Так надо делать всегда.
А вот надо ли хранить время в бд вместе с таймзоной - вопрос открытый.
И оба вопроса хоть и пересекаются между собой, но друг другу не мешают.
даже больше скажу.
утверждение: "всегда хранить время c таймзоной", тоже может создавать нетривиальные проблемы.
например, изменение таймзоны в конкретной географической точке.
и тогда получается, что события сохраненные вчера в 17ч (+3), сегодня эти же события стали 16ч (+2), потому что сегодня ночью таймзона сменилась.
вообще, в случае микросервисов, и взаимодействия бд только с одним приложением, проблема с таймзоной внутри бд перестает быть актуальной. конкретное приложение становится ответственным за правильную работу с таймзоной. и соответственно можно хранить время в бд без таймзоны.
А почему бы не дать имя тесту как "Calculator's listSum should return 5"?
наверно потому что runas плохо дружит со скриптами
Да и честно говоря, слабо представляю как поженить честную БД транзакционность относительно сложного приложения и реактивность. Концепции друг другу прямо противоположные, прямо скажем. Безотносительно с Hb или без
По опыту, наблюдая проекты в которых API Gateway запилен на базе java-фреймворков, пришел для себя к предположению, что выбор решения был за чуваками, шарящими в java, но не шарящими чуть в сторону.
Это не хорошо, не плохо. Просто наблюдение. Нельзя шарить везде и во всем. А других шарящих чуваков в команде не оказалось.
В требованиях только вот это "Гейтвей должен маршрутизировать запросы в сервисы разных версий в зависимости от версии клиентского приложения" относительно нетривиально. Остальное штатным готовым API Gateway'ем решается.
Публикация джарок, сгенеренных с proto-файлов - понятно.
А вы делали публикацию/импорт самих proto-файлов из java/kotlin проектов? Protobuf - он же как бы мультиплатформенный.
По моему когда очень длинный флоу, то ни визуально, ни ...-as-code переварить очень сложно.
И спасает только декомпозиция.
А в целом, представлять флоу в виде человеко-ориентированного DSL (неважно какого, хоть Kotlin DSL, хоть любой прочий) - очень хорошая практика.
Скрам применим тогда, когда есть возможность доставлять ощутимый результат до потребителя относительно короткими итерациями.
Может завод по производству чайников каждые две недели выпускать и доставлять до магазина модифицированную версию чайника - завод вполне может жить по скрам-рельсам.
Аналогично и в обратную сторону. Не может команда разработки каждые две недели релизить стабильную версию своего ПО, значит не надо им в скрам.