Нет, не сумбурно, смысл понятен. Кстати некоторые перечисленные моменты уже реализованы, некоторые — лень, ибо уже конец близок. Вот если обнулят всех то можно еще доработать.
Переписал алгоритм покупки. Теперь он ищет самый эффективный продукт на данный момент. Ищет по принципу самого дешевого байта, тоесть смотрим на коэффициент / (кол-во байт которое добавляет покупка очередного аппера).
var storeUppers = [2,5,12,16,32,142,389,2075,8858,70862];
var productivity = [];
var ind = 0;
localStats.powerUps.forEach(function(powerUp) {
var realPrice = powerUp.currentPrice;
productivity.push(realPrice / storeUppers[ind]);
ind++;
});
var store = document.querySelector('#powerupstore');
var children = store.childNodes;
var nodeIndex = productivity.indexOf(Math.min.apply(Math, productivity));
var child = children[nodeIndex];
if(child.className == 'storeItem') {
child.dispatchEvent(evt);
}
Решить — не факт, предложить — почему нет. Но если мое предложение к усовершенствованию лямбд даже на Java 8 EG обсуждалось то видимо есть уже какие-то попытки формализировать. Поделитесь?
А зачем пример? Не знаю как в других языках, но в питоне новые конструкции языка появляются постоянно и происходит это потому что Гвидо активно прислушывается к комьюнити — захотели дектораторы -> договорились о синтаксисе -> получили дектораторы.
Вот MS другая ситуация, C# тоже стреляет такими же новинками, но это пальцем в небо, кому-то нужно, а кому-то нет, ведь выдумано это внутри компании. А тут сообщество есть, собственно те кто будет использовать конечный продукт. Ну и я считаю прислушиваться нужно.
К чему я веду — «даешь JSR к рассмотрению от народа!»
Лямбды открывают безмерные глубины для всякого рода GUI и прочих систем построенных на событиях.
Но все же, это только мне лямбды кажутся все еще незавершенными? Ну посудите сами, если мы ориентируемся использовать их для систем построенных на событиях то давайте же взглянем на такие системы, ну к примеру на GWT. Там все кишит прям callback'ами, а что такое callback — это комбинация onSuccess + onFail. Итого имеем 2 метода, а если я не ошибаюсь, то таких лямбд java еще не умеет.
Кратенькую информацию все же удалось получить от нашего соратника — TheShade. Но на сколько я понял данная концепция дальше обсуждения на Java 8 EG не зашла.
По заверениям разработчиков, демон scout_realtime потребляет ресурсов не больше, чем широко известная утилита htop.
Коллеги, кто ставил данное творение, поделитесь, пожалуйста, показателями нагрузки которую порождает данная утилита?
Плюс небольшое предложение — в текущей реализации, для real-time'a эта утилита висит демоном, но не лучше было бы сделать on-demand? Это из личного опыта, дело в том что я не сижу и не смотрю как плывет график, я зачастую хочу видеть тренд, за час/день/месяц. Мне кажется что cron джоба, которая с некоторой периодичностью (пусть 1/2/5 мин, заодно и хаотичные всплески уберутся) собирает статистику и потом, по требованию, показывает ее — будет экономичнее нагружать сервер.
Я даже расстроился когда посмотрел ролик. Ждал этого матча пол месяца, думал все будет как в трансляции игр, а в итоге что получил — еще одну рекламу промышленного робота. А хотелось бы не нарезку красивых моментов снятых с N дубля, которые превратили в голливудский блокбастер с сюжетной линией, а простой теннисный матч.
Да, не молодой, но использовали пока не было нареканий. Данная статья это как раз тревожный звоночек и посыл к тому что бы пересмотреть стек используемых 3rd party библиотек. Ну а с кандидатом угадали, первый на очереди как раз logback. Сейчас пока в лаборатории, но в строю может оказаться довольно скоро.
Да, с этими настройками тоже можно играться, но тут опять таки важно понимать что именно происходит:
1) bufferedIO всего лишь оборачивает java.io.Writer в java.io.BufferedWriter, с буфером 8 КБ
2) bufferSize регулирует размер буфера BufferedWriter
С помощью такой настройки FileAppender'а действительно можно понизить уровень блокировок на файле. Но я пошел другим путем, как раз таки увеличивая сам буфер AsyncAppender'а. Причиной тому была конфигурация платформы — mem/CPU в достатке, а вот IO лучше поберечь.
P.S. А кто в курсе что будет после того как набьем необходимое кол-во памяти?
А вот ниже уже нет, ошибку показывает.
P.S. Capacity на данный момент — пол терабайта.
и в комменте akurganow — habrahabr.ru/post/217507/#comment_7446305
P.S. Я думаю мое мнение понятно без дополнительных комментариев. Вцелом и программа и литература подобраны отлично.
Вот MS другая ситуация, C# тоже стреляет такими же новинками, но это пальцем в небо, кому-то нужно, а кому-то нет, ведь выдумано это внутри компании. А тут сообщество есть, собственно те кто будет использовать конечный продукт. Ну и я считаю прислушиваться нужно.
К чему я веду — «даешь JSR к рассмотрению от народа!»
P.S. За опечатку сори.
Кратенькую информацию все же удалось получить от нашего соратника — TheShade. Но на сколько я понял данная концепция дальше обсуждения на Java 8 EG не зашла.
Но в целом спасибо, отличная подбрка.
Плюс небольшое предложение — в текущей реализации, для real-time'a эта утилита висит демоном, но не лучше было бы сделать on-demand? Это из личного опыта, дело в том что я не сижу и не смотрю как плывет график, я зачастую хочу видеть тренд, за час/день/месяц. Мне кажется что cron джоба, которая с некоторой периодичностью (пусть 1/2/5 мин, заодно и хаотичные всплески уберутся) собирает статистику и потом, по требованию, показывает ее — будет экономичнее нагружать сервер.
1) bufferedIO всего лишь оборачивает java.io.Writer в java.io.BufferedWriter, с буфером 8 КБ
2) bufferSize регулирует размер буфера BufferedWriter
С помощью такой настройки FileAppender'а действительно можно понизить уровень блокировок на файле. Но я пошел другим путем, как раз таки увеличивая сам буфер AsyncAppender'а. Причиной тому была конфигурация платформы — mem/CPU в достатке, а вот IO лучше поберечь.