Меня это сразу насторожило. На данный момент идея выглядит не плохо, но пройдет какое-то время и понятие социальной рекламы скорее всего расширится в политическую сторону.
"Восьмое число после запятой в числе пи назовете по памяти?" - если вы работаете в области, где вам регулярно нужно самому проводить вычисления с числом Пи с точностью не менее 8 знаков после запятой, то вы будете знать число Пи с такой точностью. При этом вам совершенно не надо будет зубрить его. Вы его сами запомните просто по той причине, что постоянно используете. И все.
Я согласен с тем, что не нужно специально зубрить базовые вещи. В этом нет смысла. Они у вас сами выучатся входе практики. Но мне странно слышать, что вещи, которые вы используете чуть ли не каждый день, у вас так и не получилось запомнить.
"Вопросы могут быть такими: - назовите все примитивные типы в Java, сколько каждый тип занимает памяти, если не помнишь, то посчитай; - какие методы класса Object, стандартный вопрос (многие задают), но в данном случае нужно назвать все до одного, т.к. собеседующий реально за это запаривается и сидит считает."
Так это же простые вопросы. При этом есть немало практических задач, где знание этих вещей необходимо.
Не меньше 80% разработчиков не напишут корректно даже элементарного метода Гаусса с первой попытки.
Надо заметить, что корректная реализация метода Гаусса с учетом всех нюансов - задача не такая уж и простая. На бумаге он, конечно, элементарен. Но это на бумаге.
Мне кажется, что один лишь факт использования репозитория доменом не указывает на нарушение изоляции доменного слоя, т.к. паттерн репозиторий по задумке представляет инверсию зависимостей между слоем домена и слоем доступа к данным. Главное - чтобы все методы репозитория и их сигнатуры определялись исходя исключительно из потребностей домена и выражались через его (домена) терминологию.
Раз речь зашла о вероятностях, то собственно вопрос отпадает. Просто категоричный тон заявления "закономерности окружающего мира неизменны и не зависят от того, что мы они них знаем" заставляет думать, что эту вероятность вы полагаете равной единице.
Коллеги не всегда с ними соглашались, однако я не сдавался и настаивал на изменениях, потому что был на сто процентов уверен, что для проекта так будет лучше.
Точно лучше? Уверенность в своей правоте — не аргумент. Нужно уметь аргументировать свою позицию.
Порой споры принимали ожесточенный характер
Ожесточенные споры начинаются в тех случаях, где своим приоритетом вы ставите выплескивание накопившегося стресса на коллегу, а не получение положительных результатов в командной работе.
Свою позицию можно и нужно излагать четко и прямо. А для того чтобы к ней прислушивались, достаточно не переходить на личности и хотя бы немного постараться учесть сторону собеседника.
По канону, имхо, приложение JavaFX собирается не в JAR, а в установочный файл конкретной платформы. С Java SE 16 вы можете использовать JLink и JPackage для этих целей (JPackage при сборке под винду требует Wix 3).
В logback есть похожая уязвимость? Кто-нибудь проверял?
Меня это сразу насторожило. На данный момент идея выглядит не плохо, но пройдет какое-то время и понятие социальной рекламы скорее всего расширится в политическую сторону.
"Восьмое число после запятой в числе пи назовете по памяти?" - если вы работаете в области, где вам регулярно нужно самому проводить вычисления с числом Пи с точностью не менее 8 знаков после запятой, то вы будете знать число Пи с такой точностью. При этом вам совершенно не надо будет зубрить его. Вы его сами запомните просто по той причине, что постоянно используете. И все.
Я согласен с тем, что не нужно специально зубрить базовые вещи. В этом нет смысла. Они у вас сами выучатся входе практики. Но мне странно слышать, что вещи, которые вы используете чуть ли не каждый день, у вас так и не получилось запомнить.
"Вопросы могут быть такими: - назовите все примитивные типы в Java, сколько каждый тип занимает памяти, если не помнишь, то посчитай; - какие методы класса Object, стандартный вопрос (многие задают), но в данном случае нужно назвать все до одного, т.к. собеседующий реально за это запаривается и сидит считает."
Так это же простые вопросы. При этом есть немало практических задач, где знание этих вещей необходимо.
Если уж выполнять разминку для ума, то лучше на такой задачке - как минимизировать давление на голосующего при открытом голосовании.
Согласен. Хотелось бы больше подробностей о разграничении доступа к данным в этом проекте.
Так в статье речь идет про конкретный дистрибутив - Ubuntu. Или я что-то путаю?
Если не будет этой возможности, то как тогда проверить подлинность голосов?
Возможно вопрос наивный, но что если в базе хранить не сами ID, а их хеши?
Надо заметить, что корректная реализация метода Гаусса с учетом всех нюансов - задача не такая уж и простая. На бумаге он, конечно, элементарен. Но это на бумаге.
Мне кажется, что один лишь факт использования репозитория доменом не указывает на нарушение изоляции доменного слоя, т.к. паттерн репозиторий по задумке представляет инверсию зависимостей между слоем домена и слоем доступа к данным. Главное - чтобы все методы репозитория и их сигнатуры определялись исходя исключительно из потребностей домена и выражались через его (домена) терминологию.
Т.е. вы пришли к процедурному программированию?
Раз речь зашла о вероятностях, то собственно вопрос отпадает. Просто категоричный тон заявления "закономерности окружающего мира неизменны и не зависят от того, что мы они них знаем" заставляет думать, что эту вероятность вы полагаете равной единице.
"закономерности окружающего мира неизменны" - это вообще говоря возможно строго доказать? (Т.е. не используя неполную индукцию)
Точно лучше? Уверенность в своей правоте — не аргумент. Нужно уметь аргументировать свою позицию.
Ожесточенные споры начинаются в тех случаях, где своим приоритетом вы ставите выплескивание накопившегося стресса на коллегу, а не получение положительных результатов в командной работе.
Свою позицию можно и нужно излагать четко и прямо. А для того чтобы к ней прислушивались, достаточно не переходить на личности и хотя бы немного постараться учесть сторону собеседника.