12:20 вывод в консоли, кстати, показательный момент почему метод stop не надо применять. Видим, что запрос ушел, а ответ не пришел, т.к. работа сервера была остановлена. Пользователю остается только гадать - дошли данные или нет. Меня звук клавиатуры не отвлекает. Наоборот, придает чувство участия в процессе. Можно чуть приглушить - да, но убирать, на мой взгляд, не стоит. Спасибо за ролик 👍
зачем ты всё время выносишь всё в константы что касается времени? то есть это же неудобно каждый раз листать в вверх и смотреть какое там было время присвоено константе, тем более у нас TimeUnit уже показывает в секундах, получается это просто лишнее поле. И второй вопрос, зачем ты пишешь в catch(final) ?
Большое спасибо за активность на канале!) Про final уже писали, поэтому я продублирую: Здравствуйте, к текущему моменту у меня просто такой стиль написания кода. Я не претендую на его правильность: с одной стороны с final получается больше кода, что усложняет его чтения - с другой стороны с final сразу можно увидеть, не читая дальнейший код, будет ли данная переменная изменяться или нет, что бывает особенно полезно в больших методах. Блок catch не является исключением) В последних видео я решил отказаться от определения статических констант, т.к. большая часть зрителей нашли это не совсем удобным)
Вопрос. Если было вызвано исключение InterruptedException(), то зачем проверять, если оно было вызвано в результате interrupt()? Можно же не вызывать столько методов.
Большое спасибо за комментарий!) После первого вызова метода interrupt в прерванном потоке будет выброшено исключение InterruptedException, т.к. он был прерван в течение работы метода sleep. Поле interrupted класса Thread останется равным false. Поэтому если мы не вызовем метод interrupt второй раз, отловив исключение InterruptedException, то у нас не будет возможности потом проверить по какой причине поток закончил свою работу: он нормально завершил свою работу или был прерван. Очень рад, если ответил, но мог неправильно понять вопрос)
Спасибо за видео! У нас два раза вызывается interrupt. Я правильно понимаю, что при проверке if (Thread.interrupted() - тут флаг прерывания сбрасывается на false ) { Thread.currentThread().interrupt() - тут флаг прерывания заново устанавливается на true и поэтому мы понимаем, что поток был прерван?
Большое спасибо за комментарий!) Я не увидел вызова метода interrupted в видео) Здесь логика следующая: после первого вызова метода interrupt в прерванном потоке будет выброшено исключение InterruptedException, т.к. он был прерван в течение работы метода sleep. Поле interrupted класса Thread останется равным false. Поэтому если мы не вызовем метод interrupt второй раз, отловив исключение InterruptedException, то у нас не будет возможности потом проверить по какой причине поток закончил свою работу: он нормально завершил свою работу или был прерван. Надеюсь, что ответил)
Спасибо за активность на канале!) Если мы вызываем метод interrupt, и блок catch, который отлавливает InterruptedException, находится внутри цикла, то нет
и можете подсказать, вы всегда как то так делаете, что у вас допустим в String.out.print(") пропадает String, это вы делаете для себя, или хороший тон в промышленном программировании ?
Статический импорт можно применять для импорта статических членов класса или интерфейса. Благодаря статическому импорту появляется возможность ссылаться на статические члены непосредственно по именам, не уточняя класса. Это упрощает и сокращает синтаксис, требующийся для работы со статическими членами. Очень заметна польза от статического импорта в написании каких-нибудь математических формул в коде. Например, sqrt(pow(a, 2), pow(b, 2)), читается намного проще, чем Math.sqrt(Math.pow(a, 2), Math.pow(b, 2))
В коде с видео это скорее всего плохо видно из-за плохого выбора имен переменных, но в общем случае константы могут улучшить читаемость) MINUTES_PER_DAY понятнее, чем 1440
Вообще это хорошая практика, если переменная используется в нескольких местах. Когда приходится менять код, тебе придется поменять значение только в одном месте, страхуя себя, что ты нигде ничего не забыл.
вопрос к 5:45 если надо заснуть условно на 3 часа 33 минуты 33 секунды прописывать придется черещ секунды? спасибо кстати за видео, очень помогает готовиться к лабораторной в вузе по java
Здравствуйте, о других способах мне неизвестно) Для большей читаемости я бы рекомендовал писать как-то так: SECONDS.sleep(3 * 3600 + 3 * 60 + 3), где 3 * 3600 - 3 часа, 3 * 60 - 3 минуты. Читается это лучше, чем эквивалентный SECONDS.sleep(10983)
Большое спасибо! Безумно рад!) В планах есть, но эту тему, как мне кажется, лучше рассматривать после рассмотрения потокобезопасных коллекций и исполнителей, а этих тем, к сожалению, пока не рассматривалось)
Здравствуйте, не очень понял, почему параметры метода и так final) возможно же присвоить параметру метода новое значение внутри тела этого метода. Да, это не отразится на аргументе метода, но все же) в следующих видео постараюсь избавить от лишних шумов)
Уже писали об этом, поэтому я продублирую) Здравствуйте, к текущему моменту у меня просто такой стиль написания кода. Я не претендую на его правильность: с одной стороны с final получается больше кода, что усложняет его чтения - с другой стороны с final сразу можно увидеть, не читая дальнейший код, будет ли данная переменная изменяться или нет, что бывает особенно полезно в больших методах.
12:20 вывод в консоли, кстати, показательный момент почему метод stop не надо применять. Видим, что запрос ушел, а ответ не пришел, т.к. работа сервера была остановлена. Пользователю остается только гадать - дошли данные или нет.
Меня звук клавиатуры не отвлекает. Наоборот, придает чувство участия в процессе. Можно чуть приглушить - да, но убирать, на мой взгляд, не стоит.
Спасибо за ролик 👍
Снова большое спасибо за активность!) Где-то начиная с 20-х видео начал снимать с микрофоном - звук должен быть получше)
Здравствуйте, а в настоящих проектах разного рода сообщения, постоянные числовые значения и т.д тоже выносят в final переменные на уровень класса?
Здравствуйте, желательно выносить, только именовав их раза в 2 короче, чем в видео)
@@vladzuev10 Ахах, понял, спасибо)
Это что за прикол на 2.47? Я думал у меня телефон сдох
Ахах, ну извините) я думаю там не один такой косяк, так что в следующий раз не пугайтесь)
зачем ты всё время выносишь всё в константы что касается времени? то есть это же неудобно каждый раз листать в вверх и смотреть какое там было время присвоено константе, тем более у нас TimeUnit уже показывает в секундах, получается это просто лишнее поле. И второй вопрос, зачем ты пишешь в catch(final) ?
Большое спасибо за активность на канале!) Про final уже писали, поэтому я продублирую:
Здравствуйте, к текущему моменту у меня просто такой стиль написания кода. Я не претендую на его правильность: с одной стороны с final получается больше кода, что усложняет его чтения - с другой стороны с final сразу можно увидеть, не читая дальнейший код, будет ли данная переменная изменяться или нет, что бывает особенно полезно в больших методах.
Блок catch не является исключением)
В последних видео я решил отказаться от определения статических констант, т.к. большая часть зрителей нашли это не совсем удобным)
Вопрос. Если было вызвано исключение InterruptedException(), то зачем проверять, если оно было вызвано в результате interrupt()? Можно же не вызывать столько методов.
Большое спасибо за комментарий!) После первого вызова метода interrupt в прерванном потоке будет выброшено исключение InterruptedException, т.к. он был прерван в течение работы метода sleep. Поле interrupted класса Thread останется равным false. Поэтому если мы не вызовем метод interrupt второй раз, отловив исключение InterruptedException, то у нас не будет возможности потом проверить по какой причине поток закончил свою работу: он нормально завершил свою работу или был прерван. Очень рад, если ответил, но мог неправильно понять вопрос)
@@vladzuev10 спасибо за информацию.
Спасибо за видео! У нас два раза вызывается interrupt. Я правильно понимаю, что при проверке
if (Thread.interrupted() - тут флаг прерывания сбрасывается на false ) {
Thread.currentThread().interrupt() - тут флаг прерывания заново устанавливается на true и поэтому мы понимаем, что поток был прерван?
Большое спасибо за комментарий!) Я не увидел вызова метода interrupted в видео) Здесь логика следующая: после первого вызова метода interrupt в прерванном потоке будет выброшено исключение InterruptedException, т.к. он был прерван в течение работы метода sleep. Поле interrupted класса Thread останется равным false. Поэтому если мы не вызовем метод interrupt второй раз, отловив исключение InterruptedException, то у нас не будет возможности потом проверить по какой причине поток закончил свою работу: он нормально завершил свою работу или был прерван. Надеюсь, что ответил)
@@vladzuev10 спасибо🙏
Я, честно говоря, ожидал, что даже несмотря на while (true) цикл будет прерван, т.к было прервано само исполнение потока.
Спасибо за активность на канале!) Если мы вызываем метод interrupt, и блок catch, который отлавливает InterruptedException, находится внутри цикла, то нет
и можете подсказать, вы всегда как то так делаете, что у вас допустим в String.out.print(") пропадает String, это вы делаете для себя, или хороший тон в промышленном программировании ?
Статический импорт можно применять для импорта статических членов класса или интерфейса. Благодаря статическому импорту появляется возможность ссылаться на статические члены непосредственно по именам, не уточняя класса. Это упрощает и сокращает синтаксис, требующийся для работы со статическими членами. Очень заметна польза от статического импорта в написании каких-нибудь математических формул в коде. Например, sqrt(pow(a, 2), pow(b, 2)), читается намного проще, чем Math.sqrt(Math.pow(a, 2), Math.pow(b, 2))
Может System.out.print();?
Пропиши статичный импорт нужной функции:
import static java.lang.System.out;
И потом можно писать проще:
out.print("...");
Зачем все сообщения и значения выводить в константу? В чем прикладной смысл? Для читаемости кода или как-то влияет на работоспособность?
В коде с видео это скорее всего плохо видно из-за плохого выбора имен переменных, но в общем случае константы могут улучшить читаемость) MINUTES_PER_DAY понятнее, чем 1440
Вообще это хорошая практика, если переменная используется в нескольких местах. Когда приходится менять код, тебе придется поменять значение только в одном месте, страхуя себя, что ты нигде ничего не забыл.
вопрос к 5:45 если надо заснуть условно на 3 часа 33 минуты 33 секунды прописывать придется черещ секунды?
спасибо кстати за видео, очень помогает готовиться к лабораторной в вузе по java
Здравствуйте, о других способах мне неизвестно) Для большей читаемости я бы рекомендовал писать как-то так: SECONDS.sleep(3 * 3600 + 3 * 60 + 3), где 3 * 3600 - 3 часа, 3 * 60 - 3 минуты. Читается это лучше, чем эквивалентный SECONDS.sleep(10983)
Мне кажется, можно последовательно вызвать несколько слипов - на дни, минуты, секунды
Подскажите, я правильно понимаю, если мы прописываем TimeUnit.SECONDS.sleep(5) в методе main, то мы усыпляем именно поток main?
Да, верно. Метод sleep усыпляет текущий поток, а метод main выполняется главным потоком
Как всгда хорошее объеснее и наглядное.
Есть небольшое пожелание к тебе, скорее большее )), хотелось бы от тебя увидеть разбор про CompletableFuture
Большое спасибо! Безумно рад!) В планах есть, но эту тему, как мне кажется, лучше рассматривать после рассмотрения потокобезопасных коллекций и исполнителей, а этих тем, к сожалению, пока не рассматривалось)
@@vladzuev10 о круто 🙌
2:46 💀💀💀
😄😄😄
Зачем final перед параметрами в методе ? Параметры в методе и так final :) Грохот клавы еще тот
Здравствуйте, не очень понял, почему параметры метода и так final) возможно же присвоить параметру метода новое значение внутри тела этого метода. Да, это не отразится на аргументе метода, но все же) в следующих видео постараюсь избавить от лишних шумов)
В чем поинт делать все аргументы final? особенно интерсно насчёт final экспешена в catch`е.
Уже писали об этом, поэтому я продублирую)
Здравствуйте, к текущему моменту у меня просто такой стиль написания кода. Я не претендую на его правильность: с одной стороны с final получается больше кода, что усложняет его чтения - с другой стороны с final сразу можно увидеть, не читая дальнейший код, будет ли данная переменная изменяться или нет, что бывает особенно полезно в больших методах.
@@vladzuev10 в таком ключе делает смысл. Спасибо!)