Небольшая предыстория

• 47 различных экранов;
• ~50 shapes и selectors;
• ~70 разных цветов (одни элементы могут иметь градиент и рамку, другие – специфичны для конкретного экрана).

1. В каждой Activity написать код, который будет перекрашивать UI (решение в лоб, всем Views назначаются id и в каждой Activity программно задаются цвета).
2. Наследование от всех используемых UI элементов (развитие первого решения, исключающее внесение изменений в Activity, за место этого переписываются xml).
3. Обертка над Resources или над чем-нибудь еще, что позволило бы реализовать требуемую задачу во время создания View или Shape.

Эксперимент номер один. Попытка завернуть Resources

Теперь о класс Resources

Эксперимент номер два

1. Замена ресурсов в View.
2. Замена ресурсов в Shape и Selector.

O View. Подмена LayoutInflater

О Shape

Еще немного о кэше ресурсов

Результат

1. Свой собственный LayoutInflater, который вносит изменения в View.
2. Великий Singletone с набором методов вида getDrawable(int resId, Resources baseResource), который занимается хранением цветовой схемы, Drawables и ColorStateLists.
3. Базовая активность, содержащая перекраску статус бара и оборачивание контекста.

https://habrahabr.ru/post/334010/

• Барух Садогурский (JFrog)
• Олег Анастасьев (Одноклассники)
• Алексей Акопян (Dell EMC)
• Кирилл Толкачёв (Альфа-Лаборатория)
• Александр Тарасов (Одноклассники)

https://habrahabr.ru/post/333916/

https://habrahabr.ru/post/334000/

https://habrahabr.ru/post/334008/

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

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

Оглавление

• Docker Swarm и Overlay-сети
  
  • Overlay
    
    • vxlan
    • Шифрование
    • Инспектирование интерфейсов vxlan-туннелей
  • ingress
  • Docker_gwbridge
• Заключение
• Ссылки/ресурсы

Docker Swarm и Overlay-сети

Overlay-сети используются в контексте кластеров (Docker Swarm), где виртуальная сеть, которую используют контейнеры, связывает несколько физических хостов, на которых запущен Docker. Когда вы запускаете контейнер на swarm-кластере (как часть сервиса), множество сетей присоединяется по умолчанию, и каждая из них соответствует разным требованиям связи.

Например, у меня есть 3 ноды docker swarm кластера:

Для начала я создам overlay-сеть под названием my-overlay-network:

Затем запущу сервис с контейнером, на котором запущен простой веб-сервер, который смотрит портом 8080 во внешний мир. Этот сервис будет иметь 3 реплики, и я отмечу, что он связан только с одной сетью (my-overlay-network):

Если затем вывести список всех интерфейсов, доступных любому запущенному контейнеру, то их будет 3. В то же время, если запустить контейнер на одном хосте, то можно ожидать только 1 интерфейс:

Контейнер связан с my-overlay-network через eth2, что можно понять по IP-адресу. eth0 и eth1 связаны с другими сетями. Если запустить docker network ls, то можно увидеть 2 дополнительные сети, которые добавились: docker_gwbridge и ingress, а по адресам подсетей можно понять, что они привязаны к eth0 и eth1:

Overlay

Overlay-сеть создает подсеть, которую могут использовать контейнеры в разных хостах swarm-кластера. Контейнеры на разных физических хостах могут обмениваться данными по overlay-сети (если все они прикреплены к одной сети).

Например, для веб-приложения, которое мы запустили, можно увидеть по одному контейнеру на каждом хосте в swarm-кластере:

Я могу получить overlay IP-адрес для каждого контейнера при помощи команды ifconfig eth2 (eth2 — это интерфейс, присоединенный к overlay-сети).

На swarm01:

Потом с контейнера на swarm02 у меня должна быть возможность пингануть 10.10.10.5 (IP контейнера на swarm01):

vxlan

Overlay-сеть использует технологию vxlan, которая инкапсулирует layer 2 фреймы в layer 4 пакеты (UDP/IP). При помощи этого действия Docker создает виртуальные сети поверх существующих связей между хостами, которые могут оказаться внутри одной подсети. Любые точки, которые являются частью этой виртуальной сети, выглядят друг для друга так, будто они связаны поверх свича и не заботятся об устройстве основной физической сети.

Чтобы увидеть этот процесс в действии, можно сделать захват трафика на хостах, которые являются частью overlay-сети. В последнем примере захват трафика на swarm01 или swarm02 выявит icmp-трафик между контейнерами, которые на них запущены (vxlan использует udp port 4789):

В этом примере в пакетах можно видеть два слоя. Первый — это туннельный трафик udp vxlan между хостами по порту 4789, а внутри можно увидеть второй — icmp трафик с IP-адресами контейнера.

Шифрование

Захват трафика в этом примере показал, что если ты видишь трафик между хостами, то увидишь и трафик внутри контейнеров, проходящий по overlay-сети. Именно поэтому в Docker есть опция шифроования. Можно запустить автоматическое IPSec-шифрование vxlan-туннелей, просто добавив --opt encrypted при создании сети.

Если запустить такой же тест, но с использованием зашифрованной overlay-сети, то можно увидеть только зашифрованные пакеты между хостами:

Инспектирование интерфейсов vxlan-туннелей

Как и bridge-сети, Docker создает bridge-интерфейс для каждой overlay-сети, который соединяет виртуальные туннельные интерфейсы, выполняющие vxlan туннельную связь между хостами. Впрочем, эти туннельные интерфейсы (bridge и vxlan) создаются не напрямую на туннельном хосте. Они находятся в разных контейнерах, которые Docker запускает для каждой создаваемой overlay-сети.

Чтобы действительно проинспектировать эти интерфейсы, надо использовать nsenter для запуска команд внутри сети контейнера, который управляет туннелями и виртуальными интерфейсами. Эту команду надо запустить на хостах с контейнерами, которые участвуют в overlay-сети.

Также надо отредактировать /etc/systemd/system/multi-user.target.wants/docker.service на хосте и закомментировать MountFlags=slave по инструкции из этого обсуждения.

Наконец, если запустить захват трафика на veth-интерфейсе, то мы увидим трафик, который покидает контейнер, но до того, как он будет направлен в vxlan туннель (упомянутый выше пинг все еще работает):

ingress

Вторая сеть, к которой были присоединены контейнеры, — это сеть ingress. Это overlay-сеть, но она устанавливается по умолчанию сразу после запуска swarm-кластера. Эта сеть отвечает за связи, которые устанавливаются с контейнерами со стороны внешнего мира. Также именно в ней происходит балансировка нагрузки, которую предоставляет swarm-кластер.

Балансировку нагрузки выполняет IPVS в контейнере, который Docker swarm запускает по умолчанию. Можно увидеть, что этот контейнер прикреплен к ingress-сети (я использовал тот же веб-сервис, что и раньше: он раскрывает порт 8080, который прикрепляется к порту 80 в контейнерах):

Для начала, взглянем на хост — на любой хост, который участвует в swarm-кластере:

Здесь мы видим правило, по которому трафик, предназначенный для порта 8080, перенаправляется по адресу 172.19.0.2. Этот адрес принадлежит контейнеру ingress-sbox, если проинспектировать его интерфейсы, то мы получим слещующее:

Docker использует mangle-правила iptables, чтобы назначить определенный номер пакетам для порта 8080. IPVS будет использовать этот номер, чтобы балансировать нагрузку в подходящие контейнеры:

Как Docker swarm использует iptables и IPVS для балансировки нагрузки контейнеров, можно более детально изучить по видеоролику Deep Dive into Docker 1.12 Networking.

Docker_gwbridge

Наконец, поговорим о сети docker_gwbridge. Это bridge-сеть с соответствующим интерфейсом под названием docker_gwbridge, который создается на каждом хосте swarm-кластера. Сеть docker_gwbridge соединяет трафик из контейнеров swarm-кластера с внешним миром. Например, такой трафик получится, если мы направим запрос в Google.

Не буду вдаваться в подробности, поскольку bridge-сети я уже в деталях рассмотрел в предыдущей статье.

Заключение

Контейнер, запущенный на swarm-кластере, по умолчанию может быть соединён с тремя и более сетями. Первая сеть, docker_gwbridge, позволяет контейнерам поддерживать связь с внешним миром. Сеть ingress нужна только для того, чтобы устанавливать входящие соединения из внешнего мира. И, наконец, сети overlay: их создает сам пользователь и их можно прикрепить к контейнерам. Эти сети служат общей подсетью для контейнеров единой сети, в которой они могут обмениваться данными напрямую (даже если они запущены на разных физических хостах).

Также существуют пространства разных сетей, которые создаются по умолчанию на swarm-кластере. Эти пространства помогают управлять vxlan-туннелями для overlay-сетей и правилами балансировки нагрузки для входящих связей.

Ссылки/ресурсы

• Deep dive into Docker Networking (видео)
• Overlay networking and swarm mode
• Docker Swarm overlay security

https://habrahabr.ru/post/334004/

https://habrahabr.ru/post/333610/

Настройка сервера

apt install pptpd

localip 10.0.0.1
remoteip 10.0.0.100-200

# client server secret IP addresses
orange pptpd pass123 10.0.0.100

ms-dns 8.8.8.8
ms-dns 8.8.4.4

service pptpd restart

net.ipv4.ip_forward = 1

~$ ifconfig
	ens3 Link encap:Ethernet HWaddr 52:54:00:f8:0c:4a 
	inet addr:31.148.99.234 Bcast:31.148.99.255 Mask:255.255.255.0
	inet6 addr: fe80::5054:ff:fef8:c4a/64 Scope:Link
	UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
	RX packets:8808733 errors:0 dropped:0 overruns:0 frame:0
	TX packets:3300625 errors:0 dropped:0 overruns:0 carrier:0
	collisions:0 txqueuelen:1000 
	RX bytes:3511383831 (3.5 GB) TX bytes:3245380453 (3.2 GB)

	lo Link encap:Local Loopback 
	inet addr:127.0.0.1 Mask:255.0.0.0
	inet6 addr: ::1/128 Scope:Host
	UP LOOPBACK RUNNING MTU:65536 Metric:1
	RX packets:216 errors:0 dropped:0 overruns:0 frame:0
	TX packets:216 errors:0 dropped:0 overruns:0 carrier:0
	collisions:0 txqueuelen:1 
	RX bytes:16618 (16.6 KB) TX bytes:16618 (16.6 KB)

iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE && iptables-save

iptables --table nat --append POSTROUTING --out-interface ppp0 -j MASQUERADE
iptables -I INPUT -s 10.0.0.0/8 -i ppp0 -j ACCEPT
iptables --append FORWARD --in-interface ens3 -j ACCEPT

Настройка локального сервера

apt install pptp-linux

pty "pptp 31.148.99.234 --nolaunchpppd"
name orange
password pass123
remotename PPTP
require-mppe-128

lock
noauth
nobsdcomp
nodeflate
defaultroute
replacedefaultroute
mtu 1400
persist
maxfail 0
lcp-echo-interval 20
lcp-echo-failure 3

pon pptpserver

~$ ifconfig ppp0
	ppp0 Link encap:Point-to-Point Protocol 
	inet addr:10.0.0.100 P-t-P:10.0.0.1 Mask:255.255.255.255
	UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1496 Metric:1
	RX packets:1075 errors:0 dropped:0 overruns:0 frame:0
	TX packets:959 errors:0 dropped:0 overruns:0 carrier:0
	collisions:0 txqueuelen:3 
	RX bytes:154176 (154.1 KB) TX bytes:194499 (194.4 KB)

~$ ping 10.0.0.100
	PING 10.0.0.100 (10.0.0.100) 56(84) bytes of data.
	64 bytes from 10.0.0.100: icmp_seq=1 ttl=64 time=8.91 ms
	64 bytes from 10.0.0.100: icmp_seq=2 ttl=64 time=8.80 ms
	64 bytes from 10.0.0.100: icmp_seq=3 ttl=64 time=8.93 ms
	64 bytes from 10.0.0.100: icmp_seq=4 ttl=64 time=9.00 ms

Проброс портов

iptables -t nat -A PREROUTING -p tcp -d 31.148.99.234 --dport 80 -j DNAT --to-destination 10.0.0.100:80
iptables -A FORWARD -i ppp0 -d 10.0.0.100 -p tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -d 31.148.99.234 --dport 443 -j DNAT --to-destination 10.0.0.100:443
iptables -A FORWARD -i ppp0 -d 10.0.0.100 -p tcp --dport 443 -j ACCEPT

Маленькие доработки

#!/bin/sh
while [ 0 ]
do
 if ifconfig ppp0>>/dev/null
 then
  sleep 7
 else
  pon pptpserver
  if $?
  then
   echo $(date) Connected
  else
   echo $(date) Connection error
  fi
 fi
 sleep 3
done

/root/scripts/ppp.sh

chmod +x /root/scripts/ppp.sh

Итог

Ссылки на используемые ресурсы

https://habrahabr.ru/post/333996/

Управление контактами

• PeopleModel;
• PeopleNameGroupModel;
• PeopleVCardModel;
• Person.

• firstName — имя контакта;
• lastName — фамилия контакта;
• favorite — true, если контакт помечен как «избранный», false — в противном случае;
• avatar — путь до изображения с аватаром контакта на устройстве;
• contactId — идентификатор контакта в базе данных устройства;
• phoneNumbers — список номеров телефонов контакта;
• emailDetails — информация об электронных адресах;
• person — объект типа Person, содержащий больше информации о контакте.

• id — идентификатор записи в базе данных;
• firstName — имя контакта;
• lastName — фамилия контакта;
• middleName — отчество контакта;
• companyName — название компании, где работает контакт;
• role — должность контакта в компании;
• department — отдел компании, где работает контакт;
• favorite — true, если контакт помечен как «избранный», false — в противном случае;
• avatar — путь до изображения с аватаром контакта на устройстве;
• phoneNumbers — список номеров телефонов контакта;
• emailDetails — информация об электронных адресах;
• addressDetails — информация об адресе проживания;
• birthday — дата рождения контакта.

...
# Runtime dependencies which are not automatically detected
Requires:
  - sailfishsilica-qt5 >= 0.10.9
  - nemo-qml-plugin-contacts-qt5
...

import org.nemomobile.contacts 1.0

PeopleModel {
    id: peopleModel
    filterType: PeopleModel.FilterAll
    requiredProperty: PeopleModel.PhoneNumberRequired
}
SilicaListView {
    anchors.fill: parent
    header: PageHeader {title: qsTr("Contacts")}
    model: peopleModel
    delegate: ListItem {
        width: parent.width
        Column {
            width: parent.width
            Label {text: firstName + " " + lastName}
            Label {text: qsTr("Phone numbers: ") + phoneNumbers.join(", ")}
        }
    }
}

Управление событиями календаря

• AgendaModel;
• CalendarEvent;
• CalendarEventModification;
• Calendar.

AgendaModel {
    id: agendaModel
    startDate: new Date()
    endDate: new Date(2018, 0)
}

• displayLabel — название события;
• description — описание события;
• startTime — время начала события;
• endTime — время окончания события;
• allDay — true, если событие помечено как событие на «весь день»;
• location — место проведения мероприятия;
• color — цвет, которым помечается событие в календаре;
• uniqueId — уникальный идентификатор события в базе данных.

• CalendarEventModification createNewEvent();
• CalendarEventModification createModification(CalendarEvent event);
• void remove(string uniqueId).

Calendar.createNewEvent();
Calendar.createModification(event);
Calendar.remove(event.uniqueId);

...
# Runtime dependencies which are not automatically detected
Requires:
  - sailfishsilica-qt5 >= 0.10.9
  - nemo-qml-plugin-calendar-qt5
...

import org.nemomobile.calendar 1.0

AgendaModel {
    id: agendaModel
    startDate: new Date() 
    endDate: new Date(2018, 0)
}
SilicaListView {
    anchors.fill: parent
    header: PageHeader { title: qsTr("Calendar events") }
    model: agendaModel
    delegate: ListItem {
        width: parent.width
        contentHeight: column.height
        Column {
            id: column; 
            width: parent.width
            Label { text: eventDateTimeToString(event) }
            Label { text: event.displayLabel }
            Label { text: qsTr("Location: ") + event.location }
        }
    }
}
function eventDateTimeToString(event) {
    return Qt.formatTime(event.startTime, "HH:mm") + " – " 
           + Qt.formatTime(event.endTime, "HH:mm") + "\t" 
           + Qt.formatDate(event.startTime, Qt.SystemLocaleShortDate);
}

Dialog {
    property var eventModification
    SilicaFlickable {
        // Компоненты ValueButton для установки даты, времени начала и времени конца события.           
        TextField {
            id: eventLabelTextField
            label: qsTr("Event")
            text: eventModification.displayLabel
        } 
        // Компонент TextField с id=locationTextField для установки места проведения мероприятия. 
    }
    onAccepted: {
        eventModification.displayLabel = eventLabelTextField.text;
        eventModification.location = locationTextField.text;
        eventModification.save();
    }
}

PullDownMenu {
    MenuItem {
        text: "Add new event"
        onClicked: pageStack.push(Qt.resolvedUrl("EditEventDialog.qml"), 
                                  {eventModification: Calendar.createNewEvent()})
    }
} 

SilicaListView {
    // ...
    model: agendaModel
    delegate: ListItem {
          // ...
          menu: ContextMenu {
               MenuItem {
                   text: "Edit"
                   onClicked: pageStack.push(Qt.resolvedUrl("EditEventDialog.qml"),
                                             {eventMod: Calendar.createModification(event)})
               }
        }
    }
}

MenuItem {
    text: qsTr("Delete")
    onClicked: Calendar.remove(event.uniqueId)
}

Заключение

https://habrahabr.ru/post/329692/

При отправке содержимого используется протокол Dat (Distributed Dataset Synchronization and Versioning), специально разработанный для передачи данных в рамках распределенной сети.

• Как создать провайдера виртуальной инфраструктуры
• Что нужно знать об IaaS-провайдере до начала работы
• Как выбрать направление для развития ИТ-проекта
• Мифы об облачных технологиях. Часть 1
• Как обезопасить Linux-систему: 10 советов

https://habrahabr.ru/post/333988/

О богатстве выбора и требованиях к языку

1. BuckleScript
   
2. ClojureScript
   
3. CoffeeScript
   
4. Elm
   
5. ElixirScript
   
6. JavaScript 2016 и будущие версии языка
   
7. JavaScript + аннотации
   
8. Nim
   
9. PureScript
   
10. Reason
    
11. TypeScript
    

1. Это должен быть язык со строгой типизацией. Типы, на микроуровне, играют роль документации. Они помогают, до определённой степени, обеспечивать правильность кода, и, что важнее, упрощают рефакторинг. Ещё одним соображением, в силу которого мы искали язык со строгой типизацией, была скорость разработки. Мы стремились найти строго типизированный язык, так как хотели ускорить работу. Такая идея идёт вразрез с тем видением типизации, которое сложилось у многих программистов. А именно, принято считать, что это — дополнительная нагрузка на разработчика, которая снижает скорость работы. Однако повышение скорости разработки означает ещё и увеличение вероятности появления ошибок. Нам нужна была типизация для того, чтобы код содержал как можно меньше ошибок, даже если пишут его быстро. Строгая типизация, кроме того, полезна в быстрорастущих проектах. Наша команда инженеров постоянно увеличивается в размерах, и число тех, кто работает над кодом, стабильно растёт.
   
   
2. Нужно, чтобы существовали хорошие вспомогательные инструменты. Учитывая то, чем мы собирались заниматься (серьёзное перепроектирование сайта), у нас не было времени на то, чтобы самостоятельно создавать значительное число вспомогательных средств. Было очень важно, чтобы мы могли быстро приступить к работе, используя готовые решения с открытым кодом. Если говорить конкретнее, то вот о каких именно инструментах идёт речь. Это — интеграция с популярными системами сборки (например, с Webpack), поддержка линтера, простая интеграция с фреймворками для тестирования. Если интеграция вспомогательных систем для какого-то языка была неочевидной, мы больше этот язык не рассматривали.
   
   
3. Язык должен был использоваться в серьёзных проектах. Если язык выглядел хорошо, но в реальности использовался лишь в мелких проектах отдельных энтузиастов, он вполне мог оказаться неподходящим для нашей задачи. Кроме того, если язык не используется в серьёзных проектах, возникают вопросы о том, долго ли такой язык просуществует, и о том, как быстро разработчики языка будут реагировать на сообщения о найденных в нём ошибках.
   
   
4. Наши разработчики должны освоить язык достаточно быстро. В вышеприведённом списке есть прекрасные языки, единственный минус которых — слишком большой срок, который нужен разработчикам для того, чтобы их освоить. Среди них хочется отметить Elm и PureScript. Мы серьёзно обсуждали вопрос их использования. Однако, в итоге оказалось, что их внедрение означало бы слишком большой объём работы, необходимый для освоения новых концепций программирования разработчиками, которые с ними не знакомы, для выхода их на уровень, позволяющий продуктивно работать над проектом.
   
   
5. Язык должен работать и на клиенте, и на сервере. На Reddit очень важно SEO, поэтому отсутствие универсальной системы выдачи готовых к отображению в браузере страниц — это большая проблема.
   
   
6. Хорошая поддержка библиотек. Мы не собирались писать всё с нуля. Существуют некоторые задачи, для решения которых нужны надёжные, проверенные временем библиотеки. Нам хотелось, чтобы у нас была возможность выбора того, что нам нужно, из существующих библиотек.

Компиляция или аннотирование?

enum VoteDirection {
  upvoted = 1,
  notvoted = 0,
  downvoted = -1,
};
const voteState: VoteDirection = VoteDirection.upvoted;

const voteDirections = {
  upvoted: 1,
  notvoted: 0,
  downvoted: -1,
};
type VoteDirection = $Keys;
const voteState: VoteDirection = voteDirections.upvoted;

Проверка корректности кода

class Animal {}
class Bird extends Animal {}

const foo: Array = [];

foo.push(new Animal());
/*
foo.push(new A);
        ^ A. This type is incompatible with
const foo: Array = [];
                ^ B
*/

class Animal {}
class Bird extends Animal {}

const foo: Array = [];

foo.push(new Animal()); // в typescript всё нормально

Экосистема

Итоги

https://habrahabr.ru/post/333986/

Стоп Apache Hadoop 3.0.0 alpha

Стоп Apache Tomcat 9.0.0.M22 и JetBrains IntelliJ IDEA 2017.1

Нужно ли устанавливать новую версию software, если не обновляется hardware?

Как Docker может повлиять на Cisco Any Connect 4.5.00058?

Послесловие

https://habrahabr.ru/post/333984/

• Слабые кадры. Компетентный IT-персонал и наиболее сильные кадры вымываются в столичные регионы, а также уезжают за рубеж. Такая ситуация будет подталкивать руководство на местах избавляться от IT-обузы в виде недееспособных сотрудников.
• Требования и нормативы. А ведь облачные площадки полностью соответствуют регулирующему законодательству, прежде всего в разрезе защиты персональных данных. Реализация требований законодательства, как для бизнеса, так и для государственных ведомств – все это дополнительная головная боль, которая способна привести к целому ряду неприятных последствий. Хочется, чтобы она была изначально устранена.

https://habrahabr.ru/post/333976/

Такси и другие Uber-like решения

Доставка и курьерские службы

Веб интерфейсы систем управления заказами

Зачем нужна маскировка номера

https://habrahabr.ru/post/333972/

4. Отчет XBRL

В этой главе мы рассмотрим отчеты XBRL. Как и прежде, основное внимание уделяем тому, что можно сделать, а не как это делается.

Отчет (instance document) содержит факты и ссылается на таксономию для придания фактам смысла:

Факты могут быть простыми (item) или составными (кортеж, tuple). Все простые факты в отчете имеют контекст, напр. финансовый год или начало отчетного периода. Все используемые контексты содержатся в самом отчете.

Схематически состав отчета можно изобразить следующим образом:

В следующих разделах мы более подробно рассмотрим составные части отчета.

4.1. Корневой элемент xbrl

Отчет содержит различные виды данных:

• Ссылки на одну или несколько таксономий;
• Ссылки на базы ссылок (linkbase) – опционально;
• Ссылки на роли (roles) и роли дуг (arcroles) – опционально;
• Контекст (context);
• Единицы измерения (units);
• Факты (fact) – простые (item) и кортежи (tuple);
• Сноски (footnote).

Общим контейнером для всех составных частей отчета является обязательный элемент xbrl.

4.2. Ссылки

Отчет может содержать некоторые ссылки на внешние ресурсы.

4.2.1. Ссылка на таксономию

Факты в отчете представляют собой бесполезные данные без таксономии, придающей им смысл. Каждый отчет должен ссылаться хотя бы на одну таксономию. Ссылка должна указывать на схему таксономии.

4.2.2. Ссылки на базы ссылок

Автор отчета может добавлять в него ссылки на базы ссылок, которые вместе таксономией (или таксономиями) становятся частью DTS (связанный комплекс таксономий, мы обсуждали его ранее). Примерами могут служить дополнительные определения или ссылки на концепты, свои версии презентаций или меток. Способ указания ссылки в отчете идентичен таковому в таксономии.

4.2.3. Ссылки на роли и роли дуг

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

4.3. Контекст

Чтобы можно было понять приведенные в отчете факты, у них должен быть контекст. Представленный в XBRL контекст должен содержать составителя отчета, отчетный период и, при необходимости, сценарий. Контекст должен иметь атрибут id, который используется для ссылки на него из элементов отчета.

4.3.1. Составитель отчета

Компания, государственное ведомство или физическое лицо, составляющее отчет; описывается в контексте атрибутом entity.

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

Опционально, составитель отчетности может также иметь элемент segment для дополнительной детализации, напр. бизнес-единица внутри крупной компании или территориальное подразделение государственной организации. В спецификации не дается каких-либо указаний относительно того, как именно следует использовать этот элемент – это любое XML-выражение, не использующее синтаксис XBRL.

4.3.2. Отчетный период

Период может быть двух типов – на дату (instant) и собственно за период (duration). Во втором случае можно либо явно задать начало и окончание периода, либо указать за все время (forever).

Примечание: Дата окончания всегда следует после даты начала. Если дата указывается без времени, то автоматически устанавливается полночь. Для начала периода это будет начало указанного дня, а для окончания периода – конец указанного дня (но технически это будет полночь следующего дня).

4.3.3. Сценарий

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

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

4.4. Единица измерения

Числовые значения должны иметь единицу измерения, которая предоставляет возможность их интерпретировать. Каждая используемая в отчете единица измерения должна быть определена отдельным элементом внутри корневого элемента xbrl.

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

У каждой единицы измерения должен быть указан атрибут id, используемый для обращения к ней в пределах отчета.

4.5. Факт

Факт (item) – это отдельное значение, которое передается в качестве отчетных данных. Факт не может содержать в себе другие факты, для таких случаев используются кортежи фактов (см. далее).

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

4.5.1. Ссылка на контекст

Каждый факт в отчете должен ссылаться на контекст путем указания его id. Тип отчетного периода, используемого при расчете факта, должен совпадать с типом отчетного периода в контексте:

• для фактов на дату контекст должен содержать instant-период;
• для фактов за период контекст должен содержать корректную пару значений атрибутов startDate (начало периода) и endDate (окончание периода), либо иметь значение forever (за все время).

4.5.2. Ссылка на единицу измерения

Числовые факты должны ссылаться на единицу измерения путем указания ее id.

4.5.3. Точность и десятичные знаки

Числовые факты должны содержать либо точность (precision), либо количество десятичных знаков (decimals). Это важно при сравнении значений, а также при выполнении расчетов, особенно при округлении и усечении.

Атрибут precision указывает количество значимых знаков факта (до десятичного разделителя). Атрибут decimals указывает точность значения в количестве знаков после десятичного разделителя. Эти атрибуты являются взаимоисключающими, т.е. недопустимо использовать оба из них в одном факте.

Атрибут precision определяется автоматически при наличии атрибута decimals. Спецификация XBRL дает точные правила такого определения. Также, она приводит примеры того, как читать эти атрибуты.

4.6. Кортежи фактов

Большинство фактов существуют независимо друг от друга. Они определяются отдельными элементами под корневым элементом xbrl. Когда смысл фактов раскрывается только с учетом их взаимосвязи, для объединения фактов в связанные множества используются кортежи. Примером может служить имя и должность менеджера.

Кортежи объединяют факты, при этом в качестве элементов кортежа могут использоваться как факты, так и другие кортежи. Сам по себе кортеж не может ссылаться на контекст или единицу измерения. Также, он не может иметь атрибутов тип периода (periodType) и баланс (balance).

4.7. Сноски

Факты передаются независимо, кортежи позволяют собирать факты в связанную структуру. Другие, менее структурированные связи между фактами и дополнительными данными к ним, можно определить с помощью сносок.

Сноски (footnotes) – это дополнительные данные к фактам и ссылки на них, которые существуют только в пределах отчета. Для ссылок на сноски используется роль footnotes. Сама сноска содержит текст и должна иметь метку языка.

4.8. Равенство

Для сравнения фактов или кортежей фактов могут иметь значение несколько форм равенства:

• Идентичность
• Структура
• Родительский элемент
• Значение
• XPath
• Контекст
• Единица измерения

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

https://habrahabr.ru/post/333896/

Метод Уэлфорда — простой и эффективный способ для вычисления средних, дисперсий, ковариаций и других статистик. Этот метод обладает целым рядом прекрасных свойств:

• достигает отличных показателей по точности решений;
• его чрезвычайно просто запомнить и реализовать;
• это однопроходный онлайн-алгоритм, что крайне полезно в некоторых ситуациях.

Оригинальная статья Уэлфорда была опубликована в 1962 году. Тем не менее, нельзя сказать, что алгоритм сколь-нибудь широко известен в настоящее время. А уж найти математическое доказательство его корректности или экспериментальные сравнения с другими методами и вовсе нетривиально.

Настоящая статья пытается заполнить эти пробелы.

Содержание

• Введение
• 1. Погрешности при вычислении средних
• 2. Обозначения
• 3. Вычисление средних
• 4. Вычисление ковариаций
• 5. Экспериментальное сравнение методов
• Заключение

Введение

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

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

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

У статьи следующая структура. В пункте 1 мы рассмотрим простейшую задачу вычисления среднего, на примере которой поймём, что эта задача не так уж и проста, как это кажется на первый взгляд. Пункт 2 вводит используемые в данной статье обозначения, которые пригодятся в разделах 3 и 4, посвящённых выводу формул метода Уэлфорда для, соответственно, вычисления взвешенных средних и взвешенных ковариаций. Если вам неинтересны технические подробности вывода формул, вы можете пропустить эти разделы. Пункт 5 содержит результаты экспериментального сравнения методов, а в заключении находится пример реализации алгоритмов на языке С++.

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

1. Погрешности при вычислении средних

Начну c классического примера. Пусть есть простой класс, вычисляющий среднее для набора чисел:

class TDummyMeanCalculator {
private:
    float SumValues = 0.;
    size_t CountValues = 0;
public:
    void Add(const float value) {
        ++CountValues;
        SumValues += value;
    }
    double Mean() const {
        return CountValues ? SumValues / CountValues : 0.;
    }
};

Попробуем применить его на практике следующим способом:

int main() {
    size_t n;
    while (std::cin >> n) {
        TDummyMeanCalculator meanCalculator;
        for (size_t i = 0; i < n; ++i) {
            meanCalculator.Add(1e-3);
        }
        std::cout << meanCalculator.Mean() << std::endl;
    }
    return 0;
}

Что же выведет программа?

Начиная с некоторого момента, сумма перестаёт меняться после прибавления очередного слагаемого: это происходит, когда SumValues оказывается равным 32768, т.к. для представления результата суммирования типу float просто не хватает разрядности.

Из этой ситуации есть несколько выходов:

1. Перейти с float на double.
2. Использовать один из более сложных методов суммирования.
3. Использовать метод Кэхэна для суммирования.
4. Наконец, можно использовать метод Уэлфорда для непосредственного вычисления среднего.

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

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

class TWelfordMeanCalculator {
private:
    float MeanValues = 0.;
    size_t CountValues = 0;
public:
    void Add(const float value) {
        ++CountValues;
        MeanValues += (value - MeanValues) / CountValues;
    }

    double Mean() const {
        return MeanValues;
    }
};

К вопросу о корректности этого кода мы вернёмся в дальнейшем. Пока же заметим, что реализация выглядит достаточно простой, а на тех данных, что используются в нашей программе, еще и работает с идеальной точностью. Это происходит из-за того, что разность value - MeanValues на первой итерации в точности равна среднему, а на последующих итерациях равна нулю.

Этот пример иллюстрирует основное достоинство метода Уэлфорда: все участвующие в арифметических операциях величины оказываются "сравнимы" по величине, что, как известно, способствует хорошей точности вычислений.

В этой статье мы рассмотрим применение метода Уэлфорда к ещё одной задаче — задаче вычисления ковариации. Кроме того, мы проведём сравнение различных алгоритмов и получим математические доказательства корректности метода.

2. Обозначения

Вывод формулы часто можно сделать очень простым и понятным, если выбрать правильные обозначения. Попробуем и мы. Будем считать, что заданы две последовательности вещественных чисел: $$ и $$, и последовательность соответствующих им весов $$:

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

Тогда, например, $$ — это сумма весов первых $$ элементов, $$ — это взвешенная сумма первых $$ чисел первой последовательности, а $$ — сумма взвешенных произведений:

Также понадобятся средние взвешенные величины:

Наконец, введём обозначения для ненормированных "разбросов" $$ и нормированных ковариаций $$:

3. Вычисление средних

Докажем взвешенный аналог формулы, использованной нами выше для вычисления среднего по методу Уэлфорда. Рассмотрим разность $$:

В частности, если все веса равняются единице, получим, что

Кстати, формулы для "взвешенного" случая позволяют легко реализовывать операции, отличные от добавления ровно одного очередного числа. Например, удаление числа $$ из множества, по которому вычисляется среднее — это то же, что добавление числа $$ с весом $$. Добавление сразу нескольких чисел — то же, что добавление одного из среднего с весом, равным количеству этих чисел, и так далее.

4. Вычисление ковариаций

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

Отсюда уже легко видеть, что

Эта формула чрезвычайно удобна, в том числе и для онлайн-алгоритма, однако, если величины $$ и $$ окажутся близкими и при этом большими по абсолютному значению, её использование приведёт к существенным вычислительным погрешностям.

Давайте попробуем вывести рекуррентную формулу для $$, в каком-то смысле аналогичную формуле Уэлфорда для средних. Итак:

Рассмотрим последнее слагаемое:

Подставим получившееся в выражение для $$:

Код, реализующий вычисления по этой формуле, при отсутствии весов выглядит очень просто. Необходимо обновлять две средних величины, а также сумму произведений:

double WelfordCovariation(const std::vector& x, const std::vector& y) {
    double sumProducts = 0.;
    double xMean = 0.;
    double yMean = 0.;

    for (size_t i = 0; i < x.size(); ++i) {
        xMean += (x[i] - xMean) / (i + 1);
        sumProducts += (x[i] - xMean) * (y[i] - yMean);
        yMean += (y[i] - yMean) / (i + 1);
    }

    return sumProducts / x.size();
}

Также интересным является вопрос об обновлении величины собственно ковариации, т.е. нормированной величины:

Рассмотрим первое слагаемое:

Вернёмся теперь к рассмотрению $$:

Это можно переписать, например, так:

Получилась формула, действительно обладающая удивительным сходством с формулой для обновления среднего!

5. Экспериментальное сравнение методов

Я написал небольшую программу, в которой реализуются три способа вычисления ковариации:

1. "Стандартный" алгоритм, напрямую вычисляющий величины $$, $$ и $$.
2. Алгоритм, использующий метод Кэхэна.
3. Алгоритм, использующий метод Уэлфорда.

Данные в задаче формируются следующим образом: выбираются два числа, $$ и $$ — средние двух выборок. Затем выбираются еще два числа, $$ и $$ — соответственно, отклонения. На вход алгоритмам подаются последовательности чисел вида

причём знаки при отклонениях меняются на каждой итерации, так, чтобы истинная ковариация вычислялась следующим образом:

Истинная ковариация константна и не зависит от числа слагаемых, поэтому мы можем вычислять относительную погрешность вычисления для каждого метода на каждой итерации. Так, в текущей реализации $$, а средние принимают значения 100000 и 1000000.

На первом графике изображена зависимость величины относительной погрешности при использовании наивного метода для среднего, равного 100 тысячам. Этот график демонстрирует несостоятельность наивного метода: начиная с какого-то момента погрешность начинает быстро расти, достигая совершенно неприемлемых величин. На тех же данных методы Кэхэна и Уэлфорда не допускают существенных ошибок.

Второй график построен для метода Кэхэна при среднем, равном одному миллиону. Ошибка не растёт с увеличением количества слагаемых, но, хотя она и существенно ниже, чем ошибка "наивного" метода, всё равно она слишком велика для практических применений.

Метод Уэлфорда, в свою очередь, и на этих данных демонстрирует идеальную точность!

Заключение

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

class TWelfordMeanCalculator {
private:
    double Mean = 0.;
    size_t Count = 0;
public:
    void Add(const float value) {
        ++Count;
        Mean += (value - Mean) / Count;
    }
    double GetMean() const {
        return Mean;
    }
};

class TWelfordCovariationCalculator {
private:
    size_t Count = 0;
    double MeanX = 0.;
    double MeanY = 0.;
    double SumProducts = 0.;
public:
    void Add(const double x, const double y) {
        ++Count;
        MeanX += (x - MeanX) / Count;
        SumProducts += (x - MeanX) * (y - MeanY);
        MeanY += (y - MeanY) / Count;
    }
    double Covariation() const {
        return SumProducts / Count;
    }
};

Использование этих методов может сэкономить много времени и сил в ситуациях, когда данные устроены достаточно "неудачно". Натолкнуться на проблемы с точностью вычислений можно в сколь угодно неожиданных ситуациях, даже при реализации одномерного алгоритма kMeans.

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

Литература

1. github.com: Different covariation calculation methods
2. machinelearning.ru: Сложение большого множества чисел, существенно отличающихся по величине
3. ru.wikipedia.org: Алгоритм Кэхэна
4. en.wikipedia.org: Algorithms for calculating variance: Online algorithm

https://habrahabr.ru/post/333426/

Как устроена документация в Cach'e

Что такое iKnow и iFind:

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

Технология iFind это модуль СУБД Cach'e для выполнения операций полнотекстового поиска по данным классов Cach'e. iFind использует многие функции iKnow для обеспечения интеллектуального текстового поиска. Чтобы использовать iFind в запросах, необходимо описать в классе Cach'e специальный iFind индекс.

Существует три вида индексов iFind, каждый вид индекса предоставляет все функции предыдущего вида, плюс дополнительные функции:

• Основной индекс (%iFind.Index.Basic): поддерживает поиск слов и словосочетаний.
• Семантический индекс (%iFind.Index.Semantic): поддерживает поиск объектов iKnow.
• Аналитический индекс (%iFind.Index.Analytic): поддерживает все функции iKnow в семантическом индексе, а также информацию о пути и близости слов.

XData Install [ XMLNamespace = INSTALLER ]
{

// Указываем название области





// Проверяем существует ли такая область




// Создаем область


	
// Создаем базу данных



// Маппируем указанные классы и глобалы в новую область
















 
}

Домен, который нужен нам для работы iKnow, строится по таблице содержащей документацию. Так как источником данных является таблица, будем использовать SQL.Lister. Поле content содержит текст документации, значит укажем его как поле данных. Остальные поля укажем в метаданных.

ClassMethod Domain(ByRef pVars, pLogLevel As %String, tInstaller As %Installer.Installer) As %Status
{
	#Include %IKInclude
	#Include %IKPublic
	set ns = $Namespace
	znspace "DOCSEARCH"
	// Создание домена или открытие если он существует
	set dname="DocSearch" 
   	if (##class(%iKnow.Domain).Exists(dname)=1){
	   	write "The ",dname," domain already exists",!
		zn ns
		quit
        }
  	else {	 
  		write "The ",dname," domain does not exist",!
       	set domoref=##class(%iKnow.Domain).%New(dname)
       	do domoref.%Save()
        }
   	set domId=domoref.Id
   	// Lister используется для поиска источников, соответствующих записям в результатах запроса
  	set flister=##class(%iKnow.Source.SQL.Lister).%New(domId)
  	set myloader=##class(%iKnow.Source.Loader).%New(domId)
  	// Построение запроса
	set myquery="SELECT id, docKey, title, bookKey, bookTitle, content, textKey FROM SQLUser.DocBook"
 	set idfld="id"
 	set grpfld="id"
 	// Указываем поля данных и метаданных
  	set dataflds=$LB("content")
  	set metaflds=$LB("docKey", "title", "bookKey", "bookTitle", "textKey")
        //Занесем все данные в Lister
  	set stat=flister.AddListToBatch(myquery,idfld,grpfld,dataflds,metaflds)
        if stat '= 1 {write "The lister failed: ",$System.Status.DisplayError(stat) quit }
        //Запускаем процесс анализа
        set stat=myloader.ProcessBatch()
        if stat '= 1 {
	      quit 
	       }
        set numSrcD=##class(%iKnow.Queries.SourceQAPI).GetCountByDomain(domId)
        write "Done",!
        write "Domain cointains ",numSrcD," source(s)",!
        zn ns
        quit
}

Для поиска по документации мы используем индекс %iFind.Index.Analytic:

Index contentInd On (content) As %iFind.Index.Analytic(LANGUAGE = "en", LOWER = 1, RANKERCLASS = "%iFind.Rank.Analytic");

После добавления и построения такого индекса, его можно использовать, например в SQL запросах. Общий синтаксис использования iFind в SQL:

SELECT * FROM TABLE WHERE %ID %FIND search_index(indexname,'search_items',search_option)

После создания индекса %iFind.Index.Analytic с такими параметрами генерируются несколько SQL процедур вида — [Название таблицы]_[Название индекса]Название процедуры

• DocBook_contentIndRank — Возвращает результат алгоритма ранжирования TF-IDF для запроса
  Синтаксис имеет вид:
  
  

  SELECT DocBook_contentIndRank(%ID, ‘SearchString’, ‘SearchOption’) Rank FROM DocBook WHERE %ID %FIND search_index(contentInd,‘SearchString’, ‘SearchOption’)

• DocBook_contentIndHighlight — возвращает результаты поиска, где искомые слова обрамлены в указанный тег:
  
  

  SELECT DocBook_contentIndHighlight(%ID, ‘SearchString’, ‘SearchOption’,’Tags’) Text FROM DocBook WHERE %ID %FIND search_index(contentInd,‘SearchString’, ‘SearchOption’)

Что в итоге получилось:

1. Автозаполнение в строке поиска

   
   

   Когда вы вводите текст в строке поиска, предлагаются возможные варианты запросов, чтобы помочь быстрее найти нужную информацию. Эти подсказки создаются на основе того слова(или начальной части слова, если ввод слова не закончен) которое вы ввели и пользователю демонстрируются десять наиболее похожих слов или словосочетаний.
   
   Происходит этот процесс с помощью iKnow, метода %iKnow.Queries.Entity.GetSimilar

   
   
   
   

2. Нечеткий поиск

   
   

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

   
   

   В SQL запросах iFind, за использование нечеткого поиска отвечает параметр search_option.
   Значение search_option = 3, означает расстояния Левенштейна равное двум.
   
   Для задания расстояния Левенштейна равное n, следует указать значение search_option = ‘3:n’
   В поиске по документации используется расстояния Левенштейна равное единице, продемонстрируем как это работает:
   
   Наберем в поиске слово ifind:

   
   
   
   

   Попробуем произвести нечеткий поиск, например слово с опечаткой — ifindd. Как мы видим поиск исправил опечатку и нашел нужные статьи.

   
   
   
   

3. Сложные запросы

   
   

   Благодаря тому, что iFind поддерживает сложные запросы с применением скобок и операторов AND OR NOT, мы реализовали расширенный поиск. В поиске можно указать: слово, словосочетания, любое из нескольких слов, либо не содержащие некоторые слова. Поля можно заполнять как одно или несколько, так и все сразу.

   
   

   Например, найдем статьи содержащие слово iknow, словосочетание rest api и содержащие любое из слов domain или UI.

   
   
   
   

   Видим, что таких статей две:

   
   
   
   

   Заметим, что во второй статье упоминается Swagger UI, можно добавить в запрос, поиск статьей, не содержащих слово Swagger

   
   
   
   

   В итоге найдена только одна статья:

   
   
   
   

4. Подсветка результатов поиска

   
   

   Как уже говорилось выше, использование iFind индекса, создает процедуру DocBook_contentIndHighlight. Используя:

   
   

   SELECT DocBook_contentIndHighlight(%ID, 'search_items', '0', '', 0) Text FROM DocBook

   
   

   Получаем искомый текст обрамленный в тег

   
   
   
   

   Это позволяет на фронтенде визуально выделять результаты поиска.

   
   
   
   

5. Алгоритм ранжирования результатов

   
   

   iFind поддерживает возможность ранжирования результатов по алгоритму TF-IDF. Мера TF-IDF часто используется в задачах анализа текстов и информационного поиска, например, как один из критериев релевантности документа поисковому запросу.

   
   

   В результате SQL запроса, поле Rank будет содержать вес слова, который пропорционален количеству употребления этого слова в статье, и обратно пропорционален частоте употребления слова в других статьях.

   
   

   SELECT DocBook_contentIndRank(%ID, ‘SearchString’, ‘SearchOption’) Rank FROM DocBook WHERE %ID %FIND search_index(contentInd,‘SearchString’, ‘SearchOption’)

   
   

6. Интеграция с официальным поиском по документации

   
   

   После установки, в официальный поиск по документации добавляется кнопка “Search using iFind”.

   
   
   
   

   Если заполнено поле Search words, то после нажатия на “Search using iFind”, будет выполнен переход на страницу с результатами поиска для введенного запроса.

   
   Если поле не заполнено, то будет выполнен переход на начальную страницу нового поиска.
   

Установка

1. Загрузите из последнего релиза с страницы релизов, файл Installer.xml
2. Импортируйте загруженный файл Installer.xml в область %SYS, скомпилирйте.
3. В терминале в области %SYS введите следующую команду:
   
   

   do ##class(Docsearch.Installer).setup(.pVars)

   
   Процесс занимает около 15-30 минут из-за процесса построения домена.

Демо

Заключение

https://habrahabr.ru/post/333582/

Чему мы научимся

Подготовка

Теория и основы

//W = количество столбцов в сетке
//H = количество строк
//f = коэффициент распределения/рассеивания
//Сначала мы копируем сетку в newGrid, чтобы не изменять сетку, потому что выполняем считывание из неё
for(var r=1; rcode>

0.1 * (100+100+100+100-4*100) = 0.1 * (400-400) = 0

0.1 * (100+100+0+0-4*0) = 0.1 * (200) = 20

0.1 * (70+70+70+70-4*100) = 0.1 * (280 - 400) = -12

Реализация

uniform vec2 res;
void main() {
    vec2 pixel = gl_FragCoord.xy / res.xy;
    gl_FragColor = vec4(0.0,0.0,0.0,1.0);
 }

Шаг 1: перемещаем значения между пикселями

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

Каждый пиксель должен получить немного цвета своих соседей и потерять немного своего.

uniform vec2 res;
uniform sampler2D texture;
void main() {
    vec2 pixel = gl_FragCoord.xy / res.xy;

    gl_FragColor = texture2D( tex, pixel );// Это цвет текущего пикселя
    gl_FragColor.r += 0.01;// Инкремент красного компонента 	
 }

Проблема

Фокус с буфером кадра

1. Передаём A через шейдер, рендерим в B.
2. Рендерим B на экран.
3. Передаём B через шейдер, рендерим в A.
4. Рендерим A на экран.
5. Повторяем 1.

1. Передаём A через шейдер, рендерим в B.
2. Рендерим B на экран.
3. Меняем A и B (то есть переменная A теперь содержит текстуру, находившуюся в B, и наоборот).
4. Повторяем 1.

uniform vec2 res; // Ширина и высота экрана
uniform sampler2D bufferTexture; // Входная текстура
void main() {
    vec2 pixel = gl_FragCoord.xy / res.xy;
    gl_FragColor = texture2D( bufferTexture, pixel );
}

gl_FragColor.r += 0.01;

Шаг 2: получаем источник дыма

// Получаем расстояние от этого пикселя до центра экрана
float dist = distance(gl_FragCoord.xy, res.xy/2.0);
if(dist < 15.0){ // Создаём круг радиусом 15 пикселей
	gl_FragColor.rgb = vec3(1.0);
}

// Получаем расстояние от этого пикселя до центра экрана
float dist = distance(gl_FragCoord.xy, res.xy/2.0);
if(dist < 15.0){ // Создаём круг радиусом 15 пикселей
	gl_FragColor.rgb += 0.01;
}

// Ширина и высота экрана
uniform vec2 res; 
// Входная текстура
uniform sampler2D bufferTexture; 
// x,y - это положение. z - это сила/плотность
uniform vec3 smokeSource;

void main() {
    vec2 pixel = gl_FragCoord.xy / res.xy;
    gl_FragColor = texture2D( bufferTexture, pixel );

    // Получаем расстояние от текущего пикселя до источника дыма
    float dist = distance(smokeSource.xy,gl_FragCoord.xy);
    // Создаём дым, когда нажата клавиша мыши
    if(smokeSource.z > 0.0 && dist < 15.0){
    	gl_FragColor.rgb += smokeSource.z;
    }
}

Шаг 3: рассеиваем дым

// Рассеивание дыма
float xPixel = 1.0/res.x; // Размер единичного пикселя
float yPixel = 1.0/res.y;

vec4 rightColor = texture2D(bufferTexture,vec2(pixel.x+xPixel,pixel.y));
vec4 leftColor = texture2D(bufferTexture,vec2(pixel.x-xPixel,pixel.y));
vec4 upColor = texture2D(bufferTexture,vec2(pixel.x,pixel.y+yPixel));
vec4 downColor = texture2D(bufferTexture,vec2(pixel.x,pixel.y-yPixel));

// Уравнение рассеивания
gl_FragColor.rgb += 
    14.0 * 0.016 * 
	(
		leftColor.rgb + 
		rightColor.rgb + 
		downColor.rgb + 
		upColor.rgb - 
		4.0 * gl_FragColor.rgb
	);

Ой-ёй, всё зависло!

float factor = 14.0 * 0.016 * (leftColor.r + rightColor.r + downColor.r + upColor.r - 4.0 * gl_FragColor.r);
// Нам нужно учитывать низкую точность текселов
float minimum = 0.003;
if (factor >= -minimum && factor < 0.0) factor = -minimum;

gl_FragColor.rgb += factor;

Шаг 4: рассеивание дыма вверх

// Уравнение рассеивания
float factor = 8.0 * 0.016 * 
    (
		leftColor.r + 
		rightColor.r + 
		downColor.r * 3.0 + 
		upColor.r - 
		6.0 * gl_FragColor.r
	);

Примечание об уравнении рассеивания

Небольшое исправление

// Обрабатываем нижнюю границу
// Эти строки нужно выполнять до функции рассеивания
 if(pixel.y <= yPixel){
 	downColor.rgb = vec3(0.0);
 }

Сетка скоростей

Заключение

Для чего могут пригодиться буферы кадров?

Не бойтесь технических статей

https://habrahabr.ru/post/333718/

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

Павел расскажет про способы тестирования верстки и сам Galen Framework — что это и как работает, опыт использования на проекте, его плюсы и минусы, а также небольшое сравнение с BackstopJS.

Михаил расскажет об оптимизации изоморфного react-приложения на примере обновленного сайта rambler.ru. Также разберем assets, конфигурацию Webpack и Server Side Rendering.

https://habrahabr.ru/post/333834/

https://habrahabr.ru/post/333966/