Можно оптимизировать, как делают многие JPA: сделайте SQL sequence сразу с шагом 10, и кешируйте промежуточные значения. Однако, в этом случае могут появляться "дырки" и будет нарушен порядок по Id в случае нескольких инстансов.
Идея состоит в том, что на выполнение задачи уходит ровно столько времени, сколько было выделено.
А это как раз очень натурально получается. Всегда есть некий баланс между качеством и скоростью. Оптимальное решение всегда рождается, когда времени на реализацию достаточно: можно хорошо подумать, исследовать, отрефакторить и протестить.
Кроме того, практически любая задача включает в себя элемент неопределенности, связанный с проведением сторонних технологий или неким исследованием. Это может неожиданно увеличить время задачи, поскольку на этапе планирования все оптимисты.
Проблема в том, что в обратную сторону это не работает. Если удалось выполнить задачу за меньшее время, то никто не горит желанием брать себе следующую и тупо ждут следующего спринта.
Работаю над проектом в лучших традициях методологий: матрицы оценок, груминг, стендапы, etc. Все больше убеждаюсь, что все это не более чем формальность. Есть четкий функционал, который надо сделать к концу года, согласованный с клиентом. Есть некий план задач, что нужно сделать для этого. И внутри этого периода всегда есть пространство для маневра: разные неожиданности, сложности, сделать хорошо или быстро... Поэтому дробить каждую из задач дальше не имеет смысла: сразу теряется гибкость к адаптации, затрудняются изменения, а народ теряет из виду цели работы и фокусируется на тикетах, которые со временем имеют свойство растягиваться.
Общаясь с разными разработчиками, я заметил интересную тенденцию мнений по поводу спринга: чем лучше человек в нем разбирается, тем больше он его ненавидит.
Спринг из коробки предлагает много нужных вещей, которых не надо идти искать, рыская по всей экосистеме. С другой стороны, посредственный, а иногда отвратительный дизайн (привет Spring Securituy), куча неявных соглашений, @заклинания, кейсы, прибитые гвоздями без возможности модификации -- убивают все удовольствие от разработки. Впрочем, в этом заключается участь всех индустриальных стандартов. Шедевры не находят массового пользователя.
ЗАЧЕМ? Отдаем другу конверт не говоря какого цвета в нем карта
Плохо объяснено как всегда. Основное отличие в том, что в квантовой системе можно произвести частичное изменение, например получить результат, что карта на 40% синяя и на 60% красная. Другая соответственно будет на 60% синяя и на 40% красная. К тому же частичное изменение можно проводить с помощью третьей квантовой системы, запутанной с первыми двумя. К этому сложно подобрать классические аналоги.
Примерно так и есть. В реляционной модели вы определяете все связи на этапе дизайна, при этом само отношение не является полноправным объектом модели. В графовых бд связи являются такими же объектами как и сущности, и ими можно манипулировать в рантайме.
Немного оффтопика: по запросу графовых бд сразу выходит Neo4j, у которой просто отвратительная таргетированная рекламная кампания. После этого из каждого утюга ещё долго будут абьюзить рекламой оной. Так что открывайте в инкогнито.
А вообще главное отличие реляционных и графовых бд в том, что в первой отношения задаются статически, а во второй - динамически. Все.
EntityGraphs, емнип, не позволяют исключить из загрузки "примитивные" типы данных,
Может, и уже достаточно давно.
Возьмём наипростейший пример с пользователем и его банковским счётом
Это понятно. Но это не единственный кейс, хоть и распространенный. Если у вас инвентарная система с сотнями сущностей, и нужно организовать универсальный доступ к этим данным, при этом основной потребитель даже не фронт, а другие сервисы... задолбаетесь строчить тонны ненужных DTO и маппингов. Проще выставить всю модель наружу, при этом контролируя доступ к определенным полям. В качестве референтов можно указать Hateos и JPARS.
Идея тут в том, что не нужно слепо следовать паттернам только потому, что кто-то когда-то сказал, что нужно делать так, а не иначе, уповая на чей-то авторитет, а пытаться найти более красивое и удобное решение в каждом конкретном случае.
Это понятно. Просто изначально вопрос был, если модели данных практически полностью совпадает с API, то зачем делать ещё один слой, вместо того, чтобы отдать сразу Entities? Пример из прошлого: инвентарная система с огромным количеством разных Entities и API для доступа ко всем ним.
Там до Api как такового никому особо дела не было. Проект прошел по куче рук, и каждый реализовал тикет как мог. Для каждой новой фичи на бэке тупо писался свой контроллер, сервис, DTO и маппер. В итоге все т.н. "api" -- это куча findByXxx, которые отдают схожие DTO с немного разным набором филдов под каждый конкретный кейс.
Для сильно служебных полей есть @JsonIgnore и ещё куча способов исключить их из сериализации. Хорошая модель данных организована так, чтобы отделить процессинг от стейта: не загромождать сами Entities промежуточными состояниями и служебными данными, а выделить их в отдельный объект.
Согласно моему горькому опыту в любом проекте очень быстро замусоривается DTO, всевозможными мепперами и промежуточными сервисами. Доходит до того, что на одну entity получается с десяток схожих DTO. В то же время успешный рефакторинг на раздачу Entities уменьшил кодовую базу сразу на 90%.
Меня всегда удивляет боязнь девелоперов вместо DTO отдавать сразу Entities. Начинают что-то говорить, что это неправильно, и что-то про разные модели и секьюрити. Но на практике это те же самые POJO, и в 99% случаев из fieldset-ы совпадают. А при грамотно выставленных EntityGraphs можно четко контролировать отдаваемый контент. Поэтому чаще всего следуя каким-то искусственным паттернам, сами себе усложняем жизнь.
Не совсем понял как вы за 12 лет при месячном пробеге 500км смогли накатать 700к миль... И в описанном режиме реальная доступная ёмкость батареи составляет 40% минус деградация. Или я что-то не понял?
Идея интересная, однако не стоит так делать повсеместно. Здесь вы инкапсулируете в класс животного свойства, которые относятся больше к компетенции ZooWorker-а, и не имеют большого смысла в отрыве от него. Например вот у нас в зоопарке открылся ветеринарный отдел, и теперь снова будем нагружать бедных животных новыми свойствами и всей логикой, относящейся к ветеринарной службе? В итоге когда предметная область вырастет, ваши животные превратятся в пухлых монстров.
Первый параметр обеспечивает безгеморную десериализацию с Jackson-ом для immutable объектов, второй -- корректирует идиотское соглашение Java насчет package-private области видимости по умолчанию.
Можно оптимизировать, как делают многие JPA: сделайте SQL sequence сразу с шагом 10, и кешируйте промежуточные значения. Однако, в этом случае могут появляться "дырки" и будет нарушен порядок по Id в случае нескольких инстансов.
А это как раз очень натурально получается. Всегда есть некий баланс между качеством и скоростью. Оптимальное решение всегда рождается, когда времени на реализацию достаточно: можно хорошо подумать, исследовать, отрефакторить и протестить.
Кроме того, практически любая задача включает в себя элемент неопределенности, связанный с проведением сторонних технологий или неким исследованием. Это может неожиданно увеличить время задачи, поскольку на этапе планирования все оптимисты.
Проблема в том, что в обратную сторону это не работает. Если удалось выполнить задачу за меньшее время, то никто не горит желанием брать себе следующую и тупо ждут следующего спринта.
2016: left-pad npm package
Работаю над проектом в лучших традициях методологий: матрицы оценок, груминг, стендапы, etc. Все больше убеждаюсь, что все это не более чем формальность. Есть четкий функционал, который надо сделать к концу года, согласованный с клиентом. Есть некий план задач, что нужно сделать для этого. И внутри этого периода всегда есть пространство для маневра: разные неожиданности, сложности, сделать хорошо или быстро... Поэтому дробить каждую из задач дальше не имеет смысла: сразу теряется гибкость к адаптации, затрудняются изменения, а народ теряет из виду цели работы и фокусируется на тикетах, которые со временем имеют свойство растягиваться.
То есть где-то посередине подковы время стоит?
Общаясь с разными разработчиками, я заметил интересную тенденцию мнений по поводу спринга: чем лучше человек в нем разбирается, тем больше он его ненавидит.
Спринг из коробки предлагает много нужных вещей, которых не надо идти искать, рыская по всей экосистеме. С другой стороны, посредственный, а иногда отвратительный дизайн (привет Spring Securituy), куча неявных соглашений, @заклинания, кейсы, прибитые гвоздями без возможности модификации -- убивают все удовольствие от разработки. Впрочем, в этом заключается участь всех индустриальных стандартов. Шедевры не находят массового пользователя.
Плохо объяснено как всегда. Основное отличие в том, что в квантовой системе можно произвести частичное изменение, например получить результат, что карта на 40% синяя и на 60% красная. Другая соответственно будет на 60% синяя и на 40% красная. К тому же частичное изменение можно проводить с помощью третьей квантовой системы, запутанной с первыми двумя. К этому сложно подобрать классические аналоги.
Недостаток модели Эверетта в том, что количество вселенных счетно, а волновая функция непрерывна.
Примерно так и есть. В реляционной модели вы определяете все связи на этапе дизайна, при этом само отношение не является полноправным объектом модели. В графовых бд связи являются такими же объектами как и сущности, и ими можно манипулировать в рантайме.
Немного оффтопика: по запросу графовых бд сразу выходит Neo4j, у которой просто отвратительная таргетированная рекламная кампания. После этого из каждого утюга ещё долго будут абьюзить рекламой оной. Так что открывайте в инкогнито.
А вообще главное отличие реляционных и графовых бд в том, что в первой отношения задаются статически, а во второй - динамически. Все.
Может, и уже достаточно давно.
Это понятно. Но это не единственный кейс, хоть и распространенный. Если у вас инвентарная система с сотнями сущностей, и нужно организовать универсальный доступ к этим данным, при этом основной потребитель даже не фронт, а другие сервисы... задолбаетесь строчить тонны ненужных DTO и маппингов. Проще выставить всю модель наружу, при этом контролируя доступ к определенным полям. В качестве референтов можно указать Hateos и JPARS.
Идея тут в том, что не нужно слепо следовать паттернам только потому, что кто-то когда-то сказал, что нужно делать так, а не иначе, уповая на чей-то авторитет, а пытаться найти более красивое и удобное решение в каждом конкретном случае.
Это понятно. Просто изначально вопрос был, если модели данных практически полностью совпадает с API, то зачем делать ещё один слой, вместо того, чтобы отдать сразу Entities? Пример из прошлого: инвентарная система с огромным количеством разных Entities и API для доступа ко всем ним.
Там до Api как такового никому особо дела не было. Проект прошел по куче рук, и каждый реализовал тикет как мог. Для каждой новой фичи на бэке тупо писался свой контроллер, сервис, DTO и маппер. В итоге все т.н. "api" -- это куча findByXxx, которые отдают схожие DTO с немного разным набором филдов под каждый конкретный кейс.
Для сильно служебных полей есть @JsonIgnore и ещё куча способов исключить их из сериализации. Хорошая модель данных организована так, чтобы отделить процессинг от стейта: не загромождать сами Entities промежуточными состояниями и служебными данными, а выделить их в отдельный объект.
Согласно моему горькому опыту в любом проекте очень быстро замусоривается DTO, всевозможными мепперами и промежуточными сервисами. Доходит до того, что на одну entity получается с десяток схожих DTO. В то же время успешный рефакторинг на раздачу Entities уменьшил кодовую базу сразу на 90%.
Меня всегда удивляет боязнь девелоперов вместо DTO отдавать сразу Entities. Начинают что-то говорить, что это неправильно, и что-то про разные модели и секьюрити. Но на практике это те же самые POJO, и в 99% случаев из fieldset-ы совпадают. А при грамотно выставленных EntityGraphs можно четко контролировать отдаваемый контент. Поэтому чаще всего следуя каким-то искусственным паттернам, сами себе усложняем жизнь.
Не совсем понял как вы за 12 лет при месячном пробеге 500км смогли накатать 700к миль... И в описанном режиме реальная доступная ёмкость батареи составляет 40% минус деградация. Или я что-то не понял?
То есть время от растопки до закипания котла не берется в рассчет? К тому же:
Теплопотери у паровых двигателей на порядки больше. Огромный расход топлива на начальный нагрев рабочего тела, особенно в старт-стоп режиме.
Возможно по CO и углю паровой двигатель чище, но NOx выхлопов будет гораздо больше ввиду бОльшей температуры горения.
Извечный вопрос при покупке гибрида/электромобиля: через сколько лет мне придется менять батарею стоимостью полавтомобиля?
Вообще критичен не сам пробег, а время заправки и доступность точек. Даже при равном пробеге бензиновые авто здесь сильно выигрывают.
Идея интересная, однако не стоит так делать повсеместно. Здесь вы инкапсулируете в класс животного свойства, которые относятся больше к компетенции ZooWorker-а, и не имеют большого смысла в отрыве от него. Например вот у нас в зоопарке открылся ветеринарный отдел, и теперь снова будем нагружать бедных животных новыми свойствами и всей логикой, относящейся к ветеринарной службе? В итоге когда предметная область вырастет, ваши животные превратятся в пухлых монстров.
Есть еще файлик
lombok.config, который позволяет выставить параметры по-умолчанию для аннотаций всех подпакетов. У меня, например, выставлено:Первый параметр обеспечивает безгеморную десериализацию с Jackson-ом для immutable объектов, второй -- корректирует идиотское соглашение Java насчет package-private области видимости по умолчанию.