Pull to refresh
19
0
Send message

Пожалуйста, объясните что происходит в 15 паззлере? Я спать нормально не могу после него.

Я довольно часто заказываю из Европы запчасти для в велосипедов. Первый раз заказывал доставку как раз через EMS. Звонок в будний день в 11 утра — "Я у дверей с вашей посылкой", повезло что тогда я больной дома был. После этого стараюсь заказывать только почтой РФ, но на зарубежный сайтах не всегда понятно какой способ доставки кем будет отправлен, поэтому в общей сложности ещё пару раз попадался на EMS. каждый раз курьер звонил в будний день от дверей. Каким-то чудом по странному стечению обстоятельств я каждый раз оказывался дома. Один раз мне даже не стали звонить на телефон, позвонили в дверь (это был единственный раз когда меня не было дома) и увезли посылку обратно. В результате я про посылку узнал только когда мне продавец написал "нам тут вашу посылку вернули".

Подскажите, есть ли возможность в Elasticsearch сделать join по нескольких таблицам с возможностью сортировки по полям?
Пример: есть 2 таблицы — авторы и посты с лайками. Необходимо вывести информацию про авторов, отсортированную по суммарному количеству лайков в постах данного автора. Можно ли это сделать в один запрос?

Поделитесь, пожалуйста где спрашивали, просто письмом в поддержку?
Забыли самое главное — как часто ракета сначала затягивает в сопло дым от еще не существующей реактивной струи и только потом взлетает?)
PS извините за повтор.

Хочу лишь уточнить, что всё вышесказанное актуально для ситуации нехватки памяти! Система всё ещё может уничтожать отдельные Activity, например если таск висит в фоне долгое время. Цитата из документации:


If the user leaves a task for a long time, the system clears the task of all activities except the root activity. When the user returns to the task again, only the root activity is restored. The system behaves this way, because, after an extended amount of time, users likely have abandoned what they were doing before and are returning to the task to begin something new.

Однако для уничтоженных таким образом Activity isFinishing() будет корректно возвращать true. Но даже здесь похоже документация привирает! Есть небезосновательные подозрения, что начиная с определённой версии Android этот механизм больше не работает.

«if Android had to reclaim memory» — возможно тут я недопонял, в каких именно случаях андроид хочет выгрузить лишь Activity, а не цельный App.

Это одно из самых больших заблуждений среди разработчиков Android — что система может удалять из памяти отдельные Activity. Возникает оно, к сожалению из-за неточной информации в официальной документации, однако даже ведущие инженеры платформы утверждают обратное.

Всё было бы так если бы Android при недостатке памяти уничтожал только Activity, однако при нехватке памяти Android убивает целиком процесс.

Не могли бы вы поподробнее пояснить по поводу isFinishing()?


Кстати с Acitivity.isFinishing() тоже не всё так гладко: сверните приложение с >1 активити в стэке, дождитесь ситуации нехватки памяти, вернитесь обратно и воспользуйтесь Up Navigation и вуаля!.. Это был простой рецепт того, как поиметь Activity.isFinishing() == false для активити, которые вы больше никогда не увидите.

Предположим следующую ситуацию:
Back Stack: Activity1 -> Activity2 -> [Activity3]
Свернули приложение, дождались нехватки памяти, вернулись обратно, нажали кнопку назад, получили
BackStack: Activity1 -> [Activity2]
Для какой именно Activity я получу isFinishing() == false? Для Activity3?

Вот уж действительно — «Однажды у программиста появилась проблема и он решил использовать регулярные выражения чтобы её решить. Теперь у него 2 проблемы.»
Вы неправильно поняли, я вовсе не извращенец-однострочник, автор статьи первым написал намеренно раздутый "обычный" код, а потом 5 строчек в функциональном стиле, типа смотрите как теперь все здорово и читаемо. Вот только для кого, для адептов этого самого функционального стиля? Если я сейчас покажу аналогичный код из статьи и из своего комментария коллеге, не знакомому с RxJava, мой код он поймет, а вот увидев код из статьи произнесет "wtf is this". Серьезно, хватит считать, что функциональный стиль кода заведомо читаемее, с каких это пор базовые элементы языка стали считаться " непонятным мусором ", а flatMap — сутью? Я сам люблю функциональное программирование, но пихать его направо и налево без разбора и с пеной у рта доказывать всем вокруг, что теперь то код стал читаемее раз в 5 минимум похоже на помешательство, вы уж извините.
Спасибо за статью, однако общий посыл статьи на мой взгляд неверный. В принципе об этом уже сказал Googolplex в самом первом комментарии к статье — Optional предназначен не для борьбы с NPE, для более лаконичной реализации идиомы «опциональное возвращаемое значение».

Раздел "Использование Optional для устранения избыточного кода" странный. Вы предлагаете вместо этого
Person person = getDefaultPerson();
if (person != null) {
    PersonAddress personAddress = person.getAddress();
    if (personAddress != null) {
        PersonAddressStreet street = personAddress.getStreet();
        if(street != null) {
            streetName = street.getStreetName();
        } else {
            streetName = "EMPTY";
        }
    }
}

Написать так
Person person = getDefaultPerson();
String streetName = person.flatMap(Person::getAddress)
               .flatMap(PersonAddress::getStreet)
               .map(PersonAddressStreet::getStreetName)
               .orElse("EMPTY");

Хммм, 5 строк вместо 12, здорово. Но ведь можно написать и так
Person person = getDefaultPerson();
PersonAddress personAddress = person != null ? person.getAddress() : null;
PersonAddressStreet street = personAddress != null ? personAddress.getStreet() : null;
String streetName = street != null ? street.getStreetName() : "EMPTY";

и получить всего 4 строки. Если хочется сократить код максимально, то можно вообще объявить где-то парочку статических функций
public static <T> T consumeNpe(@NonNull Supplier<T> potentiallyNpeCall)
    {
        return noNpe(potentiallyNpeCall, null);
    }

public static <T> T consumeNpe(@NonNull Supplier<T> potentiallyNpeCall, T defaultValue)
{
    try
    {
        return potentiallyNpeCall.get();
    }
    catch (NullPointerException npe)
    {
        return defaultValue;
    }
}

и разруливать эту ситуацию в 1 строчку в любом месте в приложении
String streetName = consumeNpe(() -> getDefaultPerson().getAddress().getStreet().getStreetName(), "EMPTY");

Во втором примере вы предлагаете заменить
if(person != null) {
    System.out.println(person);
 }

на
person.ifPresent(System.out::println);

я бы назвал это "шило на мыло", тем более что первый кусок кода можно записать без скобок
if(person != null) System.out.println(person);

ну и далее по списку.

Это никакое не "устранение избыточного кода", это всего лишь замена декларативного стиля на функциональный, не более того.

Повторю, Optional предназначен лишь для лучшей читаемости ситуаций, когда возвращаемое методом значение опционально. Если взять ваш пример, то метод getAddress() в классе Person будет возвращать как раз Optional. Программист сразу поймёт что у персоны может не быть адреса едва взглянув на заголовок функции и вместо проверки на null вызовет метод isPresent().

Кстати рекомендую к прочтению ещё одну статью на эту тему.
Как так, в заголовке статьи говорится "появятся уже в марте", а на сайте — 3-4 квартал 2016 года?
Примерно год назад поставил себе 10 дома в качестве эксперимента. Месяц назад решился обновить рабочую 7 на 10 ибо домашняя проработала год без единого нарекания. Позавчера понял, что это была ошибка — ОС без спроса и предупреждения обновилась так, что слетели ВСЕ драйвера, которые могли слететь, начиная от драйверов чипсета и заканчивая драйверами видеокарты от Nvidia. Потратил около двух часов рабочего времени перед тем, как все снова заработало, подумываю о возвращении на 7. В голове не укладывается как можно выпускать обновления ОС, которые ломают тебе даже то, что раньше работало.
Если это действительно так, то лично для меня это очень печально. С покупкой Xperia Z3 стал фанатом Sony'вских смартов, но смотрю на Z5 и вот эту новую линейку и складывается впечатление, что смартфоны качественно хуже, чем Z3, а денег за них хотят больше. Xperia Z5 — да, добавили сенсор отпечатков пальцев, но при этом как это принято уменьшили батарею и убрали гарантию влагозащиты.

Презентованная линейка X вообще для меня непонятна. Вроде всё логично — 3 модели — бюджетная, средняя и флагман, но какого же чёрта безрамочный экран только у бюджетной модели!?
Лучше прочитайте книгу Леонарда Сасскинда "Битва при черной дыре. Мое сражение со Стивеном Хокингом за мир, безопасный для квантовой механики", там все эти вопросы раскрываются на достаточно постом языке.
Мне очень интересно, Xperia X — это продолжение линейки Z или это новая линейка? В этом году будут новые Zшки?
На самом деле я не имел ввиду именно эту штуку, я имел ввиду такой класс аксессуаров для телефона. Когда начинают пихать всё именно в смартфон, он начинает выглядеть для меня как в ветке комментариев ниже. Хотя смартфоны Caterpillar никогда не были "обычными".
Вопрос в том зачем это нужно когда давно существует вот такое.
Чудесный TODO:
// TODO óáðàòü ìàãè÷åñêèå ÷èñëà!!!
)

Information

Rating
Does not participate
Registered
Activity