Наконец-то дошли руки интегрировать error prone, nullaway и checker framework. Каких-то явных ошибок в проекте не нашлось, в основном всяки слегка попахивающий код, типа неиспользуемых аннотаций @Slf4j.
Но столкнулись с проблемой при использовании Stream API: у нас в нескольких местах есть код вида "list.stream().map(this::canReturnNull).filter(Objects::nonNull).map(this::someOtherMethod)". NullAway в таком случае ничего не говорит (то ли достаточно умный что бы распознать Objects::nonNull, то ли не достаточно умный что бы в принципе со стримами разбираться). Но вот checker фреймворк в таком случае ругается, что someOtherMethod ожидает NonNull, а объекты в стриме - Nullable, хотя все нулл объекты отфильтрованы на предыдущем шаге.
На гитхабе тикеты с описанием этой проблемы существуют минимум с 2017 года, но проблема до сих пор не решена. Может быть знаете как можно обойти эту проблему? Добавлять SuppressWarning'и как-то не очень хочется, потому что в таком случае можно случайно реальную ошибку скрыть.
По текущим законам США, Твиттер является публичной площадкой и не несёт ответственности за контент публикуемый пользователями (так же как и ютуб и фейсбук). Они обязаны только соблюдать законы страны (удалять незаконный контент и т.д.) и модерировать в рамках установленных правил, одинаковых для всех.
Как только твиттер начинает выборочно удалять/модерировать пользователей, он теряет статус публичной площадки и становится издателем. А значит начинает нести прямую ответственность за весь контент публикуемый пользователями.
Так что пусть либо трусы наденут либо крестик снимут.
Идею вообще никак не настраивали и скорее всего она действительно покажет только 2 проверки из 10. В своё оправдание скажу, что в разношёрстной международной компании даже заставить разрабов установить гитовский pre-hook уже чудо :). Поэтому нужно было максимально простое решение которое бы ломало билд в случае ошибок, что бы можно было ткнуть носом потом.
Настройки в мавене тоже как у вас, разве что версии по новее.
Checker Framework не пробовал, надо будет поковырять на досуге. Тем более, что пишут что Checker Framework и ErrorProne можно использовать вместе.
Да. ErrorProne - это плагин для Maven/Gradle/Bazel, поэтому будет работать и локально и в CI с одними и теми же проверками и ошибками. А NullAway - это, получается, плагин для плагина.
NullAway по умолчанию считает, что все переменные и поля являются non-null, и компиляция будет падать с ошибкой если NullAway:
Найдёт место где вы пытаетесь присвоить null к такой переменной
Не может доказать, что поле всегда будет инициализированно каким-то значением
Вы пытаетесь обратиться к переменной, которая может быть null, без предварительной проверки на null
Мы для себя выработали такой подход: все non-null поля помечаем как final и используем ломбоковский @RequiredArgsConstructor, что бы сгенерировать конструктор принимающий эти поля. К остальным полям мы добавляем @Nullable аннотацию и проставляем значения через обычные сеттеры. При этом, насколько я понимаю, для NullAway не важно какую именно @Nullable аннотацию вы используете (мы используем спринговую), главное что бы имя аннотации было Nullable.
Единственная проблема, с которой мы столкнулись, это спринговые @ConfigurationProperties: если объявить поля такого класса как final и использовать @ConstructorBinding, то проперти становятся по факту иммутабельными. Но одно из требований нашего проекта - поддерживать обновление пропертей в рантайме, поэтому иммутабельные проперти нам не подходят. А если не использовать final и @ConstructorBinding, то NullAway ругается, что ему не удаётся доказать, что поля всегда будут инициализированны. Наше решение - использовать @Validated над классом + javax.validation.constraints.NotNull над non-null полями, и добавлять @SuppressWarnings("NullAway.Init"), что бы NullAway не проверял инициализацию полей (но он всё-равно будет проверять попытки обратиться к @Nullable полям этого класса)
Можно ещё подключить ErrorProne от гугла и плагин NullAway для него от Uber и получаем сразу статический анализатор + проверку на null в одном флаконе. Работает на этапе компиляции и довольно быстро, и не надо ничего дополнительно настраивать.
Как по мне, в соулсборн как-раз такой вариант прокачки. +1 к какой-либо характеристике = +1 уровень.
В итоге, разница в уроне между персонажем 10 уровня с неулучшенным оружием и персонажем 90-100 уровня (ближе к концу игры) с улучшенным оружием, будет всего раза в 3-4. И hp со стаминой будет больше процентов на 50-60.
Как результат, с одной стороны при наличии немного терпения и скила можно пройти всю игру хоть первым уровнем, с другой — даже в начальных локациях можно погибнуть от мобов если слишком расслабиться.
>Но зато после оценки ситуации с информационной безопасностью продукта ему уже практически ничего не будет угрожать
Видимо разработчики Axie Infinity этим так и не озаботились, потому что 23 марта у них с кошельков 615 миллионов долларов, а они об этом узнали только сегодня. И то только потому что им пользователи сообщили, что не могут вывести крипту со своих счетов.
Если молодой, есть хорошие запасы в валюте и английский на уровне, то как вариант — в языковую школу в Японии (оформление документов и визы займёт примерно полгода), а потом на месте искать работу в англоязычной компании (есть тут несколько штук). Тем более Япония похоже наконец-то решила открыть границы для студентов.
Учил английский именно читая мангу. Правда не берсерка, а Video girl Ai. Как прочитал — стал смотреть англоязычные стримы на твиче.
По началу ничего не понимал, но помогли донаты стримеру: сообщение с донатом всплывает на экране, я его читаю, стример тоже его в слух читает (это было еще до распространения авточиталок донатов) и начинает отвечать, а я, прокручивая в голове фразу произнесённую стримером, сопоставлял услышанный набор звуков с прочтёнными словами.
Выучил таким образом произношения нескольких слов → научился разделять разговорную речь на слова → запомнил часто употребляемые стримером слова и выражения → стал понимать ещё больше слов. Круг замкнулся. Эдакая само-поддерживаемая реакция.
После прочтения вашей прошлой статьи тогда, 10 лет назад, всерьёз задумался и поступлении в магистратуру в Японии, но я, как говорится, немного smoothbrain, никаких публикаций или научных работ для получения стипендии не имею, а без стипендии моё обучение зарубежом семья бы не потянула.
В итоге 10 лет спустя в Японию я всё-таки попал, но уже как ученик языковой школы. Правда из неё я уже ушёл и в данный момент жду когда будет готова рабочая виза.
Смотря где будете знакомиться. По приложениям знакомств мой опыт следующий:
Тиндер
Для 95% процентов совпадений — это просто способ попрактиковать английский или возможность похвастаться подругам, что познакомилась с гайдзином. При этом сами на английском либо не говорят, либо говорят «со словарём».
Бамбл, ОкКупид
В основном ищут либо обычных друзей, либо отношений. Большинство присутствующих в этих приложениях японок сами какое-то время жили за границей, поэтому особых трудностей с английским не испытывают.
Познакомиться где-то на улице или в кафе практически не реально, только если через общего друга. Кроме этого, есть кафе которые предлагают иностранцам скидки на напитки и позиционируют себя как место для поиска language exchange partner, но я в такие кафе не ходил.
Спойлер
Иногда доходит до абсурда. Вчера наткнулся на профиль, в котором прямым текстом написано, что девушка хочет ребёнка-полукровку, поэтому ищет иностранца-донора спермы. Обещает не требовать алиментов или признания ребёнка, но я на всякий случай решил не связываться.
Насчёт Токио пока что ничего не подскажу, только недавно туда переехал, но в Осаке если жить в однокомнатной конуре на 18 квадратов и особо никуда не ходить (я домосед, поэтому и в России жил примерно так же), то в месяц будете тратить порядка 1200-1300 долларов.
Хочу добавить про трудоустройство:
Есть компании, где разработка ведётся полностью на английском языке, соответственно в таком случае для получения рабочей визы и для работы знание японского совсем не нужно. Но для повседневной жизни я бы порекомендовал получить хотя бы N3 — более чем достаточно для подключения газа/воды/электричества/интернета и т.п.
Если у вас уже есть опыт работы разработчиком (про остальное IT и другие профессии ничего не скажу), то при трудоустройстве вам сначала предложат решить пару задач с leetcode уровня easy-medium, и потом вас будет ждать 4-5 раундов интервью: техническое с тимлидом, с HR и несколькими менеджерами (проекта/отдела/и т.д. и т.п.). При этом интервью с менеджерами могут объединить в одно. Но это не значит что вы в течении часа будете разговаривать со всеми менеджерами сразу, это значит что вы час разговариваете с одним менеджером, следом час со вторым и потом час с третьим.
Если же у вас нет опыта работы, то попытаться устроиться на работу вы сможете только раз в год — в апреле, когда заканчивается учебный год и выпускаются студенты. И конкурировать за рабочее место вы будете именно со студентами. Весь остальной год компании заняты обучением вчерашних студентов и собеседований не проводят. Даже компании, которые готовы нанимать студентов языковых школ, нанимают их, обычно, только 2 раза в год — апрель и октябрь.
Так же рассказывали, что компаниям не особо важно, чему конкретно обучался студент, потому что компании набирают не специалистов, а людей, и уже менеджеры решают кто кем будет работать. Могут отправить в отдел продаж, а могут отправить писать код на питоне, даже если ты в жизни ни строки кода не написал. Отсюда же и дикие требования/правила, вроде «написать всё резюме от руки красивым почерком» (некоторые его по 5-10 раз переписывают, что бы красивее было) или «блеснуть знаниями про компанию».
Банкинг в Японии зло
Вещи вроде налогов, коммунальных услуг, карточек оплаты ITunes/Nintendo/Playstation, пополнить счёт проездных Icoca и т.п. в принципе нельзя оплатить картой, только наличкой.
Долгое время пользовался картой банка Тинькофф с долларовым счётом, но в итоге открыл счёт в Sony Bank — есть онлайн банк на английском с англоязычной поддержкой, небольшой кешбэк, скидка на покупки в Playstation Store и можно наличку снимать 3 или 4 раза в месяц без комиссии.
Практически полностью отсутствовала вменяемая документация. В документации описывались либо какие-то высокоуровневые вещи, которые делаются через UI, либо документация была времён Liferay 5.x, который очень сильно отличается от 6.x. Что-то полезное можно было найти только в блогах разработчиков (которых почему-то было 2, и оба отделены от официальной документации)
Огромное количество JSP, который очень сложно отлаживать. По ощущениям, процентов 60 всего Java-кода приходилось именно на JSP.
Сложно сделать взаимодействие между портлетами (формами на странице).
Приличное количество багов в самой платформе. Сам находил 2 или 3 критичных для клиента бага, которые, объективности ради, были пофикшены в патчах, но поставить новый патч - огромное количество бюрократии, поэтому у клиента был собственный "форк" некоторых файлов фреймворка, которые подгружались вместо оригинальных при запуске сервера.
Очень долгая компиляция и запуск.
Надеюсь больше никогда не придётся к нему прикасаться. В одно время даже подумывал убрать все упоминания этого фреймворка из резюме.
Расскажу про свой опыт сдачи OCA 7: к моменту сдачи сертификации, у меня было примерно 2,5 года опыта работы на Java над энтерпрайзными проектами разного уровня сложности. Для подготовки к экзамену использовали разные книги, в том числе книги от Mala Gupta, которые упомянули выше в комментариях.
Для проверки уровня знаний использовали тесты от Ethuware. И так как проходили сертификацию за счет работодателя, условием допуска к экзамену было набрать минимум 70% на полном тесте от Ethuware (там есть тесты по отдельным разделам, и несколько тестов, которые покрывают все разделы, как на самой сертификации).
Я прошел пару тестов по отдельным разделам, прочитал 2 или 3 главы из книги Mala Gupta, прошел один полный тест, набрал что-то в районе 70-72%, прочитал комментарии к вопросам, на которые ответил неправильно и меня допустили проходить сертификацию.
Могу сказать, что вопросы в тестах от Ethuware хоть и похожи на вопросы из реального экзамена, но они немного сложнее. Поэтому 70% в этих тестах — это практически гарантированно 75%, а то и выше, на реальном экзамене.
Времени на прохождение всех вопросов хватило практически в притык, в конце осталась буквально пара минут, что бы проверить вопросы, в которых я сомневался, поэтому если вы не уверены в ответе на какой-то вопрос, то лучше не сидите над ним, а поставьте наиболее вероятный на ваш взгляд ответ, пометьте себе этот вопрос, и двигайтесь дальше. Если останется время, то в конце вернетесь что бы еще подумать над ответом.
На саму сертификацию ездили впятером с коллегами, результаты были известны уже через 10-15 минут после экзамена. Все пять человек набрали 88-95%.
Сейчас занят подготовкой с OCP 7, так как 2018 — последний год, когда можно сдать этот экзамен. Если в этом году не успею, то в следующий раз опять придется начинать с OCA. А если успею, то потом можно будет пройти апгрейд-сертификацию — что-то вроде облегченного экзамена на OCP 8.
Т.е. уничтожение дружелюбных юнитов и неподчинение приказам приносят ещё большую награду, чем выполнение боевой миссии?
А потом ещё смеются над военными, которые не могут натренировать модель
Наконец-то дошли руки интегрировать error prone, nullaway и checker framework. Каких-то явных ошибок в проекте не нашлось, в основном всяки слегка попахивающий код, типа неиспользуемых аннотаций @Slf4j.
Но столкнулись с проблемой при использовании Stream API: у нас в нескольких местах есть код вида "list.stream().map(this::canReturnNull).filter(Objects::nonNull).map(this::someOtherMethod)". NullAway в таком случае ничего не говорит (то ли достаточно умный что бы распознать Objects::nonNull, то ли не достаточно умный что бы в принципе со стримами разбираться). Но вот checker фреймворк в таком случае ругается, что someOtherMethod ожидает NonNull, а объекты в стриме - Nullable, хотя все нулл объекты отфильтрованы на предыдущем шаге.
На гитхабе тикеты с описанием этой проблемы существуют минимум с 2017 года, но проблема до сих пор не решена. Может быть знаете как можно обойти эту проблему? Добавлять SuppressWarning'и как-то не очень хочется, потому что в таком случае можно случайно реальную ошибку скрыть.
По текущим законам США, Твиттер является публичной площадкой и не несёт ответственности за контент публикуемый пользователями (так же как и ютуб и фейсбук). Они обязаны только соблюдать законы страны (удалять незаконный контент и т.д.) и модерировать в рамках установленных правил, одинаковых для всех.
Как только твиттер начинает выборочно удалять/модерировать пользователей, он теряет статус публичной площадки и становится издателем. А значит начинает нести прямую ответственность за весь контент публикуемый пользователями.
Так что пусть либо трусы наденут либо крестик снимут.
Идею вообще никак не настраивали и скорее всего она действительно покажет только 2 проверки из 10. В своё оправдание скажу, что в разношёрстной международной компании даже заставить разрабов установить гитовский pre-hook уже чудо :). Поэтому нужно было максимально простое решение которое бы ломало билд в случае ошибок, что бы можно было ткнуть носом потом.
Настройки в мавене тоже как у вас, разве что версии по новее.
Checker Framework не пробовал, надо будет поковырять на досуге. Тем более, что пишут что Checker Framework и ErrorProne можно использовать вместе.
Да. ErrorProne - это плагин для Maven/Gradle/Bazel, поэтому будет работать и локально и в CI с одними и теми же проверками и ошибками. А NullAway - это, получается, плагин для плагина.
NullAway по умолчанию считает, что все переменные и поля являются non-null, и компиляция будет падать с ошибкой если NullAway:
Найдёт место где вы пытаетесь присвоить null к такой переменной
Не может доказать, что поле всегда будет инициализированно каким-то значением
Вы пытаетесь обратиться к переменной, которая может быть null, без предварительной проверки на null
Мы для себя выработали такой подход: все non-null поля помечаем как final и используем ломбоковский
@RequiredArgsConstructor, что бы сгенерировать конструктор принимающий эти поля. К остальным полям мы добавляем@Nullableаннотацию и проставляем значения через обычные сеттеры.При этом, насколько я понимаю, для NullAway не важно какую именно
@Nullableаннотацию вы используете (мы используем спринговую), главное что бы имя аннотации былоNullable.Единственная проблема, с которой мы столкнулись, это спринговые
@ConfigurationProperties:если объявить поля такого класса как final и использовать
@ConstructorBinding, то проперти становятся по факту иммутабельными. Но одно из требований нашего проекта - поддерживать обновление пропертей в рантайме, поэтому иммутабельные проперти нам не подходят. А если не использовать final и@ConstructorBinding, то NullAway ругается, что ему не удаётся доказать, что поля всегда будут инициализированны.Наше решение - использовать
@Validatedнад классом +javax.validation.constraints.NotNullнад non-null полями, и добавлять@SuppressWarnings("NullAway.Init"), что бы NullAway не проверял инициализацию полей (но он всё-равно будет проверять попытки обратиться к@Nullableполям этого класса)Можно ещё подключить ErrorProne от гугла и плагин NullAway для него от Uber и получаем сразу статический анализатор + проверку на null в одном флаконе. Работает на этапе компиляции и довольно быстро, и не надо ничего дополнительно настраивать.
В итоге, разница в уроне между персонажем 10 уровня с неулучшенным оружием и персонажем 90-100 уровня (ближе к концу игры) с улучшенным оружием, будет всего раза в 3-4. И hp со стаминой будет больше процентов на 50-60.
Как результат, с одной стороны при наличии немного терпения и скила можно пройти всю игру хоть первым уровнем, с другой — даже в начальных локациях можно погибнуть от мобов если слишком расслабиться.
Видимо разработчики Axie Infinity этим так и не озаботились, потому что 23 марта у них с кошельков 615 миллионов долларов, а они об этом узнали только сегодня. И то только потому что им пользователи сообщили, что не могут вывести крипту со своих счетов.
По началу ничего не понимал, но помогли донаты стримеру: сообщение с донатом всплывает на экране, я его читаю, стример тоже его в слух читает (это было еще до распространения авточиталок донатов) и начинает отвечать, а я, прокручивая в голове фразу произнесённую стримером, сопоставлял услышанный набор звуков с прочтёнными словами.
Выучил таким образом произношения нескольких слов → научился разделять разговорную речь на слова → запомнил часто употребляемые стримером слова и выражения → стал понимать ещё больше слов. Круг замкнулся. Эдакая само-поддерживаемая реакция.
В итоге 10 лет спустя в Японию я всё-таки попал, но уже как ученик языковой школы. Правда из неё я уже ушёл и в данный момент жду когда будет готова рабочая виза.
Тиндер
Для 95% процентов совпадений — это просто способ попрактиковать английский или возможность похвастаться подругам, что познакомилась с гайдзином. При этом сами на английском либо не говорят, либо говорят «со словарём».
Бамбл, ОкКупид
В основном ищут либо обычных друзей, либо отношений. Большинство присутствующих в этих приложениях японок сами какое-то время жили за границей, поэтому особых трудностей с английским не испытывают.
Познакомиться где-то на улице или в кафе практически не реально, только если через общего друга. Кроме этого, есть кафе которые предлагают иностранцам скидки на напитки и позиционируют себя как место для поиска language exchange partner, но я в такие кафе не ходил.
Есть компании, где разработка ведётся полностью на английском языке, соответственно в таком случае для получения рабочей визы и для работы знание японского совсем не нужно. Но для повседневной жизни я бы порекомендовал получить хотя бы N3 — более чем достаточно для подключения газа/воды/электричества/интернета и т.п.
Если у вас уже есть опыт работы разработчиком (про остальное IT и другие профессии ничего не скажу), то при трудоустройстве вам сначала предложат решить пару задач с leetcode уровня easy-medium, и потом вас будет ждать 4-5 раундов интервью: техническое с тимлидом, с HR и несколькими менеджерами (проекта/отдела/и т.д. и т.п.). При этом интервью с менеджерами могут объединить в одно. Но это не значит что вы в течении часа будете разговаривать со всеми менеджерами сразу, это значит что вы час разговариваете с одним менеджером, следом час со вторым и потом час с третьим.
Если же у вас нет опыта работы, то попытаться устроиться на работу вы сможете только раз в год — в апреле, когда заканчивается учебный год и выпускаются студенты. И конкурировать за рабочее место вы будете именно со студентами. Весь остальной год компании заняты обучением вчерашних студентов и собеседований не проводят. Даже компании, которые готовы нанимать студентов языковых школ, нанимают их, обычно, только 2 раза в год — апрель и октябрь.
Так же рассказывали, что компаниям не особо важно, чему конкретно обучался студент, потому что компании набирают не специалистов, а людей, и уже менеджеры решают кто кем будет работать. Могут отправить в отдел продаж, а могут отправить писать код на питоне, даже если ты в жизни ни строки кода не написал. Отсюда же и дикие требования/правила, вроде «написать всё резюме от руки красивым почерком» (некоторые его по 5-10 раз переписывают, что бы красивее было) или «блеснуть знаниями про компанию».
Долгое время пользовался картой банка Тинькофф с долларовым счётом, но в итоге открыл счёт в Sony Bank — есть онлайн банк на английском с англоязычной поддержкой, небольшой кешбэк, скидка на покупки в Playstation Store и можно наличку снимать 3 или 4 раза в месяц без комиссии.
Работал на одном проекте на Liferay 6.2.
"Особенности" платформы на тот момент:
Практически полностью отсутствовала вменяемая документация. В документации описывались либо какие-то высокоуровневые вещи, которые делаются через UI, либо документация была времён Liferay 5.x, который очень сильно отличается от 6.x. Что-то полезное можно было найти только в блогах разработчиков (которых почему-то было 2, и оба отделены от официальной документации)
Огромное количество JSP, который очень сложно отлаживать. По ощущениям, процентов 60 всего Java-кода приходилось именно на JSP.
Сложно сделать взаимодействие между портлетами (формами на странице).
Приличное количество багов в самой платформе. Сам находил 2 или 3 критичных для клиента бага, которые, объективности ради, были пофикшены в патчах, но поставить новый патч - огромное количество бюрократии, поэтому у клиента был собственный "форк" некоторых файлов фреймворка, которые подгружались вместо оригинальных при запуске сервера.
Очень долгая компиляция и запуск.
Надеюсь больше никогда не придётся к нему прикасаться. В одно время даже подумывал убрать все упоминания этого фреймворка из резюме.
Для проверки уровня знаний использовали тесты от Ethuware. И так как проходили сертификацию за счет работодателя, условием допуска к экзамену было набрать минимум 70% на полном тесте от Ethuware (там есть тесты по отдельным разделам, и несколько тестов, которые покрывают все разделы, как на самой сертификации).
Я прошел пару тестов по отдельным разделам, прочитал 2 или 3 главы из книги Mala Gupta, прошел один полный тест, набрал что-то в районе 70-72%, прочитал комментарии к вопросам, на которые ответил неправильно и меня допустили проходить сертификацию.
Могу сказать, что вопросы в тестах от Ethuware хоть и похожи на вопросы из реального экзамена, но они немного сложнее. Поэтому 70% в этих тестах — это практически гарантированно 75%, а то и выше, на реальном экзамене.
Времени на прохождение всех вопросов хватило практически в притык, в конце осталась буквально пара минут, что бы проверить вопросы, в которых я сомневался, поэтому если вы не уверены в ответе на какой-то вопрос, то лучше не сидите над ним, а поставьте наиболее вероятный на ваш взгляд ответ, пометьте себе этот вопрос, и двигайтесь дальше. Если останется время, то в конце вернетесь что бы еще подумать над ответом.
На саму сертификацию ездили впятером с коллегами, результаты были известны уже через 10-15 минут после экзамена. Все пять человек набрали 88-95%.
Сейчас занят подготовкой с OCP 7, так как 2018 — последний год, когда можно сдать этот экзамен. Если в этом году не успею, то в следующий раз опять придется начинать с OCA. А если успею, то потом можно будет пройти апгрейд-сертификацию — что-то вроде облегченного экзамена на OCP 8.