Kickstarter захвачен маркетологами. Приходят с готовым продуктом, но заявляют цель, например, 50К. На что пойдут эти деньги? Это даже не месяц работы команды. Затем, за счет скидок собирают заказов на миллион. Нашли потребителя, выпустили партию, молодцы! Но говориить о какой-то суперуспешности проекта, когда собрали в 20 раз больше, чем просили непонятно на что, смешно.
На маке файловая система (HFS+) использует decomposed unicode, на форточках (например NTFS) — composed. (А на линуксе — как повезет, можно получить обе сразу).
Иногда получаются проблемы — архивы, синхронизация файлов, вот это все. В svn с этим долго боролись в свое время.
То, что вы описали, это 1мс импульс мощностью 1кВт * 30 * 1000 = 30 МВт. Если такие импульсы выдавать раз в секунду, то средняя мощность будет та же, что и у луча, который непрерывно отдаёт 30 кВт.
В каком именно режиме работает тот лазер, не написано.
Не знаю, много ли пользы от подобных статей. Если вдруг понадобятся описанные методы, единственное, до чего нужно допереть — это до того, что нужно искать в окрестностях TreeSet. Или Arrays.sort() / Collections.sort(). Дальше все написано в документации.
А вот что делать не стоит:
— писать Car.compareTo() на основе пробега — это неестественно. Если очень хочется сделать именно Set, то лучше сделать отдельный компаратор, и передать его в TreeSet. А сам метод Car.compareTo()реализовать на основе других полей вообще не нужен. И да, equals() забыли дописать тогда тоже не нужен.
— вообще, там Set не подходит — будут пропадать машины с одинаковым пробегом. Так что список (или массив), заполнить и отсортировать.
Дополнительный вопрос: что будет, если после добавления всех машин в Set в примере выше вызвать car1.setMileage(20000)?
Только по-хорошему, нужно допиливать браузеры, чтоб в режиме инкогнито все настройки отдавались одинаково — «user-agent=mozilla», и все. Установленные шрифты, флэш, java, ОС, размер экрана — не отдавать, либо отдать какую-нибудь стандартную конфигурацию.
1) в исходниках в файле plugins/ldapbrowser.common/plugin.xml поменять «M1++» на «M1+Numpad_Add», и «M1+M2++» на «M1+M2+Numpad_Add» (в нескольких местах); потом пересобрать.
2) либо пинать разработчиков, чтобы они это сделали;
3) если есть возможность поменять хоткей в настройках студии — поменять там.
Забавный хоткей. "+" вводится через «shift+=», т.е. без шифта не получится. Возможно, апачи имели в виду плюс на нумпаде, а в конфиге прописали именно плюс («M1++» и «M1+M2++»).
Глядя на мир, нельзя не удивляться!
Вообще, мерзкий баг, надеюсь всё-таки зафикшен, даже если только через патч JRE.
Иногда получаются проблемы — архивы, синхронизация файлов, вот это все. В svn с этим долго боролись в свое время.
В каком именно режиме работает тот лазер, не написано.
А вот что делать не стоит:
— писать Car.compareTo() на основе пробега — это неестественно. Если очень хочется сделать именно Set, то лучше сделать отдельный компаратор, и передать его в TreeSet. А сам метод Car.compareTo()
реализовать на основе других полейвообще не нужен. И да, equals()забыли дописатьтогда тоже не нужен.— вообще, там Set не подходит — будут пропадать машины с одинаковым пробегом. Так что список (или массив), заполнить и отсортировать.
Дополнительный вопрос: что будет, если после добавления всех машин в Set в примере выше вызвать car1.setMileage(20000)?
issues.apache.org/jira/browse/DIRSTUDIO-825
Можете исправить:
2) либо пинать разработчиков, чтобы они это сделали;
3) если есть возможность поменять хоткей в настройках студии — поменять там.