Ездить для машины сложнее чем летать. В плане задачи автоматизации, для езды прям на старте появляется проблема ландшафта, от которой никак не избавиться. В полётах самолётов эта проблема обходится тем, что самолёт никогда не приближается к возможным препятствиям (если не брать в расчет полёты СЛА в высокогорье).
Человек ориентироваться в ландшафте учится с малых лет, поэтому учиться на авто ему проще. А в полёте появляется задача навигации, которая требует постоянного внимания без прерывания полёта (остановиться тут нельзя), с такой нагрузкой комп лучше справляется.
Да что там люди, некоторые компании, формирующие списки "нехороших" адресов в сети, вполне успешно продают свои услуги по защите от попадания в эти списки таким способом.
Представьте себе человека, который в потёмках рассматривает едва различимую надпись. Зрачки расширены по максимуму, чтобы почувствовать минимальный поток света. И тут перед глазами вспыхивает киловаттный прожектор.
Так вот, радитракту wifi-модуля будет гораздо хуже, тупо сгорит в первую секунду.
Неподдерживаемые параметры появляются двумя путями: софт запускается под разными версиями java (и авторы не стали писать определение версии в скрипте запуска, прописали параметры под обе версии), или настроили запуск под одной версией затем обновили java.
Что касается одинаковых -Xms и -Xmx, для сервера вопрос стабильности. Есть виртуалка с 10гб оперативки, запускать под ней надо только одно java-приложение, работающее 24/7, выделили 8гб на java heap, 2гб на остальные нужды. Какой смысл ставить минимум меньше 8гб? Разве что под системные буферы использовать, но если прилетит пиковая нагрузка, то уменьшившийся размер буфера может оказаться не кстати.
В статье близкий вариант описывался, его большой минус — при необходимости добавить значение в начало, надо все 11гб "подвинуть". В btree этого не требуется.
Менеджер паролей, который тянет за собой 12гб-ный файл (в будущем размер будет расти) или отправляет sha1-хеш (даже sha2 без соли отправлять — плохое решение) — сомнительные применения. Единственный практичный вариант — при регистрации на сайте этот сайт (на него пароль и так отправится) проверяет стойкость пароля. Но в этом случае правильнее использовать бд.
Когда-то работал с проектом, в котором пароли лежали без соли, сделали проверку стойкости паролей тупо по частоте появления хеша, правда очень быстро функцию пришлось отключить — у заказчиков фантазии для придумывания редких паролей (среди бд на пару млн. пользователей) не хватало.
Вот только, вероятно, размер номера X будет больше размера текста Y, а время, которое потребуется на поиск X может оказаться большим чем срок действия авторских прав.
Обновление настроек может быть лень полезно для критичных сервисов, которые нельзя останавливать ради временного изменения уровня логгирования (скажем, в целом система работает хорошо, но какая-то из функций отрабатывает странно, иногда может быть полезно в одним из классов включить trace. Некоторые библиотеки позволяют изменять свои параметры даже через mbean-ы, что оказывается иногда полезно (и не требует доступа к конфиг-файлам).
Не нашел в документации (мб. плохо искал):
Есть ли возможность указать, откуда следует читать конфиг-файл (мы конфиги держим отдельно от веб-приложений, так удобнее ими управлять)?
Есть ли возможность перезагрузки конфигов при необходимости?
Есть ли интерфейс конфигурирования кодом?
(Мысли вслух) Смена формата конфигов вместо расширения поддерживаемых форматов (пусть и с неполной функциональностью) может играть против распространения библиотеки для тех, у кого производительность не упёрлась в логгер (у нас в одном из приложений такое было с log4j, пока не воткнули asyncappender). У меня yml не зашёл, хотя и напоминает своей идеологией питон, всё-таки значащие пробелы в конфигурации (с которой работают не только разработчики) нельзя назвать однозначно хорошим решением. Для себя нашел идеальный вариант формата конфига — hocon, потихоньку перехожу на него с других форматах в своих проектах.
Где-то лет 5 назад, после перехода с svn на git, пытались работать через eclipse-плагин, тут же бросили, после коммитов в нём получались кривые диффы (как будто весь файл изменили). Возможно, связано с autocrlf, возможно даже исправили, но осадочек остался. Subclipse таким не болел. Используем готовый плагин исключительно в режиме просмотра.
Очень удобно, ничего не скажешь.
Писать так каждый раз не нужно, достаточно один раз написать статическую функцию-обёртку для кода, либо воспользоваться библиотекой, где это уже есть. В любом случае, для существующего проекта эти новые функции не принесут выгоды при переезде на java9+, так как наверняка уже в проекте есть решение проблем, которые решают такие методы.
Про takeWhile не писал, так как согласен что это killer-фича и её бэкпортирование нетривиально, однако, честно говоря, ни в одном из проектов, с которыми работал на java8, не встречал бесконечных стримов, а прерывание обработки стрима осуществлял посредством runtimeexception'а (в случае реальной ошибки) или просто делал filter с последующим взятием первой записи. Это, конечно, зависит от флагов стрима, но при однопоточной обработке и создании стримов из коллекций, новый элемент не получается до тех пор, пока предыдущий не прошел цепочку операций над стримами до момента отфильтровывания или другой операции, требующей получения следующего элемента (это наблюдение сделанное на основании последовательности срабатывания брейкпоинтов при отладке).
Что касается ProcessHandle и Cleaner, то первый нужен для специфических целей и его появление обязано расширению границ применения java вообще, а к последнему я отношусь как к обычной смене одного апи на другое (лично мне пришлось писать финализатор лишь единожды). Что касается гарантий закрытия у Closable, появление достаточно умных ide, которые теперь ругаются на отсутствие вызова close у Closable-объекта, делает данную защиту от забытого close менее острой чем раньше.
Где-то до 18го года использовал Dell 640m для периодической вёрстки кучи текста (он и до сих пор живой, а до 11-го — был основным компом), где-то с 15го искал нормальную замену — фиг там. На фоне идеальной клавиатуры в 640m, все другие варианты были издевательством. Тогда еще оставались модели с похожей клавиатурой, но Dell взял на вооружение говноидею избавления от клавиши Insert, продвинутую microsoft своей клавиатурой (после их клавиатуры пошла такая мода).
В итоге, когда в 18м году пришлось покупать ноут (не по причине проблем с 640m), пришел к решению ноутбук + портативный USB-C монитор + десктопная клавиатура. В этом случае требования к клавиатуре ноута становились более мягкими, но всё равно среди Dell-овских не нашел достойного варианта (возможно из-за ложной надежды найти что-нибудь близкое к 640m).
На сколько я помню, табличка с json-ами занимает чуть меньше чем табличка с jsonb (в частных случаях может быть наоборот), но при этом с jsonb больше возможностей и он работает быстрее.
В целом, для большинства применений jsonb выглядит выигрышнее hstore: асимптотика похожая, но для jsonb не нужны расширения, да и возможностей без конвертации в строку больше.
Аналог Arrays.asList() для Set не нужен, всегда можно передать результат Arrays.asList в конструктор HashSet. Чаще всего такая инициализация востребована в статических константах, а значит лишняя аллокация не имеет значения.
Что касается Map-а, в java8 использую комбинацию Stream.of с SimpleImmutableEntry (вот она замена Map.entry) и последующий collect в Map.
Да, вариант более многословный, но стандартные, уменьшающие громоздкость объявления констант заменяются нестандартными методами, так что на killer-фичу, заставляющую обновляться даже близко не подходит.
Кучка функций для замены commons-lang и подобных пакетов — это круто, но пока они появляются точечно, от сторонних пакетов отказаться не получится, а это заметно осложняет переход (зачем учить новое апи, если всё равно требуется использовать стороннюю библиотеку, в которой уже есть куча функций, которыми уже привык пользоваться). Конечно, появление этих функций в стандартной джаве — это круто, но почему это происходит так избирательно?
Что касается Predicate.not, в java8 есть Predicate.negate(), правда, он требует использования вспомогательной функции, либо явного каста, иначе компилятор не понимает, что это предикат (это, вроде, должны были починить в одной из более поздних версий). Да, Predicate.not — удобная штука, но на killer-фичу не тянет даже близко.
Хуже. Теперь компания-владелец такой программы будет защищать синтезы своих препаратов таким количеством схем, что альтернативы этим синтезам уже не найдёшь.
Есть такое понятие как пирамида Маслоу. Думаю, для большинства программистов участие в опенсорсе где-то ближе к верхушке. Активно контрибьютить можно, когда либо нет необходимости много работать (т.е., когда сидишь на работе с 9 до 18 и на жизнь хватает), либо когда это и есть работа. Но в постсоветском пространстве такое редкость.
Ездить для машины сложнее чем летать. В плане задачи автоматизации, для езды прям на старте появляется проблема ландшафта, от которой никак не избавиться. В полётах самолётов эта проблема обходится тем, что самолёт никогда не приближается к возможным препятствиям (если не брать в расчет полёты СЛА в высокогорье).
Человек ориентироваться в ландшафте учится с малых лет, поэтому учиться на авто ему проще. А в полёте появляется задача навигации, которая требует постоянного внимания без прерывания полёта (остановиться тут нельзя), с такой нагрузкой комп лучше справляется.
Да что там люди, некоторые компании, формирующие списки "нехороших" адресов в сети, вполне успешно продают свои услуги по защите от попадания в эти списки таким способом.
Представьте себе человека, который в потёмках рассматривает едва различимую надпись. Зрачки расширены по максимуму, чтобы почувствовать минимальный поток света. И тут перед глазами вспыхивает киловаттный прожектор.
Так вот, радитракту wifi-модуля будет гораздо хуже, тупо сгорит в первую секунду.
Неподдерживаемые параметры появляются двумя путями: софт запускается под разными версиями java (и авторы не стали писать определение версии в скрипте запуска, прописали параметры под обе версии), или настроили запуск под одной версией затем обновили java.
Что касается одинаковых -Xms и -Xmx, для сервера вопрос стабильности. Есть виртуалка с 10гб оперативки, запускать под ней надо только одно java-приложение, работающее 24/7, выделили 8гб на java heap, 2гб на остальные нужды. Какой смысл ставить минимум меньше 8гб? Разве что под системные буферы использовать, но если прилетит пиковая нагрузка, то уменьшившийся размер буфера может оказаться не кстати.
В статье близкий вариант описывался, его большой минус — при необходимости добавить значение в начало, надо все 11гб "подвинуть". В btree этого не требуется.
Менеджер паролей, который тянет за собой 12гб-ный файл (в будущем размер будет расти) или отправляет sha1-хеш (даже sha2 без соли отправлять — плохое решение) — сомнительные применения. Единственный практичный вариант — при регистрации на сайте этот сайт (на него пароль и так отправится) проверяет стойкость пароля. Но в этом случае правильнее использовать бд.
Когда-то работал с проектом, в котором пароли лежали без соли, сделали проверку стойкости паролей тупо по частоте появления хеша, правда очень быстро функцию пришлось отключить — у заказчиков фантазии для придумывания редких паролей (среди бд на пару млн. пользователей) не хватало.
Вот только, вероятно, размер номера X будет больше размера текста Y, а время, которое потребуется на поиск X может оказаться большим чем срок действия авторских прав.
Обновление настроек может быть лень полезно для критичных сервисов, которые нельзя останавливать ради временного изменения уровня логгирования (скажем, в целом система работает хорошо, но какая-то из функций отрабатывает странно, иногда может быть полезно в одним из классов включить trace. Некоторые библиотеки позволяют изменять свои параметры даже через mbean-ы, что оказывается иногда полезно (и не требует доступа к конфиг-файлам).
Не нашел в документации (мб. плохо искал):
Есть ли возможность указать, откуда следует читать конфиг-файл (мы конфиги держим отдельно от веб-приложений, так удобнее ими управлять)?
Есть ли возможность перезагрузки конфигов при необходимости?
Есть ли интерфейс конфигурирования кодом?
(Мысли вслух) Смена формата конфигов вместо расширения поддерживаемых форматов (пусть и с неполной функциональностью) может играть против распространения библиотеки для тех, у кого производительность не упёрлась в логгер (у нас в одном из приложений такое было с log4j, пока не воткнули asyncappender). У меня yml не зашёл, хотя и напоминает своей идеологией питон, всё-таки значащие пробелы в конфигурации (с которой работают не только разработчики) нельзя назвать однозначно хорошим решением. Для себя нашел идеальный вариант формата конфига — hocon, потихоньку перехожу на него с других форматах в своих проектах.
Где-то лет 5 назад, после перехода с svn на git, пытались работать через eclipse-плагин, тут же бросили, после коммитов в нём получались кривые диффы (как будто весь файл изменили). Возможно, связано с autocrlf, возможно даже исправили, но осадочек остался. Subclipse таким не болел. Используем готовый плагин исключительно в режиме просмотра.
Ну да, теперь приходится сидеть на startisback, не удивлюсь, если оно по итогу быстрее родного работает в силу отсутствия виджетов.
Что касается ProcessHandle и Cleaner, то первый нужен для специфических целей и его появление обязано расширению границ применения java вообще, а к последнему я отношусь как к обычной смене одного апи на другое (лично мне пришлось писать финализатор лишь единожды). Что касается гарантий закрытия у Closable, появление достаточно умных ide, которые теперь ругаются на отсутствие вызова close у Closable-объекта, делает данную защиту от забытого close менее острой чем раньше.
Гм… Не использую hstore, но судя по описанию, аналог для jsonb — jsonb_object_keys
В итоге, когда в 18м году пришлось покупать ноут (не по причине проблем с 640m), пришел к решению ноутбук + портативный USB-C монитор + десктопная клавиатура. В этом случае требования к клавиатуре ноута становились более мягкими, но всё равно среди Dell-овских не нашел достойного варианта (возможно из-за ложной надежды найти что-нибудь близкое к 640m).
На сколько я помню, табличка с json-ами занимает чуть меньше чем табличка с jsonb (в частных случаях может быть наоборот), но при этом с jsonb больше возможностей и он работает быстрее.
В целом, для большинства применений jsonb выглядит выигрышнее hstore: асимптотика похожая, но для jsonb не нужны расширения, да и возможностей без конвертации в строку больше.
Аналог Arrays.asList() для Set не нужен, всегда можно передать результат Arrays.asList в конструктор HashSet. Чаще всего такая инициализация востребована в статических константах, а значит лишняя аллокация не имеет значения.
Что касается Map-а, в java8 использую комбинацию Stream.of с SimpleImmutableEntry (вот она замена Map.entry) и последующий collect в Map.
Да, вариант более многословный, но стандартные, уменьшающие громоздкость объявления констант заменяются нестандартными методами, так что на killer-фичу, заставляющую обновляться даже близко не подходит.
Кучка функций для замены commons-lang и подобных пакетов — это круто, но пока они появляются точечно, от сторонних пакетов отказаться не получится, а это заметно осложняет переход (зачем учить новое апи, если всё равно требуется использовать стороннюю библиотеку, в которой уже есть куча функций, которыми уже привык пользоваться). Конечно, появление этих функций в стандартной джаве — это круто, но почему это происходит так избирательно?
Что касается Predicate.not, в java8 есть Predicate.negate(), правда, он требует использования вспомогательной функции, либо явного каста, иначе компилятор не понимает, что это предикат (это, вроде, должны были починить в одной из более поздних версий). Да, Predicate.not — удобная штука, но на killer-фичу не тянет даже близко.
Есть такое понятие как пирамида Маслоу. Думаю, для большинства программистов участие в опенсорсе где-то ближе к верхушке. Активно контрибьютить можно, когда либо нет необходимости много работать (т.е., когда сидишь на работе с 9 до 18 и на жизнь хватает), либо когда это и есть работа. Но в постсоветском пространстве такое редкость.
В расчётах числа атомов ошибка на 3 порядка: видимо автор забыл килограммы в граммы перевести.