Не бывает. Ее невозможно измерить средствами современных ЭВМ, поэтому в ЭВМ этих секунд нет. Просто в какой-то момент можно зафиксировать, что время системы отличается от координированного времени на секунду. А почему это произошло, из-за обыкновенной погрешности или из-за координации, невозможно. А то, что нельзя измерить, тем можно пренебречь.
Программы, которые падают от незначительной корректировки системных часов по NTP просто неправильно написаны. Для таких целей, где важно не зависеть от перевода часов, есть специальные средства, основанные на монотомном счетчике. Этот счетчик не показывает дату, не показывает часы, он просто отсчитывает периоды. Вот его и надо использовать в таких программах, где важна последовательность событий с точностью до секунды.
Я знаю, что мне нужно в такси. Вот сейчас еду и понимаю. Нужна возможность кастомизации музыкальных предпочтений.
Заранее забиваешь настройку, что бы ты хотел слышать во время поездки, и водителю приложение заранее сообщает: «Пассажир хочет ехать в тишине» — или: «Пассажир предпочитает шансон»
Можно вообще профиль такси объединить с Яндекс.музыкой.
У этих динозавров есть то, чего нет у Яндекса, — машины, которыми они распоряжаются. Диспетчер таксопарка дает водителю задание ехать туда-то к такому-то времени, и с вероятностью 99% водитель это задание выполнит. А Яндекс публикует кота в мешке: "Эй, есть заказ неизвестно куда. Кто желает взять?" — и ждет, когда кто-то откликнется. Естественно, никакие долгосрочные прогнозы в такой модели невозможны.
Для такой опции нужен резерв из машин, чтобы, если основная машина не смогла подъехать в указанное время к указанному месту, автоматически направлялась дежурная машина из резерва.
И тут мы плавно подходим к тому, что проблему надо решать не программно, а организационно, т. е. выходить из зоны комфорта, заключать договора с водителями и таксопарками и нести по ним ответственность.
Ну уж нет. Пусть лучше пассажиры в экран по полчаса тыкают.
Он не может адекватно представлять интересы нанимателя, потому что они конфликтуют с его собственными.
Предположим, увольнение программиста действительно в интересах собственника, в том контексте, который был представлен менеджеру. Программист может переслать это письмо собственнику, сопроводив своими комментариями, может после увольнения подать в суд и представить это письмо в качестве доказательства, что его вынудили уйти из-за того, что IT-директор хотел перевести его к себе в компанию. Таким образом выполнение мероприятий в интересах собственника будет поставлено под угрозу, а принимаемые им решения будут дискредитированы.
Именно поэтому конфликты интересов следует устранять. Даже если ты такой весь из себя честный и благородный и думаешь только о благе последнего своего клиента, но чтобы твоим консультациям доверяли, они должны соответствовать определенным стандартам. Данное письмо эти стандарты нарушает. Уровень доверия к предложениям менеджера после этого письма равен 0.
Конфликт интересов может быть даже у эксперта, не принимающего решения. Основной механизм устранения конфликта — уведомление нанимателя о возможном конфликте интересов.
А чтобы работник потом не строил из себя дурачка, прикрываясь тем, что он не знал или хотел как лучше, соответствующие пункты включают в контракт и проводят специальное обучение. В данном случае обучение не требовалось, поскольку персонаж имеет диплом, который подтверждает, что его владелец всему уже обучен.
Пункты в контракте нужны для того, чтобы менеджера мог вздрючить собственник. А для того, чтобы с этим менеджером больше никто не имел дела, достаточно того, что мы прочитали в его письме.
Конфликт интересов — это юридически определенная вещь. Если собственник в контракте предусмотрел обязанность менеджера не допускать конфликта интересов, то теоретически менеджер может даже присесть. И диплом здесь является ключевым фактором, так как менеджер осознавал, что он делает и какие будут последствия.
У него своя компания. Уволенного по его рекомендации он позвал работать туда. Это классический конфликт интересов. Интересы работодателя конфликтуют с интересами личного бизнеса.
7.8) В методах, принимающих в качестве параметра дженерики, желательно указывать не конкретный тип, а границы (wildcard bounds), чтобы можно было сделать вот так:
Не нужно. После первой итерации получится, что последний элемент уже сравнивали со всеми остальными, и он стоит на своем месте. Поэтому каждый следующий внутренний цикл должен быть на 1 итерацию короче предыдущего.
Я, например, вижу поехавшие отступы. Такое бывает, когда у автора табуляции в IDE занимают 4 пробела, а там, куда код вставили, — 8. Хорошая иллюстрация того, почему табуляции в коде использовать нельзя.
После ключевых слов перед круглой скобкой принято ставить пробел, чтобы отличать управляющую конструкцию языка от вызова функции.
После закрывающей круглой скобки перед открывающей фигурной скобкой нужен пробел.
Имя final-поля большими буквами нарушает правила именования. Большими буквами обозначаются константы, значение которых никогда не меняется. А final-поле у каждого экземпляра может иметь различные значения.
Runnable — функциональный интерфейс. Начиная, с 8-й явы его не надо анонимным классом реализовывать. Вместо этого надо лямбду создавать.
В иммутабельном классе Vector поля надо было сделать final.
Вместо compute() для модификации объектов в Map в методе inverse() лучше подойдет computeIfAbsent().
Стримы вообще не представлены никак. А это уже 5 лет как ключевое API.
Вот как выворачивание map выглядит на 10-й яве.
Однопоточный вариант
<K, V> Map<V, Collection<K>> inverseSequential(Map<K, V> map) {
return map.entrySet().stream().collect(
HashMap::new,
(result, entry) -> {
var value = result.computeIfAbsent(entry.getValue(), k -> new ArrayList<>());
value.add(entry.getKey());
},
(a, b) -> { throw new UnsupportedOperationException(); }
);
}
Многопоточный вариант
<K, V> Map<V, Collection<K>> inverseParallel(Map<K, V> map) {
return map.entrySet().parallelStream().collect(
HashMap::new,
(result, entry) -> {
var value = result.computeIfAbsent(entry.getValue(), k -> new ArrayList<>());
value.add(entry.getKey());
},
(map1, map2) -> {
map2.entrySet().forEach(
entry -> {
var value = map1.computeIfAbsent(entry.getKey(), k -> new ArrayList<>());
value.addAll(entry.getValue());
}
);
}
);
}
Про устаревшие API уже выше сказали. На мой взгляд, код, использующий устаревшее API, нельзя назвать красивым.
Не бывает. Ее невозможно измерить средствами современных ЭВМ, поэтому в ЭВМ этих секунд нет. Просто в какой-то момент можно зафиксировать, что время системы отличается от координированного времени на секунду. А почему это произошло, из-за обыкновенной погрешности или из-за координации, невозможно. А то, что нельзя измерить, тем можно пренебречь.
Программы, которые падают от незначительной корректировки системных часов по NTP просто неправильно написаны. Для таких целей, где важно не зависеть от перевода часов, есть специальные средства, основанные на монотомном счетчике. Этот счетчик не показывает дату, не показывает часы, он просто отсчитывает периоды. Вот его и надо использовать в таких программах, где важна последовательность событий с точностью до секунды.
Я знаю, что мне нужно в такси. Вот сейчас еду и понимаю. Нужна возможность кастомизации музыкальных предпочтений.
Заранее забиваешь настройку, что бы ты хотел слышать во время поездки, и водителю приложение заранее сообщает: «Пассажир хочет ехать в тишине» — или: «Пассажир предпочитает шансон»
Можно вообще профиль такси объединить с Яндекс.музыкой.
Выгодно-невыгодно это все субъективно и ситуативно, а пассажиру нужна гарантия.
Если робот плохо выполняет свою работу, то за ним ухаживают, меняют ему запчасти, заправляют расходниками, снижают нагрузку, а людей лишают премии.
У этих динозавров есть то, чего нет у Яндекса, — машины, которыми они распоряжаются. Диспетчер таксопарка дает водителю задание ехать туда-то к такому-то времени, и с вероятностью 99% водитель это задание выполнит. А Яндекс публикует кота в мешке: "Эй, есть заказ неизвестно куда. Кто желает взять?" — и ждет, когда кто-то откликнется. Естественно, никакие долгосрочные прогнозы в такой модели невозможны.
Для такой опции нужен резерв из машин, чтобы, если основная машина не смогла подъехать в указанное время к указанному месту, автоматически направлялась дежурная машина из резерва.
И тут мы плавно подходим к тому, что проблему надо решать не программно, а организационно, т. е. выходить из зоны комфорта, заключать договора с водителями и таксопарками и нести по ним ответственность.
Ну уж нет. Пусть лучше пассажиры в экран по полчаса тыкают.
Он не может адекватно представлять интересы нанимателя, потому что они конфликтуют с его собственными.
Предположим, увольнение программиста действительно в интересах собственника, в том контексте, который был представлен менеджеру. Программист может переслать это письмо собственнику, сопроводив своими комментариями, может после увольнения подать в суд и представить это письмо в качестве доказательства, что его вынудили уйти из-за того, что IT-директор хотел перевести его к себе в компанию. Таким образом выполнение мероприятий в интересах собственника будет поставлено под угрозу, а принимаемые им решения будут дискредитированы.
Именно поэтому конфликты интересов следует устранять. Даже если ты такой весь из себя честный и благородный и думаешь только о благе последнего своего клиента, но чтобы твоим консультациям доверяли, они должны соответствовать определенным стандартам. Данное письмо эти стандарты нарушает. Уровень доверия к предложениям менеджера после этого письма равен 0.
Этот текст вообще никакой смысловой нагрузки не несет. Есть факты.
Остальное — лирика.
Со стримами и лямбдами многое иначе выглядит.
Конфликт интересов может быть даже у эксперта, не принимающего решения. Основной механизм устранения конфликта — уведомление нанимателя о возможном конфликте интересов.
А чтобы работник потом не строил из себя дурачка, прикрываясь тем, что он не знал или хотел как лучше, соответствующие пункты включают в контракт и проводят специальное обучение. В данном случае обучение не требовалось, поскольку персонаж имеет диплом, который подтверждает, что его владелец всему уже обучен.
Пункты в контракте нужны для того, чтобы менеджера мог вздрючить собственник. А для того, чтобы с этим менеджером больше никто не имел дела, достаточно того, что мы прочитали в его письме.
Конфликт интересов — это юридически определенная вещь. Если собственник в контракте предусмотрел обязанность менеджера не допускать конфликта интересов, то теоретически менеджер может даже присесть. И диплом здесь является ключевым фактором, так как менеджер осознавал, что он делает и какие будут последствия.
У него своя компания. Уволенного по его рекомендации он позвал работать туда. Это классический конфликт интересов. Интересы работодателя конфликтуют с интересами личного бизнеса.
7.8) В методах, принимающих в качестве параметра дженерики, желательно указывать не конкретный тип, а границы (wildcard bounds), чтобы можно было сделать вот так:
P. S. Сам так очень редко делаю, но для методических материалов все должно быть четко.
Итого в сухом остатке. Эффектный менеджер с дипломом MBA уволил одного из самых компетентных сотрудников из-за своего конфликта интересов.
После ключевых слов перед круглой скобкой принято ставить пробел, чтобы отличать управляющую конструкцию языка от вызова функции.
После закрывающей круглой скобки перед открывающей фигурной скобкой нужен пробел.
Имя final-поля большими буквами нарушает правила именования. Большими буквами обозначаются константы, значение которых никогда не меняется. А final-поле у каждого экземпляра может иметь различные значения.
Runnable — функциональный интерфейс. Начиная, с 8-й явы его не надо анонимным классом реализовывать. Вместо этого надо лямбду создавать.
В иммутабельном классе Vector поля надо было сделать final.
Вместо compute() для модификации объектов в Map в методе inverse() лучше подойдет computeIfAbsent().
Стримы вообще не представлены никак. А это уже 5 лет как ключевое API.
Вот как выворачивание map выглядит на 10-й яве.
Про устаревшие API уже выше сказали. На мой взгляд, код, использующий устаревшее API, нельзя назвать красивым.