Accessibility в вебе — это не сложно на самом деле. И семантические интерактивные элементы — важная его часть. Иначе получится postman. Который из-за отсутствия семантики почти не юзабелен. А вот тег footer, действительно, не принципиален.
Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Наследие эпохи PHP ещё долго будут разгребать и какие-то улучшения там происходить ещё точно будут.
Новые проекты на нем все так же пишутся. В своей области он вполне популярен.
Нужны какие-то очень весткие мотивы, чтобы заманить их обратно.
Я считаю, что у php довольно пологая кривая обучения, плюс Очень хорошая инфраструктура в своей области. Часто слышу, что php разрабов проще найти / они меньше стоят, что немаловажно для компаний.
Так что доля php может глобально и снижается, особенно за счет узости его применения. Но жизнь на нем вполне есть. И профессионал, и новичок в ближайшие 10 лет без работы не останутся.
На рынке кроме фактора спроса на язык есть еще и предложение спецов, умеющих в него. И на php, imho, проще начинать. В т.ч. из-за кучи фриланса и простых инструментов на нем.
переучись ты на другой стек, это не так уж сложно, если голова работает правильно…
А чем backend на java принципиально лучше, чем на php?
У меня в команде работал чел, перешедший с C# на php. Говорил, что Doctrine получше чем EF. Да и работу новичку проще найти.
И будут за тобой стоять очереди эйчаров.
За толковыми php-шниками тоже очередь. Видимо, везде сейчас так.
На php куча админок, систем управления делается. В т.ч. и с нуля. Как-то в разработке онлайн банка участвовал. На почту постоянно идет поток предложений рассмотреть ту или иную вакансию. Так что с редкостью COBOL вы уж совсем мимо.
И сам php как язык, отягощенный обратной совместимостью с не самыми лучшими решениями, по сравнению с новыми ЯП может и не очень. Хотя и он неплохо развивается. Но вот удобных фреймворков и библиотек на нем написана масса. Так что в целом разрабатывать легко и приятно.
С точки зрения пользования со скринридером оценки комментариев до их текста удобнее, чем после. Т.к. ты можешь заранее увидеть его рейтинг и либо остановиться внимательнее, либо вообще пропустить.
Мне кажется в вопросе заселения цивилизацией местной галактики есть несколько спорных предположений:
Цивилизация стремится к неограниченной экспансии.
Во всех развитых странах уровень рождаемости последнее время снижается. Вплоть до отсутствия воспроизводства населения. Легко предположить, что в относительно скором времени все население земли перестанет расти. А в таком случае для чего нужна экспансия? Ресурсов земли должно хватить на всех. А сидеть в своем смартфоне куда проще и интереснее, чем бороздить бесконечные просторы.
Технологии развиваются неограниченно.
Последние столетия наука развивалась очень быстро и сильно поменяла нашу жизнь. И успевшим к этому привыкнуть кажется, что так будет продолжаться всегда. Но в плане физики все скорее наоборот. Значимые с точки зрения практического использования явления открывать все сложнее и сложнее. Да и космические технологии развиваются куда медленнее, чем ожидали фантасты середины 20 века. Что уж говорить о приближении скорости перемещения в пространстве хотя бы к скорости света, без чего сложно представить межзвездные перелеты.
Так что окукливание немногочисленного человечества в киберпространстве кажется пока более реальной перспективой, чем создание хотя бы межзвездной цивилизации.
С каждым следующим поиском работы все прохладнее отношусь к тестовым заданиям.
В большинстве мест меня прекрасно брали и без них, после чего мы долго и успешно сотрудничали.
Задание часто требует больше времени, чем ты ожидаешь. Все-таки не каждый день нужно заново настраивать проект со всеми зависимостями. Плюс мне как бекендеру дают интеграцию с какими-нибудь апи внешних сервисов. Т.е. ты параллельно должен еще разобраться и с ними.
Жестко выбешивает, когда запрещают пользоваться фреймворками. Алло, у меня даже в резюме в графе должность / роль стоит "%framework_name% developer". И откликаюсь я именно на те вакансии, где он и используется. Но нет, ребятам хочется проверить "мои общие подходы". После чего ты каждый раз изобретаешь тот же фреймворк заново. Привет пункту 2.
Твою работу часто оценивают по принципу нравится / не нравится. У разрабов "я бы сделал иначе" и "ты написал фигню" нередко означает одно и то же. А попробуй по общим формулировкам ТЗ понять, что они хотят увидеть, да еще и в велосипедном исполнении.
Ну, и в конце они на тебя еще и забивают. Я чуть ни 2 недели бегал за одним товарищем, чтоб получить хоть какую-то обратную связь по тестовому. Ок, я уже понял, что вы меня не берете. Но оцените хотя бы то, на что я потратил все свое свободное время за 2 дня. В итоге он мне еще и по ошибке прислал отзыв по другому кандидату…
Туда же можно отнести и задание тестового, когда решение по твоей кандидатуре уже есть / от него не зависит. В этом легко могу понять негодование автора исходной статьи. Когда ты кучу времени делаешь никому не нужную ерунду, а в итоге тебе отказывают по совершенно другим причинам — это вызывает яркие эмоции.
повышают покупательную способность широких слоев населения — что, в конечном счёте, повышает прибыль собственников.
При условии замкнутости системы. В противном случае прибыль повышается у собственников азиатских производителей, а американские выдавливаются с рынка, вслед за чем падает покупательная способность широких слоев американского населения.
В подобных статьях однако любят выпячивать роль конкретной личности, задвигая на задний план ту среду, в которой они жили.
То же решение уйти вникуда из большой стабильной компании не выглядит столь безрассудно, если принять во внимание, что они находились в самом центре быстроразвивающейся отрасли. Где вокруг, как грибы после дождя, возникали успешные стартапы. А за углом жил знакомый венчурный капиталист, готовый вложить пару миллионов долларов в технологии, над которыми они до этого работали несколько лет.
Есть. Поэтому там решили не строить АЭС, а подогнать плавучие реакторы и переработать энергосистему под них. Плюс там планируются крупные проекты по добыче полезных ископаемых. Так что электричество очень нужно, и окупаемость должна быть достигнута.
если верить статистикам, превосходил танки/самолеты/артилерия Германию
Если ссылаться на того же Исаева, то он вполне внятно объясняет, что из себя по факту представляют десятки тысяч советских танков и куда они делись. Вкратце абсолютное большинство из них были легкими малоэффективными в 41 году машинами. Плюс абсолютное большинство танкового парка было потеряно в первый месяц войны. Когда немцы имели подавляющее численное преимущество в приграничном сражении. И хоть как-то их останавливать можно было только постоянными танковыми контратаками со слабой подготовкой и поддержкой и тяжелейшими потерями.
Так что прямое численное сравнение самолетов / танков может сказать далеко не все. Опуская их качество и эффективность использования, важно вспомнить про фактор стратегической внезапности нападения. И проблема там не в том, что солдаты на границе не успели попрыгать в окопы. А в том, что их было в разы меньше наступающих немцев. А на направлениях главных ударов на порядок. И дальше катастрофа развивалась как снежный ком.
вообще без подготовки бросать людей, это я и называю "забросать мясом".
Можно сейчас выдвигать любые благие пожелания на этот счет. Но ни ядерного оружия, ни спутниковой разведки, ни реактивной авиации у РККА на тот момент не было. И принципиально лучшую подготовку форсирования Днепра в тех условиях обеспечить было нельзя. И можно, конечно, говорить, что в той ситуации "врага забросали мясом". А можно, напротив, сказать, что быстрым форсированием спасли ни одну сотню тысяч жизней. Т.к. пробить устоявшуюся оборону по реке — это совсем другие потери. Да и параллельный геноцид находившегося под оккупацией населения никто не отменял.
именно такие действия и называются "забросать мясом"
Можете называть, как вам угодно. Но по мне детальный анализ того, что случилось, зачем и почему, более продуктивен, чем громкие эпитеты.
Ну, и если даже смотреть на итоговое соотношение потерь за всю войну, то оно вполне сопоставимо с поправкой на катастрофическое ее начало и организационно-технологическое превосходство Германии. Так что методы ведения войны в тех условиях примерно схожи и потери — тоже.
В любом случае не вполне понял вашу мысль. Локальное описание может быть вообще любое. А Днепр был форсирован относительно быстро и успешно. Сравните, например, с целом годом боев под Ржевом.
Немцам тогда еще менее сладко приходилось. Быстро отступать, часто в беспорядке — это совсем не весело. А на западном берегу их еще и несколько котлов ждало.
даже в мыслях не имеют научиться чему-нибудь полезному
А что полезнее в тех условиях может быть умения хорошо пользоваться АК?
проклятые каписталисты их ограбили!
Вы так говорите, как будто Атлантического треугольника а потом и колонизации не было. Или вы думаете, что столетия разрушения итак слабых местных государственных институтов никак не влияет?
Как раз изучаю Haskell. Там каррирование используется в основном, чтобы частично примененную функцию потом передать в функцию высших порядков. Ну, и для того, чтобы в бесточечном стиле лишние аргументы не пробрасывать. Еще прикольно одну функцию частично применять к другой. Результирующий тип по началу кажется очень неожиданным.
Так же нужно следить за хостингами, доступностями, SSL сертификатами и пр.
Github pages очень удобен в этом плане.
Аналогично с релизами. В случае с десктопом цена ошибки ниже. Если выявляется критическая бага, то пользователь просто будет пользоваться предыдущей версией.
В вебе релиз полностью под твоим контролем. Мне наоборот казалось, что это преимущество. Нашел багу — обновил сразу для всех. Нужно откатиться — для stateless сервиса это очень легко делается.
Но вообще ваше решение хорошо понятно и имеет безусловные плюсы. Особенно в контексте работы по флешке.
Может и можно через дженерики возвращать сущность из entityManager с не nullable id. Но при инжекте в контроллер с помощью ArgumentResolver уже придется прописывать дженерик вручную. Да и потом везде его по типам пропихивать. Так что трейт с getInitializedId с ассертом внутри кажется меньшей проблемой.
А ведь кроме id у сущности может быть куча автозаполняемых полей. CreatedAt updatedAt, createdBy… Часто они в doctrine event subscriber автоматом заполняются. Но тогда их тоже нужно делать nullable.
Я на одном небольшом проекте для себя успешно подружил Psalm с сущностями доктрины.
На моем текущем проекте у сущности может быть несколько десятков полей. Ну, пусть даже 10 из них не nullable. Как-то сомнительно их все через конструктор инициализировать. Да и формы с таким по дефолту не очень дружат. Не знаю насчет апи платформы и прочих библиотек..
Пехотные дивизии — да. Элитные танковые части, составляющие около 10% были полностью моторизованы. И именно они составляли основной элемент блицкрига. Т.к. танковая армия — это 150 — 200 тысяч человек, с танками, бронетранспортерами, моторизованной артиллерией, способных проходить по 100 км. в сутки. Именно они резали советскую оборону вначале войны. Пехота занимала территорию и добивала окруженные части.
Слышал, что отношение потерь РККА за ВОВ к потерям немцев и их союзников оценивается в 1,5 — 2 раза. Причем за 1941 соотношение было чуть ли не 4 / 1. Это было вызвано в основном большим количеством котлов, в которые попадали РККА в начале войны. Где гибли / попадали в плен целые армии и фронты со всем тыловым обеспечением. Во второй половине войны ситуация во многом отзеркалилась. Но соотношение до конца не выправилось.
А по поводу методов войны… Воевать можно тем способом, который позволяет обстановка и наличные ресурсы. Нельзя в середине войны объявить паузу, чтоб нарастить количество поддерживающей действия пехоты артиллерии. И обученный, вооруженный и организованный личный состав для генерала — это такой же ресурс. Не нужно думать, что он бесконечен / не имеет ценности.
Ну, и насчет форсирования Днепра… Форсировать препятствия проще всего сходу. Фронт к тому моменту быстро катился на запад. Если дать ему остановиться. Противник закрепится на западном берегу и сбивать его оттуда будет очень тяжело. А так все произошло быстро и с небольшими потерями в контексте сложности задачи.
Так что у войны мрачная логика. Но она все-таки есть.
Сам подключал psalm на прошлом проекте. Было интересно попробовать. Но в итоге впечатление сложилось двоякое. С одной стороны круто иметь статическую типизацию на php. С другой сама экосистема к этому была не слишком приспособлена. Те же symfony / doctrine тогда не имели нужных аннотаций. Да и вообще куча кода была написана с ориентацией на динамическую природу php.
Я причем эмпирически выставил строгость проверки что-то около 3. И в основном приходилось бороться с "вопросиками". Т.е. избавляться от nullable. И я до сих пор не до конца понимаю, как это нужно правильно делать, например, для сущностей доктрины. Т.е. все не nullable свойства с точки зрения типов нужно инициализировать в конструкторе. Но это сильно выбивается из общей практики. То же самое с автоинкрементным id. При создании новой сущности он должен быть null. Но потом этот вопросик сильно мешается в коде. Приходится добавлять во все сущности getInitializedId() :int с ассертом внутри. И так много в чем. Когда с точки зрения контекста использования ты знаешь лучше анализатора, что за реальный тип у этого значения.
Раздоры вокруг <div>
Accessibility в вебе — это не сложно на самом деле. И семантические интерактивные элементы — важная его часть. Иначе получится postman. Который из-за отсутствия семантики почти не юзабелен. А вот тег footer, действительно, не принципиален.
Не нужно стыдиться PHP
Даже по вашей ссылке php занимает вполне хорошее место. А с учетом того, что он, в отличие от прочих ЯП, представлен только в одной области, так вообще отличное.
Новые проекты на нем все так же пишутся. В своей области он вполне популярен.
Я считаю, что у php довольно пологая кривая обучения, плюс Очень хорошая инфраструктура в своей области. Часто слышу, что php разрабов проще найти / они меньше стоят, что немаловажно для компаний.
Так что доля php может глобально и снижается, особенно за счет узости его применения. Но жизнь на нем вполне есть. И профессионал, и новичок в ближайшие 10 лет без работы не останутся.
Не нужно стыдиться PHP
На рынке кроме фактора спроса на язык есть еще и предложение спецов, умеющих в него. И на php, imho, проще начинать. В т.ч. из-за кучи фриланса и простых инструментов на нем.
А чем backend на java принципиально лучше, чем на php?
У меня в команде работал чел, перешедший с C# на php. Говорил, что Doctrine получше чем EF. Да и работу новичку проще найти.
За толковыми php-шниками тоже очередь. Видимо, везде сейчас так.
Не нужно стыдиться PHP
На php куча админок, систем управления делается. В т.ч. и с нуля. Как-то в разработке онлайн банка участвовал. На почту постоянно идет поток предложений рассмотреть ту или иную вакансию. Так что с редкостью COBOL вы уж совсем мимо.
И сам php как язык, отягощенный обратной совместимостью с не самыми лучшими решениями, по сравнению с новыми ЯП может и не очень. Хотя и он неплохо развивается. Но вот удобных фреймворков и библиотек на нем написана масса. Так что в целом разрабатывать легко и приятно.
Сегодняшний UI хабра
С точки зрения пользования со скринридером оценки комментариев до их текста удобнее, чем после. Т.к. ты можешь заранее увидеть его рейтинг и либо остановиться внимательнее, либо вообще пропустить.
Парадокс Ферми – вовсе не парадокс, а вопрос; в чём он состоит, и как его решать (часть 1)
Мне кажется в вопросе заселения цивилизацией местной галактики есть несколько спорных предположений:
Цивилизация стремится к неограниченной экспансии.
Во всех развитых странах уровень рождаемости последнее время снижается. Вплоть до отсутствия воспроизводства населения. Легко предположить, что в относительно скором времени все население земли перестанет расти. А в таком случае для чего нужна экспансия? Ресурсов земли должно хватить на всех. А сидеть в своем смартфоне куда проще и интереснее, чем бороздить бесконечные просторы.
Технологии развиваются неограниченно.
Последние столетия наука развивалась очень быстро и сильно поменяла нашу жизнь. И успевшим к этому привыкнуть кажется, что так будет продолжаться всегда. Но в плане физики все скорее наоборот. Значимые с точки зрения практического использования явления открывать все сложнее и сложнее. Да и космические технологии развиваются куда медленнее, чем ожидали фантасты середины 20 века. Что уж говорить о приближении скорости перемещения в пространстве хотя бы к скорости света, без чего сложно представить межзвездные перелеты.
Так что окукливание немногочисленного человечества в киберпространстве кажется пока более реальной перспективой, чем создание хотя бы межзвездной цивилизации.
Когда очень хотелось получить работу в Америке или в бою все средства хороши
С каждым следующим поиском работы все прохладнее отношусь к тестовым заданиям.
Туда же можно отнести и задание тестового, когда решение по твоей кандидатуре уже есть / от него не зависит. В этом легко могу понять негодование автора исходной статьи. Когда ты кучу времени делаешь никому не нужную ерунду, а в итоге тебе отказывают по совершенно другим причинам — это вызывает яркие эмоции.
Детройт: как мировая моторная столица дошла до банкротства
При условии замкнутости системы. В противном случае прибыль повышается у собственников азиатских производителей, а американские выдавливаются с рынка, вслед за чем падает покупательная способность широких слоев американского населения.
ADOBE Systems — история удивительного успеха
Было интересно, спасибо.
В подобных статьях однако любят выпячивать роль конкретной личности, задвигая на задний план ту среду, в которой они жили.
То же решение уйти вникуда из большой стабильной компании не выглядит столь безрассудно, если принять во внимание, что они находились в самом центре быстроразвивающейся отрасли. Где вокруг, как грибы после дождя, возникали успешные стартапы. А за углом жил знакомый венчурный капиталист, готовый вложить пару миллионов долларов в технологии, над которыми они до этого работали несколько лет.
Новые АЭС в России и рост доли атома до 25%
Имхо подогнать парочку малых плавучих АЭС выглядит как-то реальнее. С дивана, как минимум.
Новые АЭС в России и рост доли атома до 25%
Есть. Поэтому там решили не строить АЭС, а подогнать плавучие реакторы и переработать энергосистему под них. Плюс там планируются крупные проекты по добыче полезных ископаемых. Так что электричество очень нужно, и окупаемость должна быть достигнута.
Как вырастить тупого ребёнка (научно обоснованные вредные советы)
Если ссылаться на того же Исаева, то он вполне внятно объясняет, что из себя по факту представляют десятки тысяч советских танков и куда они делись. Вкратце абсолютное большинство из них были легкими малоэффективными в 41 году машинами. Плюс абсолютное большинство танкового парка было потеряно в первый месяц войны. Когда немцы имели подавляющее численное преимущество в приграничном сражении. И хоть как-то их останавливать можно было только постоянными танковыми контратаками со слабой подготовкой и поддержкой и тяжелейшими потерями.
Так что прямое численное сравнение самолетов / танков может сказать далеко не все. Опуская их качество и эффективность использования, важно вспомнить про фактор стратегической внезапности нападения. И проблема там не в том, что солдаты на границе не успели попрыгать в окопы. А в том, что их было в разы меньше наступающих немцев. А на направлениях главных ударов на порядок. И дальше катастрофа развивалась как снежный ком.
Можно сейчас выдвигать любые благие пожелания на этот счет. Но ни ядерного оружия, ни спутниковой разведки, ни реактивной авиации у РККА на тот момент не было. И принципиально лучшую подготовку форсирования Днепра в тех условиях обеспечить было нельзя. И можно, конечно, говорить, что в той ситуации "врага забросали мясом". А можно, напротив, сказать, что быстрым форсированием спасли ни одну сотню тысяч жизней. Т.к. пробить устоявшуюся оборону по реке — это совсем другие потери. Да и параллельный геноцид находившегося под оккупацией населения никто не отменял.
Можете называть, как вам угодно. Но по мне детальный анализ того, что случилось, зачем и почему, более продуктивен, чем громкие эпитеты.
Ну, и если даже смотреть на итоговое соотношение потерь за всю войну, то оно вполне сопоставимо с поправкой на катастрофическое ее начало и организационно-технологическое превосходство Германии. Так что методы ведения войны в тех условиях примерно схожи и потери — тоже.
Как вырастить тупого ребёнка (научно обоснованные вредные советы)
Что по официальным данным СССР?
В любом случае не вполне понял вашу мысль. Локальное описание может быть вообще любое. А Днепр был форсирован относительно быстро и успешно. Сравните, например, с целом годом боев под Ржевом.
Немцам тогда еще менее сладко приходилось. Быстро отступать, часто в беспорядке — это совсем не весело. А на западном берегу их еще и несколько котлов ждало.
Современное пиратство глазами моряка. Наёмники
А что полезнее в тех условиях может быть умения хорошо пользоваться АК?
Вы так говорите, как будто Атлантического треугольника а потом и колонизации не было. Или вы думаете, что столетия разрушения итак слабых местных государственных институтов никак не влияет?
Функциональный Kotlin. Часть 2. Каррированные функции и где они обитают
Как раз изучаю Haskell. Там каррирование используется в основном, чтобы частично примененную функцию потом передать в функцию высших порядков. Ну, и для того, чтобы в бесточечном стиле лишние аргументы не пробрасывать. Еще прикольно одну функцию частично применять к другой. Результирующий тип по началу кажется очень неожиданным.
Java: есть ли жизнь на десктопе?
Github pages очень удобен в этом плане.
В вебе релиз полностью под твоим контролем. Мне наоборот казалось, что это преимущество. Нашел багу — обновил сразу для всех. Нужно откатиться — для stateless сервиса это очень легко делается.
Но вообще ваше решение хорошо понятно и имеет безусловные плюсы. Особенно в контексте работы по флешке.
Статический анализ и уже выросший проект: внедрять нельзя откладывать
Может и можно через дженерики возвращать сущность из entityManager с не nullable id. Но при инжекте в контроллер с помощью ArgumentResolver уже придется прописывать дженерик вручную. Да и потом везде его по типам пропихивать. Так что трейт с getInitializedId с ассертом внутри кажется меньшей проблемой.
А ведь кроме id у сущности может быть куча автозаполняемых полей. CreatedAt updatedAt, createdBy… Часто они в doctrine event subscriber автоматом заполняются. Но тогда их тоже нужно делать nullable.
На моем текущем проекте у сущности может быть несколько десятков полей. Ну, пусть даже 10 из них не nullable. Как-то сомнительно их все через конструктор инициализировать. Да и формы с таким по дефолту не очень дружат. Не знаю насчет апи платформы и прочих библиотек..
Как вырастить тупого ребёнка (научно обоснованные вредные советы)
Пехотные дивизии — да. Элитные танковые части, составляющие около 10% были полностью моторизованы. И именно они составляли основной элемент блицкрига. Т.к. танковая армия — это 150 — 200 тысяч человек, с танками, бронетранспортерами, моторизованной артиллерией, способных проходить по 100 км. в сутки. Именно они резали советскую оборону вначале войны. Пехота занимала территорию и добивала окруженные части.
Как вырастить тупого ребёнка (научно обоснованные вредные советы)
Слышал, что отношение потерь РККА за ВОВ к потерям немцев и их союзников оценивается в 1,5 — 2 раза. Причем за 1941 соотношение было чуть ли не 4 / 1. Это было вызвано в основном большим количеством котлов, в которые попадали РККА в начале войны. Где гибли / попадали в плен целые армии и фронты со всем тыловым обеспечением. Во второй половине войны ситуация во многом отзеркалилась. Но соотношение до конца не выправилось.
А по поводу методов войны… Воевать можно тем способом, который позволяет обстановка и наличные ресурсы. Нельзя в середине войны объявить паузу, чтоб нарастить количество поддерживающей действия пехоты артиллерии. И обученный, вооруженный и организованный личный состав для генерала — это такой же ресурс. Не нужно думать, что он бесконечен / не имеет ценности.
Ну, и насчет форсирования Днепра… Форсировать препятствия проще всего сходу. Фронт к тому моменту быстро катился на запад. Если дать ему остановиться. Противник закрепится на западном берегу и сбивать его оттуда будет очень тяжело. А так все произошло быстро и с небольшими потерями в контексте сложности задачи.
Так что у войны мрачная логика. Но она все-таки есть.
Статический анализ и уже выросший проект: внедрять нельзя откладывать
Сам подключал psalm на прошлом проекте. Было интересно попробовать. Но в итоге впечатление сложилось двоякое. С одной стороны круто иметь статическую типизацию на php. С другой сама экосистема к этому была не слишком приспособлена. Те же symfony / doctrine тогда не имели нужных аннотаций. Да и вообще куча кода была написана с ориентацией на динамическую природу php.
Я причем эмпирически выставил строгость проверки что-то около 3. И в основном приходилось бороться с "вопросиками". Т.е. избавляться от nullable. И я до сих пор не до конца понимаю, как это нужно правильно делать, например, для сущностей доктрины. Т.е. все не nullable свойства с точки зрения типов нужно инициализировать в конструкторе. Но это сильно выбивается из общей практики. То же самое с автоинкрементным id. При создании новой сущности он должен быть null. Но потом этот вопросик сильно мешается в коде. Приходится добавлять во все сущности getInitializedId() :int с ассертом внутри. И так много в чем. Когда с точки зрения контекста использования ты знаешь лучше анализатора, что за реальный тип у этого значения.