Windows на Git: прямая трансляция

• В общей сложности за 4 месяца существования репозитория было совершено более 250,000 Git коммитов;
• 8,421 пушей в среднем за день;
• 2,500 pull-запросов и 6,600 инспекторов кода в среднем за рабочий день;
• 4,352 активных ответвлений;
• 1,760 официальных сборок в день.

Производительность GVFS при работе на масштабных проектах

Попробуйте GVFS сами

• Atlassian SourceTree — SourceTree стал первым инструментом, который прошел валидацию на совместимость с GVFS; уже вышло обновление, в котором были введены некоторые изменения для более гладкого рабочего процесса.
• Tower — команда Tower рада сообщить, что они работают над добавлением поддержки GVFS в версию приложения для Windows. В ближайшем будущем соответствующий функицонал будет доступен в бесплатном обновлении.
• Visual Studio — само собой, неплохо бы и нашему собственному Visual Studio Git нормально работать с GVFS. Мы внедрим поддержку GVFS в версию 2017.3, первое превью которой (со всем необходимым для поддержки) выйдет в начале июня.
• Git на Windows — в рамках своей инициативы по масштабированию Git мы внесли ряд изменений под Git в Windows (к примеру, командная строка Git), включая поддержку GVFS. Сейчас у нас на Git создано особое ответвление для Windows, но со временем мы хотим все перенести в основную версию кода.

Обобщая сказанное

• успешно внедрили проект для 3500 инженеров;
• подключили прокси и доработали продуктивность;
• обновили открытый код и дали другим пользователям возможность вносить правки/вклады;
• обеспечили signed GVFlt драйвер, чтобы проще было воспользоваться сервисом;
• стали сотрудничать с другими командами, чтобы внедрить поддержку в популярные инструменты — SourceTree, Tower, Visual Studio и так далее;
• опубликовали несколько статей, где с технической точки зрения подробно рассматривается наш подход к масштабированию Git и GVFS.

https://habrahabr.ru/post/329878/

Reactive log stream processing with RxJava — Part l

В предыдущем посте автор рассматривал случаи использования ELK стека и сбора логов.
С учетом движения в сторону микросервисов и контейнеризации приложений, централизованная обработка логов и их хранение становится де-факто стандартом.

Может быть, нам стоит попробовать сделать следующий шаг и более активно использовать полученную информацию для того, чтобы находить причины ряда проблем задолго до их появления.*

Сноска — стримы и потоки данных в данном переводе являются взаимозаменяемыми словами. Также слово лог может означать журнал, хотя в большинстве случаев в тексте мы используем иное значение

Если бы мы рассматривали лог событий как поток данных того, что происходит в реальном времени в вашей системе, было бы очень интересно анализировать в реальном времени данные и все возможные варианты их использования, к примеру, обнаружить мошенническое поведение, с помощью агрегирования различных потоков информации непосредственно во время "атаки", и сразу же заблокировать атакующего вместо того, чтобы "традиционно" собирать лог данных и заниматься расследованием уже после возникновения инцидента.

Или другой пример, мы можем отфильтровать (filter) только те события, которые соответствуют определенному типу событий, сгруппировать (group by) их по общему ключу как userID и вычислить общее количество во временном окне, получив количество событий данного типа, которые пользователь совершает в определенный период времени.

 failedLogStream()
     .window(5,TimeUnit.SECONDS)
     .flatMap(window ->
                window
                .groupBy(propertyStringValue("remoteIP"))
                .flatMap(grouped -> grouped
                    .count()
                    .map( failedLoginsCount -> {
                          final String remoteIp = grouped.getKey();
                          return new Pair<>(remoteIp, failedLoginsCount);
                    }))
     )
     .filter(pair -> pair.get > 10)
     .forEach(System.out::println);           

Мы можем инициировать запросы и в других системах и работать с их ответами как с потоками данных, на которые мы можем подписаться и применить несколько привычных операторов для работы со стримами (потоками данных), которые представлены во фреймворках reactive streams (реактивных стримов).

Учим новую парадигму разработки

Хорошо бы разобрать, что такое реактивное программирование стримов, для этого нам нет необходимости разворачивать что-то большое, такое как Kafka Streams Spark or Flink.

Реактивное программирование — это неблокирующие приложения, управляемые событиями, которые масштабируются даже при небольшом числе потоков с противодействием нагрузке (механизм обратной связи, при котором количество данных от производителей не превышает число данных принимаемых потребителями).

Самой большой темой, которую принесет Spring5, будет поддержка Реактивного программирования. Новый модуль spring-web-reactive — фреймворк, похожий на spring-web-mvc, который позволит отдавать асинхронные (неблокирующие) ответы для REST сервисов и реактивный веб-клиент, из чего следует возможность применения данного решение для микросервисной архитектуры. Концепция реактивных стримов не специфична для Spring, поскольку существует общая спецификация reactive-streams-jvm, согласованная большинством реактивных фреймворков (пока для нее, может быть, и не существует идентичного наименования, но концепция должна быть достаточно простой, чтобы стать заменой фреймворкам).

Исторически модель реактивные потоки была представлена Rx.NET, а затем при помощи Netflix портирована на java, получив название RxJava. В то же время концепция был также успешно реализована и в других языках, под названием Реактивные расширения (Reactive EXtensions). С тех пор компании движутся в том же направлении, что и спецификация реактивных стримов. Сейчас RxJava, поскольку он был первопроходцем, нуждается в значительном рефакторинге(переписании кода) — соответственно, версия 2.х лучше соответствует спецификации, и, пока Spring reactor еще новичок, компании не составит труда переписать реализацию согласно спецификации. Рекомендуем прочитать больше о том как они взаимосвязаны.

Doug Lea сообщил, что хочет включить реактивные потоки в состав объекта java.util.concurrent.Flow, а это значит, что реактивные стримы будут поставляться в составе Java 9.

Преимущества с точки зрения производительности

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

Если рассматривать ответ от удаленного запрос как Stream (Стрим-поток данных), подписка на который запускает action (действие) при получении ответа, то вместо блокировки потока, ожидающего свой ответ, мы можем воспользоваться меньшим числом потоков в целом, что, в свою очередь, уменьшит затраты ресурсов (к примеру, процессорное время для переключения контекста между потоками и памяти для каждого стека потоков).

Таким образом, использование реактивного программирования позволит нам на стандартном железе обработать больше логов событий, чем обычно.

Пример: сервису, такому как Gmail, нужно отображать пользовательские почтовые сообщения (emails). Тем не менее, emails, в свою очередь, могут иметь множество людей в копии (CC). Было бы прикольно отобразить фотографию для тех пользователей, которые находятся в твоих контактах, что означает вызов REST — ContactService.

Получится вот так:

Future> emailsFuture = mailstoreService.getUnreadEmails();  
List emails = emailsFuture.get(); //блокировка текущего потока  
//возможно долгое ожидание, пока не будет получен полный список данных
//можно ли запустить следующий процесс, как только первый фрагмент будет получен?

Future> contacts = getContactsForEmails(emails);  
for(Mail mail : emails) {  
  streamRenderEmails(mail, contacts); //push(отправить) emails клиенту
}

Частично проблема была решена с приходом поддержки реактивного программирования в Java 8 с CompletableFuture (со своими thenCompose, thenCombine, thenAccept и еще 50 методами, хотя это не отменяет того факта, что нужно помнить все, что они делают, а это никак не помогает в прочтении кода).

CompletableFuture> emailsFuture = mailstoreService.getUnreadEmails();

CompletableFuture> emailsFuture  
  .thenCompose(emails -> getContactsForEmails(emails)) //нам все еще нужно ожидать List 
  .thenAccept(emailsContactsPair -> streamRenderEmails(emailsContactsPair.getKey(), emailsContactsPair.getValue()))

Мы можем переключиться на Iterator вместо List-а, и в тоже время не существует методов, говорящих выполнить какое-либо действие при появлении новых значений. В SQL есть такая возможность, к примеру, ResultSet (в котором вы можете выполнить rs.next()) вместо загрузки всех данных в память.

public interface Iterator {  
    /**
     * Возвращает {@code true}, если в итерации больше элементов.
     */
    boolean hasNext();

    /**
     * Возвращает следующий элемент итерации.
     */
    E next();
}

Но нам все еще нужно постоянно спрашивать "а у тебя есть новое значение?"

Iterable emails = mailstoreService.getUnreadEmails();  
Iterator emailsIt = emails.iterator();

while(emailsIt.hasNext()) {  
  Mail mail = emailsIt.next(); //неблокирующее действие все равно тратит много процессорного времени на получение новых значений
  if(mail != null) {
      ....
  }
}

Что нам нужно, так это реактивный итератор, такой тип данных, который сможет подписаться и выполнить действие, как только получено новое значение. Именно здесь начинается reactive stream programming (реактивное программирование стримов).

Так что же такое Stream?

Stream по-простому это последовательность упорядоченных во времени событий (событиеX происходит после событияY, так что события не конкурируют между собой).

Stream смоделирован так, что выпускает 0..N событий и одну из двух терминальных операций:

• событие завершения, через которое подписчикам сообщается, что выпуск данных окончен
• событие об ошибке, информирующее об окончании стрима с ошибкой (исключением)

Мы можем описать это визуально с помощью 'marble diagrams'.

Таким образом мы можем представить, что Stream-ом является все, а не только лог событий. Даже единичное значение может быть выражено как Стрим, выпускающий значение, за которым следует событие о завершении.

Бесконечный стрим — стрим, который выпускает события, но без единого терминального события(завершения | ошибки).

RxJava определяет Observable (Наблюдаемый) тип данных для моделирования Stream-а событий типа . В Spring Reactor-е он равен типу Flux.

Observable представляет собой stream температур, взятых с различными интервалами.

Observable представляет собой stream продуктов, купленных в нашем веб магазине.

Observable представляет собой одного пользователя (User), вернувшегося по запросу к БД.

    public Observable findByUserId(String userId) {...}
    //пусть будет Single для большей наглядности 
    public Single findByUserId(String userId) {...}

Но Observable это просто тип данных, поэтому, как и в случае с шаблоном проектирования Publish/Subscriber (Публикации/Подписчика), нам нужен Subscriber(Подписчик) чтобы обработать 3 типа событий

        Observable cartItemsStream = ...;

        Subscriber subscriber = new Subscriber() {
            @Override
            public void onNext(CartItem cartItem) {
                System.out.println("Cart Item added " + cartItem);
            }

            @Override
            public void onCompleted() {
            }

            @Override
            public void onError(Throwable e) {
                e.printStackTrace();
            }
        };

        cartItemsStream.subscribe(subscriber);

Реактивные операторы

Но это просто часть Stream-a, а до сих пор мы не применяли ничего необычного, только классический шаблон проектирования Observer (Наблюдатель).

Reactive (Реактивная) же часть означает, что мы можем определить некоторые Function (операторы — функции), которые будут выполнены, когда stream запустит событие.

Это значит, что будет создан другой stream (стримы immutable), на который мы можем подписать другой оператор и т.д.

Observable filteredCartStream = cartStream.filter(new Func1() {  
            @Override
            public Boolean call(CartItem cartItem) {
                return cartItem.isLaptop();
            }
        });

Observable laptopCartItemsPriceStream = filteredCartStream.map(new Func1() {  
            @Override
            public Long call(CartItem cartItem) {
                try {
                    return priceService.getPrice(cartItem.getId());
                } catch(PriceServiceException e) {
                    thrown new RuntimeException(e);
                }
            }
        });

Поскольку операторы (методы) класса Observable (filter, map, groupBy,...) возвращают Observable, это значит, что мы можем использовать цепочку из операторов, чтобы объединить их с лямбда синтаксисом и написать что-нибудь красивое.

Observable priceStream = cartStream  
                        .filter((cartItem) -> cartItem.isLaptop()).
                        .map((laptop) -> {
                             try {
                                  return priceService.getPrice(cartItem.getId());
                            } catch(PriceServiceException e) {
                                 thrown new RuntimeException(e);
                            }
                        });

Обратите внимание, что выше, когда создается priceStream, ничего не происходит — priceService.getPrice() не вызывается, пока нет элемента, проходящего по цепочке операторов. Это означает, что мы создали через rx-оператор подобие плана, как управляемые данные будут спускаться вниз по цепочке(подписание регистрируется).

Когда просят объяснить реактивное программирование, обычно в шутку дают пример с Excel листами, где в колонках написаны формулы, вызываемые при обновлении ячейки, что, в свою очередь, обновляет другую ячейку, которая, в свою очередь, обновляет другую и так далее по цепочке.

Прямо как rx-operator, который ничего не делает, эти формулы просто управляют данными и каждая из них получает свой шанс сделать что-то до того момента, как данные спустились вниз по цепочке.

Чтобы лучше понимать, как события путешествуют вместе с цепочкой операторов, я нашел полезную аналогию, в примере с переездом из одного дома в другой, грузчики выступают в роли операторов, вместе с которым перемещаются вещи из вашего дома — так это изобразил Томас Нильд.

Его пример с кодом:

Observable mover1 = Observable.create(s -> {  
   while (house.hasItems()) {
    s.onNext(house.getItem());
   }
   s.onCompleted();
});

Observable mover2 = mover1.map(item -> putInBox(item));

Subscription mover3 = mover2.subscribe(box -> putInTruck(box),  
   () -> closeTruck()); //это сработает на событие OnCompleted()

"Грузчик 1 с одной стороны источник Observable. Он создает выбросы за счет того, что выносит вещи из дома. Он вызывает Грузчика 2 с методом onNext(), который выполняет map() операцию. Когда его метод onNext() вызван, он берет вещь и перекладывает в коробку. Затем он вызывает Грузчика 3, конечного Subscriber(подписчика), с методом onNext(), который грузит коробку в машину."

Магия RxJava — это большой набор доступных операторов, ваша же работа заключается в комбинировании их всех вместе для управления течением данных.

Множество Stream операторов помогают составить словарь терминов для обозначения действий, производимых со стримами, которые могут быть реализованы в популярных языках (RxJava, RxJS, Rx.NET, etc) из числа ReactiveX framework (Реактивных расширений).

Эти понятия надо знать даже при использовании различных фреймворков для работы с реактивными стримами, таких как Spring Reactor (в надежде на наличие неких операторов, общих для этих фреймворков).

Пока что мы видели только простые операторы, такие как фильтрация:

Которые только пропускают элементы, попадающие под условие фильтра (один грузчик перенесет только те вещи, которые стоят меньше 100$, вместо того, чтобы передать сразу все другому грузчику)

Однако есть операторы, которые могут разбить стрим на множество отдельных стримов — Observable>(Стрим стримов) — это такие операторы, как groupBy

        Observable values = Observable.just(1,4,5,7,8,9,10);
        Observable> oddEvenStream = values.groupBy((number) -> number % 2 == 0 ? "odd":"even");
        Observable remergedStream = Observable.concat(oddEvenStream);
        remergedStream.subscribe(number -> System.out.print(number +" "));

//Выводит
//1 5 7 9 4 8 10 

и достаточно простой оператор concat, который снова из четных и нечетных стримов создает один-единственный стрим, и устанавливает на него подписку.

Мы видим, что оператор concat ожидает завершения стрима перед тем, как добавить еще один, снова создавая один стрим. Таким образом, нечетные числа отображаются первыми.

Также у нас есть возможность скомбинировать вместе множество stream-ов, как, например, это делает zip оператор

Zip назван так не потому, что он работает как архиватор, но скорее из-за то, что он, как молния (на куртке), комбинирует события из двух stream-ов.

Он берет одно событие из одного stream-а и соединяет с событием из другого (делая пару). Как только это выполнено, он применяет оператор склеивания, перед тем, как спуститься дальше по цепочке.

PS: это работает и для большего количества stream-ов.

Так что, даже если один stream выпускает события быстрее, то дальше слушатель увидит только скомбинированное событие, которое выпустится из более медленного stream-а.

Иметь возможность "ждать" ответа от множества удаленных вызовов, которые мы получаем от stream-ов, на самом деле очень полезно.

С другой стороны, оператор combineLatest не ожидает выпуска пары событий, но вместо этого, использует последние выпущенные события из более медленного stream-а, до применения функции склейки и передачи его дальше по цепочки.

Движемся к мышлению на основе Push подхода

Давайте рассмотрим несколько примеров, как на самом деле создают Observables. Наиболее длинный вариант создания:

        log("Before create Observable");
        Observable someIntStream = Observable
                .create(new ObservableOnSubscribe() {
                    @Override
                    public void subscribe(ObservableEmitter emitter) throws Exception {
                        log("Create");
                        emitter.onNext(3);
                        emitter.onNext(4);
                        emitter.onNext(5);
                        emitter.onComplete();
                        log("Completed");
                    }
                });
        log("After create Observable");

        log("Subscribing 1st");
        someIntStream.subscribe((val) -> LOGGER.info("received " + val));
        //мы можем опустить реализацию
        //другие методы(for onError and onComplete) если мы ее хотим сделать, что-то особенное

        log("Subscribing 2nd");
        someIntStream.subscribe((val) -> LOGGER.info("received " + val));

События посылаются подписчику, как только тот подписался.
Не то, что мы пользуемся такой конструкцией, просто мы передали новый объект ObservableOnSubscribe, который демонстрирует, что делать, когда на него кто-нибудь подписывается.

Пока мы не подписались на Observable, выходных данных нет и ничего не происходит, данные не движутся.

Когда кто-то подписывается, вызывается метод call() и 3 сообщения проталкиваются вниз по цепочке, следом за ними идет сигнал, что stream завершился.

Выше мы дважды подписались, код внутри метода call(...) также будет вызван дважды. Так что он эффективно переотправляет те же значения, как только кто-нибудь еще подпишется и тогда получит следующие значения на вывод:

mainThread: Before create Observable  
mainThread: After create Observable  
mainThread: Subscribing 1st  
mainThread: Create  
mainThread: received 3  
mainThread: received 4  
mainThread: received 5  
mainThread: Completed  
mainThread: Subscribing 2nd  
mainThread: Create  
mainThread: received 3  
mainThread: received 4  
mainThread: received 5  
mainThread: Completed  

Важно заметить, что rx операторы не обязательно означают многопоточность. RxJava не внедряет конкурентность по умолчанию между Observable и Subscriber. Поэтому все вызовы происходят на "главном" потоке.

Такой тип Observable, которые начинают распространение, когда кто-нибудь подписан называются cold observables(холодные наблюдатели). Другой вид — hot observables(горячие наблюдатели), они могут выпускать события, даже когда никто не подписан на них.

• Cold Observables начинают распространять события только когда кто-то подписывается. Каждый подписчик получает одни и те же события. Например, как CD на котором играют одни и те же песни для того, кто включил cd в плеер послушать.
• Hot Observables события распространяются даже когда на них еще никто не подписался. Как радиостанция которая проигрывает песни через радиовещание, даже когда никто его не включал. И так же, как при включении радиоприемника, ты пропускаешь предшествующие события. Hot observable моделирует события, распространением которых вы не можете управлять. Примерно как в случае записи событий в журнал (лог событий).

Subjects это такой специальный вид Observable, который также является Observer (как Subscriber — который решает, что он может протолкнуть данные (вызовом onNext()) до них) и сделает реализацию горячих Observables проще. Также существует множество реализаций, подобных ReplaySubject, которые сохраняют выделенные события в буфере и воспроизводят их по подписке (конечно, можно указать размер буфера, чтобы предотвратить ошибку OutOfMemory), пока PublishSubject только пропускает события, которые случились после подписания.
И конечно, существует множество статических методов для создания Observables и из других источников.

Observable.just("This", "is", "something")  
Observable.from(Iterable collection)  
Observable.from(Future future) - передает значение после того, как `future` выполнится 

Добавление в наш ELK-стек RabbitMQ эмиттера данных, отправляемых посредством push

По традиции, работая со стеком ELK, мы используем ElasticSearch чтобы запросить данные по логу событий, так что можно сказать, что они в опрашивающем стиле 'pull-based'.

Можем ли вместо этого иметь push-based, где мы собираемся информировать 'незамедлительно' при появлении события в журнале, чтобы дальше уменьшить время реагирования на событие, с того момента как оно произошло и до того как мы начнем его обрабатывать.

Одним из множества возможных решение может стать RabbitMq, как бывалое в сражениях решение с очень хорошей репутацией за его производительность, за его возможность обработки огромного числа сообщений. Несмотря на это Logstash уже поддерживает плагин для RabbitMQ (также есть еще один плагин для FluentD) так что мы можем с легкостью интегрировать его в наш существующий ELK стек и записывать логи в ElasticSearch и RabbitMQ.

Возможно вы помните, что Logstash может вести себя как контроллер, и выбирать как ему работать, и куда отправлять/сохранять логируемые событий. Это значит что мы можем отфильтровать те события, которые хотим обработать или указать куда их послать, например, в другие RabbitMQ очереди.

Существует даже возможность напрямую отправлять данные в RabbitMQ через Logback Appender, если вам захочется опустить использование Logstash.

К слову сказать: Пока так называемый AmqpAppender, является скорее специфичной реализацией RabbitMQ AMQP (с версией протокола AMQP 0-9-1, 0-9).

ActiveMQ для примера (пока тоже поддерживает AMQP connector) кажется реализует протокол версии AMQP 1.0, пока spring-amqp библиотека с протоколом версий 0-9-1, 0-9, которые совсем отличаются от 1.0), так что вы может столкнетесь с ошибками по типу 'org.apache.activemq.transport.amqp.AmqpProtocolException: Connection from client using unsupported AMQP attempted'

Однако наше решение было чтобы использовать logstash-logback-encoder и отправлять отформатированный JSON с журналом событий в Logstash. Мы перенаправим logstash вывод на точку обмена RabbitMQ (exchange).

Мы будем использовать docker-compose, чтобы запустить кластер logstash-rabbitmq
Вы можете склонировать репозиторий

docker-compose -f docker-compose-rabbitmq.yml up
и затем вы можете использовать
./event-generate.sh
чтобы сгенерировать некоторое число случайных событий которые будут отправлены на logstash.

Для того, чтобы определить, куда отправлять данные, используйте файл настроек logstash. Мы используем rabbitmq-output-plugin, как ссылку:

output {  
    rabbitmq {
        exchange => logstash
        exchange_type => direct
        host => rabbitmq
        key => my_app
    }
}

RabbitMQ это не классический JMS сервер, вместо этого он использует AMQP протокол, который имеет весьма отличную от остальных концепцию для очередей.

Издатель отправляет сообщения на именованную точку обмена (exchange) и потребитель забирает сообщения из очереди.

У сообщения есть стандартный заголовок 'routing-key', который используется в процессе называемом ассоциативным привязкой, чтобы связать обмен сообщениями в очереди. Очереди могут фильтровать какие сообщения они получают через ключ привязки, и к тому же можно использовать подставленные знаки в привязке как эти 'logstash.'

Для более подробного объяснения AMQP вы можете прочитать здесь и тут. Так мы настроили Spring соединение c RabbitMq

    @Bean
    ConnectionFactory connectionFactory() {
        return new CachingConnectionFactory(host, port);
    }

    @Bean
    RabbitAdmin rabbitAdmin() {
        RabbitAdmin rabbitAdmin = new RabbitAdmin(connectionFactory());
        rabbitAdmin.declareQueue(queue());
        rabbitAdmin.declareBinding(bindQueueFromExchange(queue(), exchange()));
        return rabbitAdmin;
    }

    @Bean
    SimpleMessageListenerContainer container(ConnectionFactory connectionFactory, MessageListenerAdapter listenerAdapter) {
        SimpleMessageListenerContainer container = new SimpleMessageListenerContainer();
        container.setConnectionFactory(connectionFactory);
        container.setQueueNames(queueName);
        container.setMessageListener(listenerAdapter);

        return container;
    }

    @Bean
    Queue queue() {
        return new Queue(queueName, false);
    }

    DirectExchange exchange() {
        return new DirectExchange("logstash");
    }

    private Binding bindQueueFromExchange(Queue queue, DirectExchange exchange) {
        return BindingBuilder.bind(queue).to(exchange).with("my_app");
    }

    @Bean
    MessageListenerAdapter listenerAdapter(Receiver receiver) {
        MessageListenerAdapter messageListenerAdapter = new MessageListenerAdapter(receiver,
                new MessageConverter() {
            public Message toMessage(Object o, MessageProperties messageProperties)
                    throws MessageConversionException {
                throw new RuntimeException("Unsupported");
            }

            public String fromMessage(Message message) throws MessageConversionException {
                try {
                    return new String(message.getBody(), "UTF-8");
                } catch (UnsupportedEncodingException e) {
                    throw new RuntimeException("UnsupportedEncodingException");
                }
            }
        });
        messageListenerAdapter.setDefaultListenerMethod("receive"); //the method in our Receiver class
        return messageListenerAdapter;
    }

    @Bean
    Receiver receiver() {
        return new Receiver();
    }

Мы определили очередь и связываем с сервисом обмена 'logstash', чтобы принять сообщения с ключем маршрутизации 'my_app'. MessageListenerAdapter выше определяет, что метод 'receive' должен быть вызван на бине Receiver каждый раз, когда новое сообщение приходит из очереди.

Поскольку мы ожидаем непрерывный поток в лог событий, мы не имеем над ним контроль, мы можем подумать об использовании hot observable, которые распространяют события всем подписчикам после того, как они подписались, так что мы используем для работы PublishSubject.

public class Receiver {  
    private PublishSubject publishSubject = PublishSubject.create();

    public Receiver() {
    }

    /**
     * Method invoked by Spring whenever a new message arrives
     * @param message amqp message
     */
    public void receive(Object message) {
        log.info("Received remote message {}", message);
        JsonElement remoteJsonElement = gson.fromJson ((String) message, JsonElement.class);
        JsonObject jsonObj = remoteJsonElement.getAsJsonObject();

        publishSubject.onNext(jsonObj);
    }

    public PublishSubject getPublishSubject() {
        return publishSubject;
    }
}

Мы должны знать, что событие SimpleMessageListenerContainer поддерживает наличие более одного потока, который потребляет из очереди (и пропускает события вниз по цепочки). Однако контракт Observable говорит, что мы не можем выделять события конкурентно (вызовы onNext,onComplete, onError должны быть сериализованы):

// ТАК ДЕЛАТЬ НЕ НАДО
Observable.create(s -> {  
                    // Thread A
                    new Thread(() -> {
                        s.onNext("one");
                        s.onNext("two");
                    }).start();

                    // Thread B
                    new Thread(() -> {
                        s.onNext("three");
                        s.onNext("four");
                    }).start();
                });
// ТАК ДЕЛАТЬ НЕ НАДО

//ДЕЛАЙТЕ ТАК
Observable obs1 = Observable.create(s -> {  
                    // Thread A
                    new Thread(() -> {
                        s.onNext("one");
                        s.onNext("two");
                    }).start();
                  });

Observable obs2 = Observable.create(s -> {  
                    // Thread B
                    new Thread(() -> {
                        s.onNext("three");
                        s.onNext("four");
                    }).start();
                });

Observable c = Observable.merge(obs1, obs2); 

Мы можем обойти эту проблему вызывая Observable.serialize() или Subject.toSerialized(), но мы остаемся со значение по умолчанию 1 Thread в ListenerContainer, нет необходимости делать это. Еще вы должны быть в курсе того, что если вы планируете использовать Subjects как шину событий, распространяющихся на несколько потоков. Прочитайте подробное объяснение.

А сейчас вы можете взглянуть на код и репозиторий, как продолжение этого длинного поста Part II (Части 2) или перейдите на Rx Playground там вы найдете больше примеров.

https://habrahabr.ru/post/329894/

• Резервное копирование, клонирование и восстановление данных с помощью инструментов NetApp и VMware. Часть 1
• Резервное копирование, клонирование и восстановление данных с помощью инструментов NetApp и VMware. Часть 2
• Облачные технологии в киноиндустрии: как DreamWorks решила проблему обработки больших объемов данных
• Хостинг персональных данных в облаке— особенности услуги
• Репликация данных в облако NetApp сервис-провайдера
• Зарубежное или локальное размещение данных в облаке: подводные камни

https://habrahabr.ru/post/329400/

HPE MSA: решения для хранения данных, масштабируемые по мере роста компании

Представляем пятое поколение систем MSA

Конструкция и архитектура систем MSA пятого поколения

https://habrahabr.ru/post/329874/

https://habrahabr.ru/post/329858/

classpath "io.realm:realm-gradle-plugin:0.89.1" 

О нас

Realm как стартап

Realm как база данных

The Realm Mobile Platform is a next-generation data layer for applications. Realm is reactive, concurrent, and lightweight, allowing you to work with live, native objects.

Hello world

build.gradle (Project level) 

classpath "io.realm:realm-gradle-plugin:3.3.0"

build.gradle (App level) 

apply plugin: 'realm-android'

Realm.init(this)
val config = RealmConfiguration.Builder()
       .build()
Realm.setDefaultConfiguration(config)

val realm = Realm.getDefaultInstance()

realm.executeTransaction { realm ->
   val dataObject = realm.createObject(DataObject::class.java)
   dataObject.name = "A"
   dataObject.id = 1
}

val dataObject = realm.where(DataObject::class.java).equalTo("id", 1).findFirst()
dataObject.name // => A

realm.executeTransaction { realm ->
   val dataObjectTransaction = realm.where(DataObject::class.java).equalTo("id", 1).findFirst()
   dataObjectTransaction.name = "B"
}
dataObject.name // => B

Сравнение с другими базами данных

Сравнение с другими ORM

Графики с сайта Realm

Live Objects

Синхронное чтение

fun getFirstObject(realm: Realm, id: Long): DataObject? {
   return realm.where(DataObject::class.java).equalTo("id", id).findFirst()
}

Асинхронное чтение

val firstObject = realm.where(DataObject::class.java).findFirstAsync()
log(firstObject.id)

fun getObjectObservable(realm: Realm, id: Long): Observable {
   return realm.where(DataObject::class.java).findFirstAsync().asObservable()
}

Основные особенности Realm объектов

• Получение объектов из базы очень быстрое, десериализации как таковой нет, чтение с диска происходит только при обращении к конкретному полю
• Именно для этого существует требование делать все поля приватными и обращаться через геттеры
• Метод copyFromRealm() — позволяет получать отвязанные, полностью собранные объекты, прямо как обычная ORM. Правда и все фишки Realm становятся недоступны. На вход принимается глубина десериализации, по умолчанию MAX_INT
• В дебагере все поля будут null. Для получения какого-либо значения нам нужно обращаться через геттер
• Все объекты Live, т.е живые. Изменения распространяются моментально в рамках одного потока. Более сложные кейсы смотрите ниже (многопоточность).
• Фильтрация объектов осуществляется по полям, причем названия полей вы указываете руками в виде строки. Например так: .equalTo(«id», 1). Это усложняет рефакторинг и приводит к ошибкам в наименовании полей для фильтрации. К сожалению Realm не генерирует переменные с названиями полей, поэтому все выборки лучше прятать внутри функции:
  
  

  fun findFirstDataObject(id: Long, realm: Realm) : DataObject
         =  realm.where(DataObject::class.java).equalTo("id", id).findFirst() 

  
  или использовать генератор имен полей от cmelchior
  
• Этот пункт изменился прямо во время написания статьи (яркий пример того, как развивается проект)
  Было: Невозможно использовать DiffUtil при изменении объекта, невозможно понять какие поля у объекта изменились. Т.е. если вам пришла нотификация об изменении объекта, невозможно понять что у него изменилось. Связано это с тем, что оба объекта (старый и новый) являются live объектами и ссылаются на одни и те же данные, они всегда будут равны.
  Стало: Можно использовать RealmObjectChangeListener для понимания что изменилось:
  
  RealmObjectChangeListener

  Person p = realm.where(Person.class).findFirst();
              p.addChangeListener(new RealmObjectChangeListener() {
                  @Override
                  public void onChange(Person person, ObjectChangeSet changeSet) {
                      if (changeSet.isDeleted()) {
                          hide(); // Object was deleted
                      } else {
                          // Use information about which fields changed to only update part of the UI
                          if (changeSet.isFieldChanged("name")) {
                              updateName(person.getName());
                          }
                      }
                  }
              });
   

  
  
• Любой объект доступен только пока открыт instance realm-a, из которого мы его получили. Проверять можно методами isValid. При обращении к невалидному объекту получим исключение
• Объекты доступны только в том потоке, в котором созданы. Обращаться из другого потока нельзя, получим исключение

• Получение списков очень быстрое, по сути мы получаем только count. Все запросы lazy, получить большой список из сложных объектов мы можем очень быстро
• Списки доступны только для чтения, любые методы изменения приводят к исключению
  
• Т.к. мы можем быстро и дешево получать все элементы, можно забыть о проблеме пагинации. Мы всегда отдаем полный список элементов, при скролле обращаемся к объектам, и они быстро получаются из базы. Если нам нужно подгрузить данные, мы запускаем загрузку, получаем данные, сохраняем их в Realm, снова получаем полный список с загруженными элементами и отображаем его
  
• До недавнего времени (до версии 3.0) была проблема с перерисовкой всех элементов списка. Если мы используем список для адаптера, то при изменении одного элемента происходит полная перерисовка всего списка. Использовать DiffUtils и сравнивать какие объекты изменились, не получится, т.к. это live объекты. В Realm 3.0 появились OrderedCollectionChangeSet, который сообщает нам DeletionRanges, InsertionRange, ChangeRanges. Стало наконец возможно понять какие объекты и как изменились.
  
  
  Пример CollectionChangeListener

  
  private final OrderedRealmCollectionChangeListener> changeListener = new OrderedRealmCollectionChangeListener() {
      @Override
      public void onChange(RealmResults collection, OrderedCollectionChangeSet changeSet) {
          // `null`  means the async query returns the first time.
          if (changeSet == null) {
              notifyDataSetChanged();
              return;
          }
          // For deletions, the adapter has to be notified in reverse order.
          OrderedCollectionChangeSet.Range[] deletions = changeSet.getDeletionRanges();
          for (int i = deletions.length - 1; i >= 0; i--) {
              OrderedCollectionChangeSet.Range range = deletions[i];
              notifyItemRangeRemoved(range.startIndex, range.length);
          }
  
          OrderedCollectionChangeSet.Range[] insertions = changeSet.getInsertionRanges();
          for (OrderedCollectionChangeSet.Range range : insertions) {
              notifyItemRangeInserted(range.startIndex, range.length);
          }
  
          OrderedCollectionChangeSet.Range[] modifications = changeSet.getChangeRanges();
          for (OrderedCollectionChangeSet.Range range : modifications) {
              notifyItemRangeChanged(range.startIndex, range.length);
          }
      }
  };
  

  
  
  
  

Транзакции

val user = database.getUser(1)
button.setOnClickListener { user.name = "Test" }

val user = database.getUser(1)
button.setOnClickListener { database.setUserName(user, "Test") }

Синхронные транзакции:

fun syncTransaction() {
   Realm.getDefaultInstance().use {
       it.executeTransaction {
           val dataObject = DataObject()
           it.insertOrUpdate(dataObject)
       }
   }
}

Асинхронные транзакции

Realm.getDefaultInstance().use {
   it.executeTransactionAsync({
       it.insertOrUpdate(DataObject(0))
   }, {
       log("OnSuccess")
   }, {
       log("onError")
       it.printStackTrace()
   })
}

val realm = Realm.getDefaultInstance()
val parent = realm.where(Parent::class.java).findFirst()
val children = Children()
// parent.setChildren(children) <-- Error
val childrenRealm = realm.copyToRealmOrUpdate(children)
parent.setChildren(childrenRealm) /// Ok

// Thread pool for all async operations (Query & transaction)
static final RealmThreadPoolExecutor asyncTaskExecutor = RealmThreadPoolExecutor.newDefaultExecutor();

Open/close realm

• для Activity: onCreate / onDestroy
• для Fragment: onCreateView/onDestroyView

Realm.getDefaultInstance().use { // it = realm instance}

// Use doOnUnsubscribe 
val realm = Realm.getDefaultInstance()
realm.where(DataObject::class.java).findAllSorted("id").asObservable().doOnUnsubscribe { realm.close() }

// Use Observable.using
Observable.using(Realm.getDefaultInstance(), realm -> realm.where(DataObject::class.java).equalTo("id", id)
       .findFirstAsync()
       .asObservable()
       .filter(realmObject -> realmObject.isLoaded())
       .cast(DataObject::class.java), Realm::close);

Notifications, RxJava

fun getObjectObservable(realm: Realm, id: Long): Observable {
   return realm.where(DataObject::class.java).equalTo("id", id).findFirstAsync()
           .asObservable().filter({ it?.isLoaded }).filter { it?.isValid }
}

Многопоточность и асинхронность

“Управление параллельным доступом с помощью многоверсионности (англ. MVCC — MultiVersion Concurrency Control) — один из механизмов обеспечения параллельного доступа к БД, заключающийся в предоставлении каждому пользователю так называемого «снимка» БД, обладающего тем свойством, что вносимые пользователем изменения в БД невидимы другим пользователям до момента фиксации транзакции. Этот способ управления позволяет добиться того, что пишущие транзакции не блокируют читающих, и читающие транзакции не блокируют пишущих.”

• Нельзя смешивать асинхронные транзакции и синхронные, если смешать, все транзакции станут синхронными
• Нельзя использовать асинхронные вызовы в потоках без Looper
• Для длительных транзакций нужно открыть отдельный instance realm, иначе realm может быть закрыт во время транзакции и вы получите исключение
• Все действия в асинхронной транзакции происходят на отдельном внутреннем executor-е, как следствие вы не можете пользоваться внешними realm объектами, возможно переполнение executor-а, изменения realm object не распространяются между потоками и прочие неудобства

Тестирование

Один Realm хорошо, а три лучше

Наследование и полиморфизм

Kotlin

Realm mobile platform

• Realm Mobile Database – база для хранения данных
  
• Realm Object Server – сервер, отвечающий за автоматическую синхронизацию и обработку событий
• Realm Data Integration API – для подключения и синхронизации данных с существующими БД (Oracle, MongoDB, Hadoop, SAP HANA, Postgres и Redis)

Иллюстрация работы mobile platform

Отладка

• RealmLog — выводит лог, есть разные уровни логирования
  
• Realm браузер — нужен просмотра базы данных с компьютера. Работает только под Mac. Для просмотра базы на Windows можно использовать Stetho Realm
  Также существуют несколько Android библиотек для удобного просмотра данных на девайсе.
  
• WriteCopyTo() — позволяет скопировать базу в файл и отправить ее на анализ.
• NDK Debugging — для анализа ошибок в нативном коде можно использовать Crashlytics NDK Crash Reporting
  

Архитектура

Полезные ссылки

Заключение

https://habrahabr.ru/post/328418/

• Back-end – могут писать системные, интеграционные, компонентные, юнит тесты (почему бы и нет?).
• Front-end – могут писать как e2e тесты, так и компонентные, так и юнит тесты.
• DB — занимаются тестированием данных/самой БД.
• Performance – тут вроде бы очевидно.
• Infrastructure – занимаются больше вопросами «около-девопсными».  
• Mobile testing(iOS, Androind, IoT) — сейчас очень модно стало отделять таких инженеров, хотя на мой взгляд это все о том же Back-end/Front-end.

https://habrahabr.ru/post/329372/

https://habrahabr.ru/post/329864/

1. Уровни зрелости дизайна в компании
2. Роль продуктового дизайнера
3. Дизайн-система как способ управления качеством интерфейса продукта и скоростью выхода на рынок
4. Организация работы дизайнеров и построение дизайн-культуры
5. Целеполагание через аналитику и исследования

Редизайн организации

1. Описать текущий интерфейсный и организационный долг, которые мешают создавать качественные продукты.
2. Показать видение будущего — каким вы видите идеальный дизайн продуктов компании и что должно заработать для этого.
3. Отметить, чему в продукте мешают текущие проблемы и что именно улучшат изменения. Это покажет их ценность для компании и продуктов.
4. Оценить сложность изменений — что нужно сделать внутри дизайн-команды и в организации в целом, чтобы светлое будущее наступило.
5. Определить этапы внедрения изменений — первоочередные, средне- и долгосрочные.
6. Начать включать изменения в общий план работ и отслеживать их свершение и широко рассказывать о позитивных изменениях.

Сложно начать идеально

• 2016: 44 запуска и редизайна
• 2015: 31
• 2014: 42
• 2013: 50
• 2012: 28
• 2011

Мобильные приложения

Медиапроекты

Мобильный веб

My.com

А как насчёт...

Паттерны дизайн-менеджмента

0. Осознание ценности дизайна

• Доверяют менеджеры. Они приходят с проблемой, а не готовым решением.
• Доверяют конечные специалисты. Напрямую обращаются за решением рабочих проблем, минуя менеджеров.
• Задачи приходят заранее, есть время продумать интерфейс.
• Уменьшается количество итераций по задачам.

Симптомы проблем

• Слабые или даже вредные дизайн-решения.
• Разные экраны одного продукта выглядят и работают по-разному.

• Дизайнеры не имеют влияния на продуктовые решения.
• Дизайнеры привлекаются к задачам в последний момент, «навести марафет».
• Менеджеры и разработчики сами принимают дизайн-решения.

Способ решения -> паттерн

• О: Лидер дизайна (часть 4)
• О: Навыки аргументации, презентации и фасилитации
• Т: Кредит доверия (часть 1)
• Т: Карта лиц, принимающих решения
• С: Ко-дизайн (часть 4)
• С: Общая дизайн-грамотность (часть 4)
• С: Адвокат дизайна среди топ-менеджеров

• Т: Юзабилити-тестирование, на которое ходит вся продуктовая команда (часть 5)
• Т: Аналитика и эксперименты (часть 5)

• О: Быстрые победы (часть 6)
• Т: Внутренний маркетинг успехов дизайна
• С: Метрики дизайна, завязанные на бизнес (часть 5)

1. Качество продукта

• Достойное качество продукта в реализации, не только макетах.
• Лучше отношение пользователей к продукту, что выражается в росте ключевых метрик.
• Меньше ресурсов на поддержание приемлемого уровня качества.

Симптомы проблем

• Визуально развалился интерфейс.
• Не отрабатывают какие-то функции.
• Непонятны какие-то функции, пользователь не может работать с ними.
• Купленный или только запущенный продукт хуже остальных.

• Разработчики невнимательно реализуют макеты.
• Дизайн выпускается раньше времени, до проверки качества реализации.
• Дизайнеры выдают не до конца продуманные или неполные макеты, так что разработчикам приходится самим додумывать (а они не специалисты).

Способ решения -> паттерн

• О: Ответственность шире, чем просто создание макетов (часть 2)
• О: T-образные специалисты (часть 2)
• О: Карта навыков и их развития (часть 4)
• О: Дизайн-ревью командой (часть 4)
• О: Общий инструментарий (часть 4)
• Т: Креативные методики решения проблем (часть 4, 5)

• Т: Дизайн-система (часть 3)
• Т: Чек-листы
• Т: Экспертная оценка с возможность задержать релиз
• Т: Юзабилити-тестирование (часть 5)
• Т: Уменьшение интерфейсного долга (часть 6)
• С: Влияние на продуктовый план (часть 5)
• С: Повышение общей дизайн-культуры и внимательности разработчиков (часть 4)

• С: Долгосрочное планирование (часть 4, 6)
• С: Клуб дизайн-лидеров (часть 4)
• С: Метрики дизайна, завязанные на бизнес (часть 5)

2. Скорость выхода на рынок

• Работы по созданию проектных артефактов отнимают меньше времени как за счёт сокращения общего срока, так и за счёт лучшего попадания в задачу.
• Качество дизайна не страдает от ускорения.

Симптомы проблем

• Запуск новых функций и продуктов отнимает много времени и сил.
• Обновления существующих функций происходят редко.
• При запусках и обновлениях страдает качество продукта.

• Непредсказуемое количество итераций по каждой задаче, что затягивает сроки и снижает вовлечённость.
• Перекладывание ответственности за проблемы на других участников продуктовой команды.
• Не хватает дизайнеров или у них нет нужных для продукта навыков.

Способ решения -> паттерн

• О: T-образные специалисты (часть 2)
• О: Карта навыков и их развития (часть 4)
• О: Доверенные аутсорсеры (часть 4)
• Т: Кредит доверия (часть 1)

• О: Планирование (краткосрочное и среднесрочное) (часть 4)
• О: Общий инструментарий (часть 4)
• С: Дизайн-система (часть 3)
• С: Планирование (долгосрочное) (часть 4, 6)

3. Снижение рисков при выходе на рынок

• Пользователи видят ценность нового продукта или функции для себя.
• Пользователи понимают и успешно используют продукт.

Симптомы проблем

• Продукт плохо принимается пользователями, активность в его использовании меньше ожидаемой.

• Принятие решений о том, каким должен быть продукт, происходит несистемно (слепое копирование конкурентов, паническая реакция на отклонение от ожидаемых значений метрик).
• Менеджер продукта и команда не знают, насколько хорошо сработали решения.
• Дизайнеры не имеют влияния на продуктовые решения.

Способ решения -> паттерн

• Т: Поиск альтернативных решений проблемы (часть 5)
• С: Ко-дизайн (часть 4)
• С: Общая дизайн-грамотность (часть 4)

• Т: Ранние прототипы и методы их проверки (часть 5)
• С: Разведочные пользовательские исследования (часть 5)

• Т: Юзабилити-тестирование (часть 5)
• Т: Аналитика и эксперименты (часть 5)
• С: Карта взаимодействия (Customer Journey Map) и оптимизация всех каналов (часть 5)
• С: Метрики дизайна, завязанные на бизнес (часть 5)

4. Увеличение аудитории и прибыли продукта

• Дизайнеры помогают находить удачные решения для сложных продуктовых проблем.
• Дизайнеры предлагают новые возможности для роста продукта, которые попадают в реализацию и приносят измеримую пользу.
• Продукт эффективен и понятен пользователям на всех этапах карты взаимодействия.
• Вся продуктовая команда понимает цели и задачи бизнеса.

Симптомы проблем

• Продукт не приносит прибыли или другой пользы компании.
• Аудитория продукта стагнирует или падает.
• Использование «тёмных паттернов» для увеличения прибыли.
• Неудачные интерфейсные решения снижают эффективность работы пользователей.

• Принятие решений о том, каким должен быть продукт, происходит несистемно (слепое копирование конкурентов, паническая реакция на отклонение от ожидаемых значений метрик).
• Менеджер продукта и команда не знают, насколько хорошо сработали решения.
• Дизайнеры не имеют влияния на продуктовые решения.

Способ решения -> паттерн

• Т: Креативные методики решения проблем (часть 4, 5)
• С: Метрики дизайна, завязанные на бизнес (часть 5)
• С: Разведочные пользовательские исследования для поиска проблем и «окон возможностей» (часть 5)
• С: Сегментация и другие способы оценки важности проблем для пользователей (часть 5)
• С: База знаний об интерфейсе и пользователях (часть 5)

• Т: Уменьшение интерфейсного долга (часть 6)
• С: Ко-дизайн (часть 4)
• С: Карта взаимодействия (Customer Journey Map) и оптимизация всех каналов (часть 5)

• С: Планирование (долгосрочное) (часть 4, 6)

5. Усиление бренда

• Интерфейс продукта усиливает лояльность пользователей к бренду.
• Стоимость компании и привлекательность продукта повышается за счёт качественного дизайна.

Симптомы проблем

• Интерфейс продукта слабо связан с брендом.
• Разные продукты или даже разные экраны одного продукта выглядят и работают по-разному.

• Нет ответственного за развитие бренда.
• Разные подразделения и продукты компании не взаимодействуют друг с другом.

Способ решения -> паттерн

• Т: Дизайн-система (часть 3)
• С: Принципы дизайна, идущие от бренда (часть 3)

• С: Клуб дизайн-лидеров (часть 4)
• С: Общая дизайн-грамотность (часть 4)

6. Найм и развитие дизайнеров

• Нужный специалист по дизайну уже есть или может подключиться к команде в приемлемые сроки.
• Навыки дизайнеров соответствуют задачам компании в текущей и среднесрочной перспективе.
• Дизайн стоит для компании адекватных денег.

Симптомы проблем

• Слабые или даже вредные дизайн-решения.
• Проблемы в интерфейсе не исправляются.

• Не хватает дизайнеров, так что разработчики или менеджеры сами принимают дизайн-решения.
• Компания не может нанять сильных специалистов.
• Высокая текучка и слабая мотивация дизайнеров.

Способ решения -> паттерн

• О: Лидер дизайна (часть 4)
• О: Карта навыков и их развития (часть 4)

• С: HR-бренд

Планирование и отслеживание изменений

0. Портрет компании

• Деньги: Как устроено бюджетирование (сколько дизайнеров можно нанять, есть ли бюджет на пользовательские исследования, бюджет на аутсорс).
• Люди: Соотношение дизайнеров и разработчиков (оптимальные цифры, к которым нужно стремиться).
• Время: В какой момент процесса работы над продуктом привлекаются дизайнеры.
• Кредит доверия: Кому уже продали идею хорошего дизайна (топ-менеджмент, менеджеры продуктов, конечные специалисты (разработчики/тестировщики/маркетологи)).

• Инициация продуктов и их новых возможностей: Какие уровни руководства, на базе какой информации (аналитика/исследования), как требования попадают к дизайнерам, как определяется успешность.
• Дизайн и разработка: Структура команд, процесс, менеджмент.
• Обеспечение качества: Методы, каков приемлемый уровень.
• Дистрибьюция продукта: Каналы, их эффективность и стоимость на пользователя.
• Поддержка пользователей: Каналы, удовлетворённость и CES (Customer Effort Score).

• Тип продукта: Рынок (B2B, B2C или другой), платформа (сайт, приложение или другая).
• Бизнес-модель: Ключевые метрики и как их оптимизировать.
• Стадия жизненного цикла компании и продукта:
  
  1. Поиск подходящего рынка, продуктового решения и бизнес-модели для его монетизации.
  2. Рост пользовательской базы и/или прибыли.
  3. Удержание пользователей.
  4. Эффективность ведения бизнеса.
  5. Вывод продукта из кризиса, когда падают пользовательская база, прибыль или рыночная доля — всё сразу или что-то из них.
  
  

1. Ценность дизайна для бизнеса

2. Интерфейсный и организационный долг

3. Видение будущего дизайна

• Концепты будущего дизайна продуктов.
• Обновлённый бренд и визуальный язык.
• Принципы дизайна для продукта, компании или дизайн-команды.

4. План внедрения

5. Реализация плана

• Чередовать «низковисящие фрукты» с долгосрочными инициативами. Первые будут показывать мгновенный эффект и помогут выиграть время на более сложные изменения, повышая кредит доверия.
• Привязка процессных задач к продуктовым. Изменение лучше упаковывать вместе с реальной задачей по продукту — и проблема выделения времени решится, и на практике проверится.

• Все баги и идеи по дизайну зафиксированы в Jira
• Исправлен как минимум 1 баг на каждом из продуктов

• На уровне макетов:
  
  • Чек-листы для проверки дизайна
  • «Свежий взгляд»: Проверка макетов одного дизайнера другим
  • Design Review всей командой
  
  
• Перед выкаткой:
  
  • Design Review в Jira: Мобильные приложения
  • Design Review в Jira: Маркетинг
  
  
• После выкатки:
  
  • Дизайнеры включены в рассылки о всех выкатках
  • Перевести все баги в Jira
  • Повторный Design Review продуктов каждый квартал
  • Задачи из Design Review попадают в продуктовый план
  • Инструкция о том, как описывать проблемы в ходе Design Review
  • Design Review после выкаток
  
  

• Стена будущего. Она показывает беклог интерфейсного и организационного долга, а также OKR в виде канбана.
• Письма команде. Рассказ о текущих проблемах и планах по их решению.

Как меняется дизайн в известных компаниях

Критерии современной компании, ценящей дизайн

Исследования Leah Buley

• Единый подход к дизайну по всей карте взаимодействия, не только цифровой части продукта (поддержка пользователей, офлайновые магазины и мероприятия, упаковка, «железо»).
• Корпоративная, бренд- и UX-стратегия связаны.
• Участие в определении продуктового плана.
• Влияние на широкий спектр метрик с чётким пониманием отдачи от добротных дизайн-решений в деньгах.
• Среднесрочное (как выпустить текущую версию) и долгосрочное видение продукта (его идеальное состояние).
• Соотношение дизайнеров и разработчиков. Само по себе количество голов ни о чем не говорит, но такие цифры могут быть ещё одним индикатором зрелости. У лучших компаний отмечается 1:4, а абсолютный минимум для гармоничного развития — 1:12.
• «Часы налёта» наблюдения за пользователями для всех участников продуктовой команды.

Nielsen/Norman Group

John Maeda

Другие модели изменений

«Адаптивный дизайн»

DesignX

Intuit

Jeffrey Onken

Justinmind

Kotter International

Leah Buley

• упрощённую, когда ярлык «стратегия» навешивается достаточно прозаичное планирование будущего продукта;
• полноценную, когда речь идёт о принесении пользы бизнесу через дизайн в широкой сфере приложений и организационных изменениях.

OPPOSITE

• Ориентация (Orientation) — Определить видение будущего, несущего осмысленные изменения.
• Люди (People) — Понимание ценности для пользователей, их ожиданий и поведения.
• Процессы (Processes) — Оценить оперативную инфраструктуру и обновить технологии, процессы и внутренние правила для поддержки изменений.
• Цели (Objectives) — Определить цели цифровой трансформации, объединив всех принимающих решения вокруг нового видения и его плана внедрения.
• Структура (Structure) — Сформировать выделенную команду с ясно очерченными ролями, ответственностью, целями и способами оценки.
• Инсайты и намерения (Insights & Intent) — Собрать данные и использовать инсайты для уточнения стратегии эволюции.
• Технологии (Technology) — Перестроить фронт- и бек-энд для обеспечения единого интегрированного UX.
• Внедрение (Execution) — Внедрять, получать обратную связь и корректировать направление трансформации.

Rosa Wu и Jess McMullin

1. Найти партнёров среди топ-менеджмента, а после этого показать им ценность дизайна. Они станут спонсорами и евангелистами дизайна в компании.
2. Запустить пилотный проект, который даст быстрые победы и покажет ценность дизайна на практике с минимальными рисками.
3. Широко рассказать об успехе, чтобы все продукты и подразделения компании также увидели ценность дизайна на практике.

Salesforce V2MOM

• Видение (Vision) — Чего хочется достичь?
• Ценности (Values) — Что важного в этой цели?
• Методы (Methods) — Как достичь её?
• Препятствия (Obstacles) — Что может помешать?
• Метрики (Measures) — Как определить, что цель достигнута?

Toyota Kata и Kaizen

1. Понимая видение будущего или общее направление изменений...
2. Оценить текущую ситуацию.
3. Определить следующую целевую ситуацию.
4. Итеративно двигаться в сторону нового состояния, что позволяет постепенно находить и решать заранее неизвестные препятствия.

Кейсы

Accenture и Fjord

Citrix

Coca-Cola

Eventbrite

Ford

Google

IBM

Intuit

private IEnumerator CheckEmotions()
{
    EmotionService emoServ = new EmotionService(SubscriptionKeys.Instance.EmotionsApiKey);
    while (true)
    {
         yield return new WaitForEndOfFrame();
         yield return emoServ.GetEmoInfoCoroutine(_WebCam.Screenshot);
         var emotions = emoServ.LastEmotions;
         if (emotions != null)
         {
              _MaxEmotionValue.text = GetMaxEmotionOnScreenshot(emotions);
         }
         yield return new WaitForSeconds(DELAY);
     }
}

private IEnumerator CreateRecognizeRequestAndSaveResponseCoroutine(
           string contentHeader, 
           byte[] data)
{
    Dictionary headers = new Dictionary();
    headers.Add(Constants.SUB_KEY_HEADER, _SubscriptionKey);
    headers.Add(Constants.CONTENT_TYPE_HEADER, contentHeader);
    WWW request = new WWW(_RecognizeRequestUrl, data, headers);
    yield return new WaitUntil(() => request.isDone);
    ParseEmotionsFromJson(request.text);
}

private void CreateRecognizeRequest()
{
    Clear();
    _Thread = new Thread(Run);
    _Thread.Start(); 
}
private void Run()
{
    WebHeaderCollection headers = new WebHeaderCollection();
    headers.Add(Constants.SUB_KEY_HEADER, _SubscriptionKey);
    var request = HttpWebRequest.Create(_RecognizeRequestUrl);
    request.ContentType = _ContentHeader;
    request.Headers = headers;
    request.ContentLength = _Data.Length;
    request.Method = WebRequestMethods.Http.Post;
    var dataStream = request.GetRequestStream();
    dataStream.Write(_Data, 0, _Data.Length);
    dataStream.Close();
    var response = request.GetResponse();
    dataStream = response.GetResponseStream();
    StreamReader reader = new StreamReader(dataStream);
    string responseString = reader.ReadToEnd();

    reader.Close();
    dataStream.Close();
    response.Close();
    Debug.Log(responseString);
    if (!TryParseEmotionsFromJson(responseString))
    {
        Run();
    }
    else
    {
        _IsDataReady = true;
    }
}

Unity Moscow Meetup #3

Об авторе

https://habrahabr.ru/post/329866/

Что такое Panda Remote Control

Заключение

https://habrahabr.ru/post/329862/

Предыстория CNI

CNI ближе к Kubernetes с философской точки зрения. Он гораздо проще CNM, не требует демонов и его кроссплатформенность по меньшей правдоподобна (исполняемая среда контейнеров CoreOS rkt поддерживает его) [… а Kubernetes стремится поддерживать разные реализации контейнеров — прим. перев.]. Быть кроссплатформенным означает возможность использования сетевых конфигураций, которые будут одинаково работать в разных исполняемых средах (т.е. Docker, Rocket, Hyper). Этот подход следует философии UNIX делать одну вещь хорошо.

Устройство CNI

{
  "cniVersion": "0.3.1",
  "name": "dbnet",
  "type": "bridge",
  "bridge": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.1.0.0/16",
    "gateway": "10.1.0.1"
  },
  "dns": {
    "nameservers": [ "10.1.0.1" ]
  }
}

Быстро попробовать CNI

$ cat > mybridge.conf <<"EOF"
{
    "cniVersion": "0.2.0",
    "name": "mybridge",
    "type": "bridge",
    "bridge": "cni_bridge0",
    "isGateway": true,
    "ipMasq": true,
    "ipam": {
        "type": "host-local",
        "subnet": "10.15.20.0/24",
        "routes": [
            { "dst": "0.0.0.0/0" },
            { "dst": "1.1.1.1/32", "gw":"10.15.20.1"}
        ]
    }
}
EOF
$ sudo ip netns add 1234567890
$ sudo CNI_COMMAND=ADD CNI_CONTAINERID=1234567890 \
 CNI_NETNS=/var/run/netns/1234567890 CNI_IFNAME=eth12 \
 CNI_PATH=`pwd` ./bridge 64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:536 (536.0 B)  TX bytes:648 (648.0 B)
…

Сторонние плагины для CNI

• Project Calico (виртуальная сеть L3, интегрированная с инструментами оркестровки и облачными платформами);
• Weave (простая сеть для multi-host Docker-инсталляций);
• Contiv Netplugin (политики/ACL/QoS и другие возможности для контейнеров в кластерных установках типа multi-host);
• Flannel (сетевая фабрика для контейнеров от CoreOS);
• SR-IOV, Cilium (BPF/XDP), Multus (плагин Multi для Kubernetes от Intel), VMware NSX и другие…

Заключение

https://habrahabr.ru/post/329830/

Только что натолкнулся на возможность Postgresql, показавшуюся мне забавной.
Для кого "боян" — респект вам, я несколько лет работаю с Postgres и до сих пор не натыкался на такую штуку.

select; без указания полей, таблицы и условий возвращает одну строку.
Но у этой строки нет полей:

=> select;
--
(1 row)

Для сравнения:

=> select null;
 ?column? 
----------

(1 row)
=> select null where 0=1;
 ?column? 
----------
(0 rows)

А сможем ли мы создать таблицу из такого "пустого" запроса? Таблицу без полей.

Да пожалуйста:

=> create table t as select;
SELECT 1
=> \d+ t
                          Table "t"
 Column | Type | Modifiers | Storage | Stats target | Description 
--------+------+-----------+---------+--------------+-------------
=> select * from t;
--
(1 row)

А можем ли мы в неё вставить?
Легко:

=> insert into t select;
INSERT 0 1
=> insert into t select;
INSERT 0 1
=> select * from t;
--
(3 rows)
=> select count(*) from t;
 count 
-------
     3

ЕЩЕ!

=> insert into t select from generate_series(1,1000000);
INSERT 0 1000000

Интересно, будет ли Postgresql сканировать такую таблицу?

=> explain analyze select * from t;
                                                 QUERY PLAN                                                 
------------------------------------------------------------------------------------------------------------
 Seq Scan on t  (cost=0.00..13438.67 rows=1000167 width=0) (actual time=0.018..96.389 rows=1000003 loops=1)
 Planning time: 0.024 ms
 Execution time: 134.654 ms
(3 rows)

Да, честно сканирует. Больше 100 ms — вполне себе заметное время.
Ну и чтобы убедиться, что всё по честному, посмотрим сколько места занимает наша супер-полезная таблица:

=> select pg_size_pretty(pg_total_relation_size('t'));
 pg_size_pretty 
----------------
 27 MB
(1 row)

То есть таблица есть, занимает место на диске, в блоках хранятся разные служебные данные, ну а то, что в ней нет полей — бывает, дело житейское!

=> select t.xmin, t.ctid from t limit 10;
  xmin   |  ctid  
---------+--------
 1029645 | (0,1)
 1029647 | (0,2)
 1029648 | (0,3)
 1029649 | (0,4)
 1029649 | (0,5)
 1029649 | (0,6)
 1029649 | (0,7)
 1029649 | (0,8)
 1029649 | (0,9)
 1029649 | (0,10)
(10 rows)

Я не придумал, зачем может понадобиться такая таблица. Но возможность есть, и это хорошо!

https://habrahabr.ru/post/329856/

https://habrahabr.ru/post/329854/

1. Подключение клавиатуры Digilent Pmod KYPD

module kypd_decoder(
                input 		      i_clk,
                input 		      i_rst_n,
                input          [3:0]  i_row,

                output reg     [3:0]  o_col,
                output reg     [3:0]  o_number
              );
	  
                reg            [19:0] counter;
                reg            [3:0]  col;
                reg            [3:0]  row;
                
                        //  row col
parameter   ZERO       = 8'b11100111,
            ONE        = 8'b01110111,
            TWO        = 8'b01111011,
            THREE      = 8'b01111101,
            FOUR       = 8'b10110111,
            FIVE       = 8'b10111011,
            SIX        = 8'b10111101,
            SEVEN      = 8'b11010111,
            EIGHT      = 8'b11011011,
            NINE       = 8'b11011101,
            A          = 8'b01111110,
            B          = 8'b10111110,
            C          = 8'b11011110,
            D          = 8'b11101110,
            E          = 8'b11101101,
            F          = 8'b11101011;


always @(posedge i_clk or negedge i_rst_n)
	if (i_rst_n == 0)
	   counter <= 20'b0;	   
	else
	   counter <= counter + 1'b1;


always @(posedge i_clk or negedge i_rst_n)
	if (i_rst_n == 1'b0) begin
	   
	   o_col <= 4'b1110;
	   col 	 <= 4'b1110;
	   row   <= 4'b1111;
	
	end else if (!counter) begin
    
       o_col <= {o_col [0], o_col [3:1]};
       col   <= o_col;
       row   <= i_row;
	
	end

always @(posedge i_clk or negedge i_rst_n)
	if (i_rst_n == 0)
		o_number <= 4'b0;
	else
		case ({row, col})
	
			ZERO:    o_number <= 4'h0;
			
			ONE:     o_number <= 4'h1;
			
			TWO:     o_number <= 4'h2;
			
			THREE:   o_number <= 4'h3;
			
			FOUR:    o_number <= 4'h4;
			
			FIVE:    o_number <= 4'h5;
			
			SIX:     o_number <= 4'h6;
			
			SEVEN:   o_number <= 4'h7;
			
			EIGHT:	 o_number <= 4'h8;
			
			NINE:	 o_number <= 4'h9;
			
			A:	 o_number <= 4'hA;
			
			B:	 o_number <= 4'hB;
			
			C:	 o_number <= 4'hC;
			
			D:       o_number <= 4'hD;
			
			E:       o_number <= 4'hE;
			
			F:       o_number <= 4'hF;
	
	
		endcase
		
endmodule

//`define MFP_DEMO_LIGHT_SENSOR

`define MFP_PMOD_KYPD

`ifdef MFP_DEMO_LIGHT_SENSOR

`ifdef MFP_PMOD_KYPD
      kypd_decoder kypd_decoder
                      (                  
                          .i_clk    (   SI_ClkIn         ),
                          .i_rst_n  (   KEY_0            ),
                          .o_col    (   KYPD_DATA [3:0]  ),
                          .i_row    (   KYPD_DATA [7:4]  ),   
                          .o_number (   KYPD_OUT         )
                      );
`endif

`ifdef MFP_PMOD_KYPD
            .KYPD_OUT    (    KYPD_OUT      ),    
`endif

`ifdef MFP_PMOD_KYPD
            wire [3:0] KYPD_OUT;
`endif

`ifdef MFP_PMOD_KYPD
             input [3:0] KYPD_OUT,
`endif

`ifdef MFP_PMOD_KYPD
            .KYPD_OUT    (    KYPD_OUT      ),    
`endif

`ifdef MFP_PMOD_KYPD
             input [3:0] KYPD_OUT,
`endif

`ifdef MFP_PMOD_KYPD
            .KYPD_OUT    (    KYPD_OUT      ),    
`endif

`ifdef MFP_PMOD_KYPD
             input [3:0] KYPD_OUT,
`endif

`ifdef MFP_PMOD_KYPD
            `MFP_PMOD_KYPD_IONUM  : HRDATA <= { 28'b0,    KYPD_OUT };
`endif

`ifdef MFP_PMOD_KYPD
`define MFP_PMOD_KYPD_ADDR          32'h1f800018
`endif

`ifdef MFP_PMOD_KYPD            
`define MFP_PMOD_KYPD_IONUM         4'h6
`endif

     `ifdef MFP_PMOD_KYPD
     inout [7:0] KYPD_DATA,
     input KEY_0,
    `endif

        `ifdef MFP_PMOD_KYPD
    	.KYPD_DATA		  (     JA           ),
	.KEY_0                    (     ~ i_btn1     ),
        `endif

module cmoda7
(
...
...
...
   inout  [ 7:0] JA
);

## Pmod Header JA
set_property -dict {PACKAGE_PIN G17 IOSTANDARD LVCMOS33} [get_ports {JA[0]}]
set_property -dict {PACKAGE_PIN G19 IOSTANDARD LVCMOS33} [get_ports {JA[1]}]
set_property -dict {PACKAGE_PIN N18 IOSTANDARD LVCMOS33} [get_ports {JA[2]}]
set_property -dict {PACKAGE_PIN L18 IOSTANDARD LVCMOS33} [get_ports {JA[3]}]
set_property -dict {PACKAGE_PIN H17 IOSTANDARD LVCMOS33} [get_ports {JA[4]}]
set_property -dict {PACKAGE_PIN H19 IOSTANDARD LVCMOS33} [get_ports {JA[5]}]
set_property -dict {PACKAGE_PIN J19 IOSTANDARD LVCMOS33} [get_ports {JA[6]}]
set_property -dict {PACKAGE_PIN K18 IOSTANDARD LVCMOS33} [get_ports {JA[7]}]

//`define MFP_DEMO_LIGHT_SENSOR

`ifdef MFP_DEMO_LIGHT_SENSOR
...
`endif 

#define MFP_PMOD_KYPD_ADDR      0xBF800018
и
#define MFP_PMOD_KYPD           (* (volatile unsigned *) MFP_PMOD_KYPD_ADDR     )

#include "mfp_memory_mapped_registers.h"

int main ()
{
    int n = 0;

    for (;;)
    {
        MFP_7_SEGMENT_HEX = MFP_PMOD_KYPD;
    }

    return 0;
}

02_compile_and_link

08_generate_motorola_s_record_file

11_check_which_com_port_is_used

set a=7 
mode com%a% baud=115200 parity=n data=8 stop=1 to=off xon=off odsr=off octs=off dtr=off rts=off idsr=off type program.rec >\.\COM%a%

12_upload_to_the_board_using_uart

https://habrahabr.ru/post/329852/

https://habrahabr.ru/post/329580/

Ни одна парадигма

Культ красоты кода

class Project < ApplicationRecord
  belongs_to :account
  has_many :participants, class_name: 'Person'
  validates_presence_of :name
end

class CreateAccounts < ActiveRecord::Migration
  def change
    create_table :accounts do |t|
      t.integer :queenbee_id
      t.timestamps
    end
  end
end

if people.include? person
      …
if person.in? people

Острые лезвия

https://habrahabr.ru/post/329844/

Не (только) кубики

DevOps конструктор Amazon AWS

AWS CodeCommit

как выглядит

AWS CodeBuild

как выглядит

Specify a Docker image

AWS CodeBuild as Test provider

AWS CodeDeploy

AWS CodePipeline

как выглядит

AWS CodeStar

как выглядит

Шаблоны AWS CodeStar

IaaC-сервисы Amazon AWS

• Elastic Beanstalk
• OpsWorks
• CloudFormation

AWS Lambda

• Accelerating DevOps Pipelines with AWS: Video, Presentation

https://habrahabr.ru/post/329840/

О докладчиках

• «Excelsior JET: обзор возможностей» (JUG.ru-2013: презентация, видео; с Павлом Павловым)
• «Excelsior JET: внутренняя архитектура» (JUG.ru-2013: презентация, видео; с Павлом Павловым)
• «Занимательные истории из жизни техподдержки JVM» (Joker 2013: презентация, видео; с Мишей Быковым)
• «Ahead-of-time компиляция» (Joker 2014: презентация, видео)
• «AOT компиляция» (JavaDay Kiev 2014: презентация, видео)
• «Java худеет. Уменьшение размера дистрибутива Java приложения без зависимостей» (JavaDay Kiev 2014: презентация, видео)
• «Круглый стол. Рефакторинги и технический долг» (JPoint 2015: видео)
• «Круглый стол. Будущее Java-платформы» (JPoint 2015: видео)
• «Клиентская Java вне браузера: делаем нативные клиенты на Java» (Joker 2015: презентация, видео)
• «JVM: краткий курс общей анатомии» (Joker 2015 University Day: презентация, видео; с Владимиром Парфиненко)
• «Delivering Native User Experience in Client-Side Java Applications» (JEEConf 2015: презентация, видео)
• «Поддержка Java 8 в Excelsior JET» (JBreak 2016: презентация, видео)
• «Поддержка Java 8 в Excelsior JET» (JPoint 2016: презентация, видео)
• «JVM: краткий курс общей анатомии» (JPoint 2016 Student Day: презентация, видео; с Владимиром Ивановым)
• «Java AOT compilation» (GeekOUT 2016: видео)
• «Поддержка Java 8 на уровне JVM» (JET Conference Autumn 2016: презентация, видео)
• «Java AOT Compilation» (JavaZone 2016: видео)
• «Верификация Java байт-кода: когда, как, а может отключить?» (JPoint 2017: презентация, видео пока доступно только для участников конференции)
• «JIT vs. AOT: Unity And Conflict of Dynamic and Static Compilers for Java» (Riga DevDays 2017, GeeCON 2017: презентация)
• «Java 9 Модули. Почему не OSGi?» (Oracle Code 2017 Moscow: презентация)

• Выпуск 134 подкаста «Разбор полётов»

• «Новинки в java.util.concurrent» (JUG.ru-2013: видео)
• «Обзор нововведений в java.util.concurrent (JSR166e)» (JEEConf 2013: презентация, видео)
• «Java Mission Control» (Java 8 Launch 2014: видео)
• «Быстрая загрузка ваших классов» (JUG.ru-2015: видео)
• «CompletableFuture. Хочется взять и применить» (JUG.ru-2015: видео)
• «CompletableFuture уже здесь» (JPoint 2015: видео)
• «Completable Future уже здесь» (JEEConf 2015: презентация, видео)
• «Hotspot и AOT» (JBreak 2016: видео)
• «Hotspot и AOT: Пришло время компилировать» (JPoint 2016: презентация, видео)
• «Чёрная метка, StampedLock и его друзья. Как не нарушить пиратский кодекс» (JPoint 2016 Student Day: видео)
• «Hotspot & AOT» (JEEConf 2016: видео)
• «Ahead-of-Time компиляция для HotSpot JVM» (JUG.ru-2016: презентация, видео)
• «Compile ahead of time. It’s fine?» (GeeCON 2017, JEEConf 2017: презентация)

О докладах

https://habrahabr.ru/post/329728/

https://habrahabr.ru/post/329824/