Всем привет. Любому автопилоту, очевидно, нужно не только принимать решения по управлению, но и заставлять автомобиль этим решениям подчиняться. Сегодня увидим, как весьма доступными средствами доработать обычный автомобиль полностью электронным рулевым управлением (steer-by-wire). Оказывается, сам авто для разработки не очень и нужен, а большинство функционала можно с комфортом отлаживать дома или в офисе. В главных ролях всем известные компоненты из хобби-магазинов электроники.

Задумаемся на секунду, что нужно для системы электронного управления? Сервопривод, который может поворачивать колёса, и контроллер, чтобы сервоприводом управлять. Внезапно, всё это в большинстве современных автомобилей уже есть, и называется "усилитель рулевого управления". Традиционные чисто механические (как правило, гидравлические) усилители стремительно исчезают с рынка, уступая место узлам с электронным блоком управления (ЭБУ). А значит, задача сразу упрощается: нам остается только "уговорить" имеющийся ЭБУ усилителя выдать нужные команды на сервопривод.

Очень удобным для доработки оказался KIA Cee'd начиная с 2015 модельного года (скорее всего аналогично и его соплатформенники от KIA/Hyundai). Сошлись одновременно несколько факторов:

• Усилитель руля полностью электрический, нет возни с гидравликой, стоит копейки (относительно) на разборках. Вся нужная проводка выведена наружу и легко доступна.
• Усилитель интегрирован с рулевой колонкой, поэтому к нему есть легкий доступ на автомобиле и любая дополнительная электроника останется в салоне в тепличных условиях (в отличие от усилителей, интегрированных в рулевую рейку).
• Очень важно — есть пример успешной доработки аналогичного KIA Soul. Американская PolySync разрабатывает апгрейд Soul до полностью drive-by-wire платформы для беспилотников, и на их гитхабе можно подсмотреть много полезного.

Итак, получена в распоряжение рулевая колонка в сборе:

Будем заставлять её крутиться. Для этого нужно создать у блока управления впечатление, что

1. Он находится в автомобиле с работающим двигателем.
2. Водитель прикладывает вращающее усилие к рулевому колесу.

Пойдем по порядку.

Симуляция автомобиля

Нужно понять интерфейс между электронным блоком управления (ЭБУ) усилителя и остальным автомобилем. Нагуглив электрическую схему видим картинку:

Из схемы видно, что физически интерфейс очень прост:

• Питание (12V постоянное) через разъем E29.
• Сигнал включенного зажигания (12V) через разъем M46.
• CAN-шина данных также через разъем M46.

Внешний вид и распиновки разъемов находим на том же сайте.

С питанием и зажиганием всё просто, берем 12V с обычного компьютерного блока питания. Но если просто подать питание и зажигание, усилитель полноценно не включится, и усиливать не будет. Дополнительно нужна информация от других блоков автомобиля: работает ли двигатель (чтобы не тратить энергию аккумулятора при выключенном), текущая скорость (чтобы делать руль "тяжелее" на скорости), наверняка что-то ещё.

Обмен данными между электронными блоками в современных автомобилях организован по шинам CAN (Controller Area Network). Это широковещательная (у пакетов нет адресов назначения) локальная сеть на витой паре, где каждый блок может публиковать свои данные. У каждого типа данных свой идентификатор. Например, в нашем случае усилитель руля рассылает значения угла поворота руля с ID 0x2B0. Часто бывает несколько физически разделенных шин, чтобы второстепенные блоки типа контроллеров стеклоподъемников не мешались обмену между критически важными компонентами. В Cee'd используется две шины: C-CAN и B-CAN (схема здесь, в части "Информация о канале передачи данных"). На C-CAN "висят" почти все блоки с ней и будем работать.

Выбор адаптера CAN-шины

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

1. Адаптеры в сборе с алиэкспресса. Их не пробовал, по слухам довольно много брака и софт видимо только под Windows.
2. Arduino шилды на MCP2515/MCP2551, в основном клоны дизайна от seeed в любом магазине ардуинной тематики. Но совмещать такой шилд надо не с Arduino (я так и не смог заставить связку работать на воспроизведение с нужной скоростью), а с Raspberry Pi. В приложении ниже подробная инструкция.
3. USB адаптер CANHacker Baby, разработка Artemka86. Выгодно отличается от вариантов с алиэкспресса отличной поддержкой "из первых рук" от разработчика (проверено лично, Артём подходит к делу с душой). Также плюсом является поддержка стандартного протокола LAWICEL совместимого с широким набором софта.

Софта разного тоже много (за обзором опять сюда). Самый простой вариант — Linux c can-utils из SocketCAN, за который спасибо инженерам Volkswagen. Большой плюс SocketCAN в стандартизации — любое USB устройство с поддержкой протокола LAWICEL (pdf) видится системой как обычный сетевой интерфейс. Таким образом избегаем привязки к вендор-специфическому софту конкретного устройства. У текущей версии CANHacker есть небольшая несовместимость со стоковыми can-utils по работе с USB, поэтому берём патченную версию отсюда. Raspberry Pi с CAN шилдом работает со стоковым пакетом can-utils из Raspbian OS без проблем.

Подключение к шине, запись пакетов

С подключением к индивидуальному узлу на стенде всё просто: соединяем контакт CAN-High адаптера с CAN-High автомобильного узла, CAN-Low — c CAN-Low. По стандарту между CAN-High и CAN-Low должно быть 2 замыкающих резистора по 120 Ом, на практике обычно всё работает на довольно широком интервале сопротивлений, у меня например одно на 110 Ом.

На автомобиле замыкающий резистор не нужен (они там уже стоят, чтобы шина сама по себе работала). В зависимости от модели авто, возможно придется повозиться с физическим доступом к проводке шины. Самый удобный вариант — разъём OBD-II (on-board diagnostic), он обязателен на всех легковых автомобилях, выпущенных в Европе с начиная 2001-2004 года и находится не дальше 60 см от рулевого колеса. На Cee'd разъём слева под рулём, за пластмасовой крышкой блока предохранителей.

Распиновка OBD-II стандартизована и включает шину CAN (CANH на 6 контакте, CANL на 14). Нам повезло, корейцы пошли по пути наименьшего сопротивления и вывели C-CAN, на которой висят все важные узлы, прямо на диагностический разъём:

В результате на Cee'd можно прослушать весь внутренний трафик, ничего в авто не разбирая. Когда машина не твоя, а знакомые пустили повозиться — большой плюс. Но такая халява не везде. У Volkswagen например служебная CAN изолирована от OBD шлюзом, поэтому подключаться пришлось бы примерно так:

Подключив все контакты, поднимаем сетевой интерфейс:

$ sudo slcand -o -c -s6 -S 115200 ttyACM0 slcan0 && sleep 1 && sudo ifconfig slcan0 up

Проверяем, что сеть работает и данные принимаются (включив зажигание):

$ cansniffer slcan0

И наконец, если всё нормально, можно записывать лог:

$ candump -L slcan0 > real-car-can-log.txt

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

Воспроизведение записи шины на стенде

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

$ $ candump slcan0
  slcan0  2B0   [5]  00 00 00 00 00
  slcan0  2B0   [5]  FF 7F FF 06 F1
  slcan0  2B0   [5]  FF 7F FF 06 C2
  slcan0  2B0   [5]  FF 7F FF 06 D3
  slcan0  2B0   [5]  FF 7F FF 06 A4
  slcan0  2B0   [5]  FF 7F FF 06 B5
  slcan0  2B0   [5]  FF 7F FF 06 86
  slcan0  2B0   [5]  FF 7F FF 06 97
  slcan0  2B0   [5]  FF 7F FF 06 68
  slcan0  5E4   [3]  00 00 00
  slcan0  2B0   [5]  FF 7F FF 06 79
  slcan0  2B0   [5]  FF 7F FF 06 4A
....

Видим, что рассылаются пакеты 2B0 (текущий угол поворота руля) и, реже, 5E4 (какой-то общий статус усилителя). Отфильтровываем их из общего лога:

$ cat real-car-can-log.txt | grep -v ' 2B0' | grep -v ' 5E4 ' > can-log-no-steering.txt

Фильтрованный лог можно подавать на воспроизведение:

% sudo ifconfig slcan0 txqueuelen 1000
$ canplayer -I can-log-no-steering.txt

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

Эмуляция усилия на руле

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

Блок управления обрабатывает сигналы датчиков и выдаёт команды сервоприводу на создание дополнительного усилия на поворот рулевого вала.

Проверка формата сигнала датчиков

По информации PolySync, на Soul, у которого с Cee'd общая платформа, два аналоговых датчика крутящего момента. Cигнал каждого — отклонение уровня постоянного напряжения от базовых 2.5V, провода в жгуте — зеленый и синий. Проверим, что у нас то же самое:

• Размыкаем разъем на ЭБУ, пробрасываем нужные контакты через макетку и заводим на аналоговые входы arduino.
  
• Загружаем скетч, в цикле замеряющий напряжения и печатающий их в терминал.
• Запускаем Serial Plotter в Arduino IDE, поворачиваем рулевой вал. Видим результат на графике, схема совпадает с Soul:
  
• Радуемся сэкономленному времени.

Эмуляция сигнала датчиков

Переходим к эмуляции сигнала датчиков. Для этого поставим свой модуль в разрыв цепи между датиком и ЭБУ, будем транслировать настоящий сигнал с датчика и по команде сдвигать его на фиксированный уровень (изображая приложенное к рулевой колонке усилие). Силами одной arduino это не получится: там нет полноценного цифро-аналогового преобразователя, который мог бы выдавать постоянное напряжение. Аналоговые входы arduino нам тоже не очень подходят — хотя пинов для них целых 6, канал АЦП в контроллере только один, и его переключение между пинами занимает заметное время.

Нужно добавить к arduino внешние ЦАП/АЦП. Мне попались модули YL-40 (описание в pdf) на основе чипа PCF8591 — на каждой по 4 канала 8-бит АЦП и 1 8-бит ЦАП. Модуль может общаться с arduino по протоколу I2C. Потребуется небольшое допиливание (в буквальном смысле): китайские товарищи поставили на плату светодиод индикации напряжения на выходе ЦАП — его обязательно надо отсоединить. Иначе утекающий через диод ток не даст ЦАП поднять напряжение на выходе больше 4.2V (вместо штатных 5V). Диод отсоединяем, отковыривая резистор R4 с обратной стороны платы.

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

С интерфейсом к arduino есть нюанс — нам нужно 2 канала ЦАП, соотвественно 2 модуля, но у них одинаковые адреса I2C (зашиты в чип). Хотя чип позволяет менять свой I2C адрес, замыкая определенные ноги на +5V вместо земли, на плате эти перемычки не разведены. Вместо перепайки возьмем костыль — две разные библиотеки I2C на arduino (стандартная Wire и SoftI2CMaster), каждая на свою пару пинов. Получаем модули на разных шинах, конфликт пропадает.

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

1. Включаем arduino, открываем Serial Monitor. Важно запустить arduino первой, не останавливать и не прерывать. Иначе напряжение на выходах ЦАПов сбросится, ЭБУ усилителя определит ошибку сигнала с датчиков, уйдет в безопасный редим и придется все перезапускать по новой.
2. Запитываем усилитель, подключаем зажигание.
3. Запускаем воспроизведение лога CAN-шины.
4. Теперь по командам l и r через Serial Monitor усилитель будет поворачивать рулевой вал. Объявляется победа.

На сегодня всё, на очереди доработка софта (интеграция с CAN шиной, чтение оттуда текущего угла поворота и динамическое управление крутящим усилием, чтобы внешний контроллер мог задать фиксированный угол поворота руля и система его выдерживала), отработка на автомобиле (на стенде не смоделируешь сопротивление от колёс). Возможно замена 8-битных ЦАП/АЦП на 10 или 12 бит (взял первое, что под руку попалось). Рулящая нейросеть тоже в процессе, надеюсь скоро сделать пост.

Спасибо Artemka86 за ценные консультации по работе с CAN и помощь с оборудованием.

Ресурсы для дальнейшего погружения

1. Car Hacking: The definitive source. Начинать можно с Car Hacking for Poories, там отлично покрыты основы. Остальное тоже интересно, но с упором на несанкционированный доступ.
2. The Car Hacker's Handbook: A Guide for the Penetration Tester. Больше деталей, чем в Car Hacking: The definitive source, тоже акцент на несанкционированный доступ. Если читать как первое введение в тему, надо приспособиться пропускать большие куски.
3. Car Hacking 101: Tools of the Trade, MCD Software — обзоры инструментов. В основном малоинтересная экзотика на мой взгляд.
4. Open Source Car Control — открытая платформа для KIA Soul, в процессе разработки. Они делают полное решение (руль, акселератор, тормоза), включвя доработки по "железу" на машине (в основном для тормозов — ставятся дополнительные тормозные приводы, что-то меняется в тормозной гидравлике итд). Релиза ещё не было, но многие вещи уже можно подсмотреть.

Бонус. Совмещаем Raspberry Pi и Arduino CAN shield

Прежде всего, внимание, CAN шилд и raspberry pi нельзя соединять напрямую, они не совместимы по напряжению. На Arduino UNO-совместимых платах напряжение логики 5V, а на raspberry pi только 3.3V, поэтому прямое соединение только сожжет задействованные пины.

Нам понадобятся:

• Raspberry Pi (проверялось на версии 3B).
• Arduino CAN шилд на MCP2515/MCP2551.
• Преобразователь уровня логики на 5 каналов или больше (можно 2 по 4 канала, но понадобится больше соединений). Мне попался этот

Нужно завести на CAN шилд питание (5V), соединения интерфейса данных SPI (4 пина: MOSI, MISO, SCLK, CS) и 1 пин сигнала прерывания. Всё, кроме питания, идет через преобразователь уровня, который в свою очередь тоже надо запитать.

На схемах ищем нужные пины.

Raspberry Pi:

CAN шилд:

Получаем результат:

• SPI на raspberry pi 19, 21, 23, 24 (MOSI, MISO, SCLK, CS) соответствуют D11, D12, D13, D9 (или на некоторых версиях D10) на CAN шилде.
• Прерывание с D2 на шилде можно завести на любой GPIO пин raspberry, у меня это пин 22 (GPIO 25). Номер пина укажем в софте при настройке.

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

Всё, кроме 5V питания и земли на шилд идёт через преобразователь:

Переходим к настройке софта (стандартный Raspbian).

1. Включаем поддержку SPI и CAN модуля. В /boot/config.txt добавляем

   
   

   dtparam=spi=on
   dtoverlay=mcp2515-can0,oscillator=16000000,interrupt=25,spimaxfrequency=1000000
   dtoverlay=spi0-hw-cs

   
   

   Здесь interrupt=25 указывает пин, на который заведено прерывание с шилда. Индексация идёт по GPIO пинам, поэтому interrupt=25 это GPIO 25, он же пин 22 по сквозной индексации всех пинов. Также важно указать частоту интерфейса SPI spimaxfrequency, т.к. значение по умолчанию — 10 МГц — слишком высокое для шилда, он просто не соединится.

   
   

2. Перезагружаем raspberry pi, проверяем соединение с шилдом:

   
   

   $ dmesg
   ...
   [   12.985754] CAN device driver interface
   [   13.014774] mcp251x spi0.0 can0: MCP2515 successfully initialized.
   ...

   
   

3. Устанавливаем can-utils:

   
   

   $ sudo apt install can-utils

   
   

4. Запускаем виртуальный сетевой интерфейс:

   
   

   $ sudo /sbin/ip link set can0 up type can bitrate 500000
   $ sudo ifconfig can0 txqueuelen 1000

   
   

   Вторая команда важна при воспроизведении большого количества данных с raspberry pi, то есть когда записанный на автомобиле полный лог CAN шины воспоизводим для изолированного узла на стенде. Без увеличения буфера он скорее всего переполнится, когда в логе встретится несколько CAN пакетов с маленькими интервалами, и тогда соединение зависнет.

   
   
5. Готово, можно пользоваться candump, cansniffer и всем остальным из can-utils.

Промо в чеке

• направленные на увеличение среднего чека (скидка на набор товаров, N+N, неразлучная пара, подарок за покупку);

• направленные на удержание покупателей (купон на скидку, рекламный текст, содержащий календарь скидок).

Акции, направленные на увеличение среднего чека

• акция N+N стимулирует покупателя приобретать товар впрок по сниженной цене. Например, 1+1 — два товара по цене одного — подразумевает 50% скидку на товар;

• скидка на набор товаров — покупатель получает скидку/подарок при покупке определенного набора товаров. Например, если вы покупаете карандаш и ручку определенного производителя, то его ластик ритейлер готов отдать вам бесплатно. Или же, он подарит вам в подарок игрушку, если вы купили детской одежды на 2000 рублей;

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

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

Акции, направленные на удержание покупателей

• купонная акция;

• рекламный текст, содержащий календарь скидок.

Промо в чеке

• направленные на увеличение среднего чека (скидка на набор товаров, N+N, неразлучная пара, подарок за покупку);

• направленные на удержание покупателей (купон на скидку, рекламный текст, содержащий календарь скидок).

Акции, направленные на увеличение среднего чека

• акция N+N стимулирует покупателя приобретать товар впрок по сниженной цене. Например, 1+1 — два товара по цене одного — подразумевает 50% скидку на товар;

• скидка на набор товаров — покупатель получает скидку/подарок при покупке определенного набора товаров. Например, если вы покупаете карандаш и ручку определенного производителя, то его ластик ритейлер готов отдать вам бесплатно. Или же, он подарит вам в подарок игрушку, если вы купили детской одежды на 2000 рублей;

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

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

Акции, направленные на удержание покупателей

• купонная акция;

• рекламный текст, содержащий календарь скидок.

Как устроена биржа

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

Ликвидность – это возможность быстро и без существенных накладных расходов продать или купить ценную бумагу.

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

Зачем это нужно

• Между странами и территориями.
• Между отраслями промышленности и секторами экономики.
• Между отдельными предприятиями внутри одного сектора.

Производные инструменты: фьючерсы, опционы и не только

• Депозитарные расписки;
• Варранты на ценные бумаги;
• Фьючерсные контракты;
• Форвардные контракты;
• Опционные контракты.

Депозитарные расписки

Варранты на ценные бумаги

Фьючерсные контракты

Форвардные контракты

1. Форвардные контракты заключаются только на внебиржевом рынке между двумя конкретными контрагентами – они же и несут риск неисполнения условий контракта (в случае фьючерсов этот риск лежит на бирже).
2. Такой контракт может быть заключен на произвольную дату в будущем в отличие от фьючерса, который имеет стандартную дату исполнения.
3. В качестве базового актива форвардного контракта может быть что угодно, а не только активы, допускающие биржевую стандартизацию.
4. Такие контракты, как правило, не требуют гарантированных депозитов, и по ним не начисляется вариационная маржа.

Опционы

Что такое фондовые индексы и зачем они нужны

IPO: зачем это нужно, плюсы и минусы

Заключение: полезные ссылки и материалы для изучения фондового рынка

• Образовательные ресурсы ITinvest
• Аналитика и обзоры рынка
• Топ-10 книг для понимания устройства фондового рынка
• Как устроена биржевая торговля в России
• Инфраструктура российского рынка ценных бумаг (краткий ликбез)
• How-to: роботы и API брокерской торговой системы

Как устроена биржа

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

Ликвидность – это возможность быстро и без существенных накладных расходов продать или купить ценную бумагу.

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

Зачем это нужно

• Между странами и территориями.
• Между отраслями промышленности и секторами экономики.
• Между отдельными предприятиями внутри одного сектора.

Производные инструменты: фьючерсы, опционы и не только

• Депозитарные расписки;
• Варранты на ценные бумаги;
• Фьючерсные контракты;
• Форвардные контракты;
• Опционные контракты.

Депозитарные расписки

Варранты на ценные бумаги

Фьючерсные контракты

Форвардные контракты

1. Форвардные контракты заключаются только на внебиржевом рынке между двумя конкретными контрагентами – они же и несут риск неисполнения условий контракта (в случае фьючерсов этот риск лежит на бирже).
2. Такой контракт может быть заключен на произвольную дату в будущем в отличие от фьючерса, который имеет стандартную дату исполнения.
3. В качестве базового актива форвардного контракта может быть что угодно, а не только активы, допускающие биржевую стандартизацию.
4. Такие контракты, как правило, не требуют гарантированных депозитов, и по ним не начисляется вариационная маржа.

Опционы

Что такое фондовые индексы и зачем они нужны

IPO: зачем это нужно, плюсы и минусы

Заключение: полезные ссылки и материалы для изучения фондового рынка

• Образовательные ресурсы ITinvest
• Аналитика и обзоры рынка
• Топ-10 книг для понимания устройства фондового рынка
• Как устроена биржевая торговля в России
• Инфраструктура российского рынка ценных бумаг (краткий ликбез)
• How-to: роботы и API брокерской торговой системы

Видео само не заиграет

Safari поддерживает только h.264 видеокодек

Мелочи, о которых стоит знать

Видео само не заиграет

Safari поддерживает только h.264 видеокодек

Мелочи, о которых стоит знать

Меня зовут Сергей, я работаю старшим дизайнером в компании Acronis. В отделе дизайна продуктов для бизнеса я отвечаю за разработку и внедрение единой библиотеки компонентов.

Так как у нас много продуктов и сервисов, а дизайн в этих продуктах и сервисах сильно отличается, мы решили его унифицировать и привести к единому UI. Зачем? Все просто: такой подход дает возможность оптимизировать работу отдела, сосредоточить дизайнеров на UX, ускорить процесс разработки и запуск новых продуктов, снизить нагрузку на отделы тестирования и значительно сократить количество багов на стороне front-end. В этой статье я расскажу о нашем опыте, остановлюсь на инструментах и покажу, как устроена библиотека изнутри.

Здравствуйте. Я ваш куратор в игре «Актуальный UI-кит»

Долгое время роль библиотеки играл собранный в Иллюстраторе PDF файл с палитрой цветов, скудным набором элементов и большими планами на будущее в виде 70-ти пустых страниц. Для того, чтобы найти какой-нибудь уже существующий элемент, приходилось постоянно дергать других дизайнеров или лопатить чужие исходники, а потом сверять актуальность с реализованным элементом на одном из тестовых стендов. Пик отчаяния наступал в тот момент, когда на тестовом стенде искомый элемент выглядел несколько иначе и вел себя не совсем так, как было запланировано в макетах. Получалась достаточно стандартная ситуация: дизайнеры тянули одеяло в свою сторону, мотивируя свои решения авторитетным «Хочу, чтобы так!», а разработчики пытались прикрываться мало значимым «Но ведь технические ограничения?!». Такой подход, закономерно, приводил к не самым лучшим результатам по обе стороны баррикад и его нужно было менять. Забегая вперед, скажу, что сейчас большинство сложных UI решений мы принимаем коллегиально и стараемся искать компромисс между красотой и технологичностью. Итак:

Основные проблемы, которые требовали решения

• Централизованная библиотека UI элементов
• Версионность файлов и контроль за изменениями
• Единый и понятный workflow
• Базовый набор инструментов для работы
• Взаимодействие с разработчиками

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

Abstract отвечает за контроль версий и историю изменений мастер-файла библиотеки. Craft используется как библиотека для палитры цветов и замена нативному color инспектору. Lingo отвечает за хранение, подключение и обновление компонентов библиотеки в Sketch файлах.

Такая схема уже сейчас позволяет легко поддерживать библиотеку в актуальном состоянии, контролировать изменения и, что наиболее важно, быстро доставлять обновления дизайнерам. При этом, доступ к мастер-файлу библиотеки имеет только Owner, а остальные участники процесса получают элементы в виде символов и составных компонентов из Lingo. Для доступа к Angular компонентам мы подняли на каждой машине песочницу, чтобы дизайнеры с помощью «npm start» в консоли могли быстро запустить node server и работать с кодом.

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

Abstract

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

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

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

Craft

На данный момент мы используем Craft как библиотеку для цветовой палитры и замену нативному color инспектору. Под рукой не только все цвета, но и названия переменных. Благодаря такому подходу удалось решить еще одну важную проблему. Дизайнеры перестали “пипетить”, а разработчики перестали резонно негодовать, почему в двух макетах у одного и того же элемента отличаются значения цвета. Кто работает в Sketch и использует несколько мониторов знает, что на каждом подключенном мониторе один и тот же цвет взятый пипеткой, в большинстве случаев, будет иметь разный HEX.

Lingo

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

Можно создать несколько библиотек, разбить библиотеку на категории, проставить теги для каждого элемента, а при импорте элементов выбрать какой элемент добавить, а какой нет. При обновлении существующего компонента в библиотеке, Lingo предложит его заменить, сделать дубликат или отказаться от изменений.

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

Несмотря на то, что в Sketch 47 будут библиотеки символов которые уже доступны в бета-версии (работают, кстати, круто), мы не спешим уходить с Lingo из-за его возможностей и большей гибкости в работе.

Плагины

Централизованно мы используем три плагина:

Первый — Shared Text Styles для работы с текстовыми стилями. Позволяет экспортить текстовые стили в JSON, добавлять стили в новый Sketch документ и апдейтить уже подгруженные.

Второй — Relabel button для работы с кнопками. Одна из лучших реализаций плагинов такого рода, на мой взгляд. Достаточно правильно настроить привязки элементов внутри символа.

Третий — Acronis data. Так как мы достаточно много работаем с таблицами и большими массивами данных, я собрал плагин, который генерирует специализированные значения для этих таблиц (offering items, agents name, schedule options, machines и т.д.). Плагин работает на основе dummy data и подтягивает значения из JSON. Перед тем, как собирать кастомное решение, была неудачная попытка подружить единый JSON с Craft, но увы. Как оказалось, Craft не умеет в исходную разметку документа и показывает поля не по порядку.

Иконки

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

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

Angular 4 компоненты

Неважно, насколько прокачана и удобна библиотека пока она существует исключительно в виде Sketch файла. Если в браузере компонент выглядит не так, как в макетах, библиотека уже неактуальна, а исходники устарели и не соответствуют действительности. Благодаря Сергею Сабурову, Кириллу Севёлову и всей команде мониторинга, наши компоненты плавно перетекают в код и работают именно так, как запланировано. Несмотря на то, что часть новых продуктов и сервисов мы уже начали собирать с помощью текущих компонентов, еще не все front-end команды готовы внедрять и использовать эти компоненты у себя. Где-то фронт написан на Ext JS, где-то используется Vue и быстрый переход с одного фреймворка или библиотеки на другой технически невозможен по ряду причин. О том, почему в компании выбрали именно Angular, подробно поговорим в следующей статье. А пока давайте вернемся к библиотеке и посмотрим, как устроены компоненты.

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

А вот так в коде:

Чтобы изменить размер и внешний вид инпута достаточно в свойствах указать

[size] = "'sm'"

Теперь давайте посмотрим на более сложный пример:

Два типа дропдаунов. В первом случае — это список из значений, во втором к списку значений добавляется строка поиска. Переключимся на код:

С помощью #selectChild получаем вложенный компонент для активного значения поля, через (select) подписываемся на событие текущего компонента, а с помощью директивы *ngFor проходим по массиву из значений и выводим их в выпадающем списке. Чтобы включить строку поиска и возможность искать по списку, во втором примере включаем свойство [search]. Как я говорил выше, более подробно об Angular и работе компонентов на front-end стороне мы расскажем в следующей статье. Stay tuned!

Дизайнеры и код

Одна из наших амбициозных и долгосрочных задач — перенести дизайн из Sketch в браузер, чтобы дизайнер мог передавать в разработку не статичные исходники или прототипы, собранные в сторонних приложениях, а готовый код. До того момента, как появились Angular компоненты, для сложных прототипов я продвигал Framer, каждую неделю готовил лекции, рассказывал о принципах и тонкостях работы с Coffee Script. Несмотря на потраченные усилия Framer не прижился по нескольким причинам:

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

От Framer мы полностью не отказались и изредка собираем в нем шоты для Dribbble. Забиваем гвозди микроскопом, да.

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

Заключение

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

Кстати, мы всегда рады опытным дизайнерам. Если вы такой, напишите мне на почту: sergey.nikishkin@acronis.com

Список ссылок

• Abstract
• Craft от Invision
• Lingo
• Shared Text Styles plugin
• Relabel button plugin
• Подробная статья на английском про изменение цвета иконок через overrides
• Facebook
• Dribbble

Прыгаем в одиночку

Паралич выбора

Одиночество

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

Нехватка мотивации

Тревога

Неуверенность в себе

Нестабильность

Страх провала

Заключение

Кто уходит из медицины?

Куда уходят из медицины?

Почему врач-айтишник — редкость?

Почему так много плохих хирургов?

Сколько на самом деле получает хирург?

Почему уход из медицины — не повод для гордости?

Эти тесты показывают, как ведут себя голые серверы, без «прочих нюансов» которые зависят от рук программистов.

Суть тестов

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

GET / HTTP/1.1
Host: service.host

HTTP/1.1 200 OK

Hello World!

GET /greeting/user HTTP/1.1
Host: service.host

HTTP/1.1 200 OK

Hello, user

Первоначальный исходный код тестов

var cluster = require('cluster');
var numCPUs = require('os').cpus().length;
var http = require("http");
var debug = require("debug")("lite");
var workers = [];
var server;

cluster.on('fork', function(worker) {
    workers.push(worker);

    worker.on('online', function() {
        debug("worker %d is online!", worker.process.pid);
    });

    worker.on('exit', function(code, signal) {
        debug("worker %d died", worker.process.pid);
    });

    worker.on('error', function(err) {
        debug("worker %d error: %s", worker.process.pid, err);
    });

    worker.on('disconnect', function() {
        workers.splice(workers.indexOf(worker), 1);
        debug("worker %d disconnected", worker.process.pid);
    });
});

if (cluster.isMaster) {
    debug("Starting pure node.js cluster");

    ['SIGINT', 'SIGTERM'].forEach(function(signal) {
        process.on(signal, function() {
            debug("master got signal %s", signal);
            process.exit(1);
        });
    });

    for (var i = 0; i < numCPUs; i++) {
        cluster.fork();
    }
} else {
    server = http.createServer();

    server.on('listening', function() {
        debug("Listening %o", server._connectionKey);
    });

    var greetingRe = new RegExp("^\/greeting\/([a-z]+)$", "i");
    server.on('request', function(req, res) {
        var match;

        switch (req.url) {
            case "/": {
                res.statusCode = 200;
                res.statusMessage = 'OK';
                res.write("Hello World!");
                break;
            }

            default: {
                match = greetingRe.exec(req.url);
                res.statusCode = 200;
                res.statusMessage = 'OK';
                res.write("Hello, " + match[1]);    
            }
        }

        res.end();
    });

    server.listen(8080, "127.0.0.1");
}

package main

import (
    "fmt"
    "net/http"
    "regexp"
)

func main() {
    reg := regexp.MustCompile("^/greeting/([a-z]+)$")
    http.ListenAndServe(":8080", http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        switch r.URL.Path {
        case "/":
            fmt.Fprint(w, "Hello World!")
        default:
            fmt.Fprintf(w, "Hello, %s", reg.FindStringSubmatch(r.URL.Path)[1])
        }
    }))
}

extern crate hyper;
extern crate regex;

use std::io::Write;
use regex::{Regex, Captures};

use hyper::Server;
use hyper::server::{Request, Response};
use hyper::net::Fresh;
use hyper::uri::RequestUri::{AbsolutePath};

fn handler(req: Request, res: Response) {
    let greeting_re = Regex::new(r"^/greeting/([a-z]+)$").unwrap();

    match req.uri {
        AbsolutePath(ref path) => match (&req.method, &path[..]) {
            (&hyper::Get, "/") => {
                hello(&req, res);
            },
            _ => {
                greet(&req, res, greeting_re.captures(path).unwrap());
            }
        },
        _ => {
            not_found(&req, res);
        }
    };
}

fn hello(_: &Request, res: Response) {
    let mut r = res.start().unwrap();
    r.write_all(b"Hello World!").unwrap();
    r.end().unwrap();
}

fn greet(_: &Request, res: Response, cap: Captures) {
    let mut r = res.start().unwrap();
    r.write_all(format!("Hello, {}", cap.at(1).unwrap()).as_bytes()).unwrap();
    r.end().unwrap();
}

fn not_found(_: &Request, mut res: Response) {
    *res.status_mut() = hyper::NotFound;
    let mut r = res.start().unwrap();
    r.write_all(b"Not Found\n").unwrap();
}

fn main() {
    let _ = Server::http("127.0.0.1:8080").unwrap().handle(handler);
}

package lite

import akka.actor.{ActorSystem, Props}
import akka.io.IO
import spray.can.Http
import akka.pattern.ask
import akka.util.Timeout
import scala.concurrent.duration._
import akka.actor.Actor
import spray.routing._
import spray.http._
import MediaTypes._
import org.json4s.JsonAST._

object Boot extends App {
  implicit val system = ActorSystem("on-spray-can")
  val service = system.actorOf(Props[LiteActor], "demo-service")
  implicit val timeout = Timeout(5.seconds)
  IO(Http) ? Http.Bind(service, interface = "localhost", port = 8080)
}

class LiteActor extends Actor with LiteService {
  def actorRefFactory = context
  def receive = runRoute(route)
}

trait LiteService extends HttpService {
  val route =
    path("greeting" / Segment) { user =>
      get {
        respondWithMediaType(`text/html`) {
          complete("Hello, " + user)
        }
      }
    } ~
    path("") {
      get {
        respondWithMediaType(`text/html`) {
          complete("Hello World!")
        }
      }
    }
}

Подлый удар в спину

Восстанавливаем справедливость

extern crate hyper;
extern crate regex;

#[macro_use] extern crate lazy_static;

use std::io::Write;
use regex::{Regex, Captures};

use hyper::Server;
use hyper::server::{Request, Response};
use hyper::net::Fresh;
use hyper::uri::RequestUri::{AbsolutePath};

fn handler(req: Request, res: Response) {
    lazy_static! {
        static ref GREETING_RE: Regex = Regex::new(r"^/greeting/([a-z]+)$").unwrap();
    }

    match req.uri {
        AbsolutePath(ref path) => match (&req.method, &path[..]) {
            (&hyper::Get, "/") => {
                hello(&req, res);
            },
            _ => {
                greet(&req, res, GREETING_RE.captures(path).unwrap());
            }
        },
        _ => {
            not_found(&req, res);
        }
    };
}

fn hello(_: &Request, res: Response) {
    let mut r = res.start().unwrap();
    r.write_all(b"Hello World!").unwrap();
    r.end().unwrap();
}

fn greet(_: &Request, res: Response, cap: Captures) {
    let mut r = res.start().unwrap();
    r.write_all(format!("Hello, {}", cap.at(1).unwrap()).as_bytes()).unwrap();
    r.end().unwrap();
}

fn not_found(_: &Request, mut res: Response) {
    *res.status_mut() = hyper::NotFound;
    let mut r = res.start().unwrap();
    r.write_all(b"Not Found\n").unwrap();
}

fn main() {
    let _ = Server::http("127.0.0.1:3000").unwrap().handle(handler);
}

Окружение

1. Ноут
   
   • Intel® Core(TM) i7-6820HQ CPU @ 2.70GHz, 4+4
   • CPU Cache L1: 128 KB, L2: 1 MB, L3: 8 MB
   • 8+8 GB 2133MHz DDR3
   
   
2. Десктоп
   
   • Intel® Core(TM) i3 CPU 560 @ 3.33GHz, 2+2
   • CPU Cache L1: 64 KB, L2: 4 MB
   • 4+4 GB 1333MHz DDR3
   
   
3. go 1.6.2, released 2016/04/20
   
4. rust 1.5.0, released 2015/12/10
   
5. Простите, любители Scala и Node.js, этот холивар не про вас.
   

Интрига

Десктоп

Ноут

Ноут на подзарядке

Выводы

Эту уязвимость чинят уже пятнадцать лет

1. расшифровать все его блоки;
2. прочитать последний байт последнего блока, чтобы определить длину набивки и, соответственно, позицию MAC в открытом тексте;
3. проверить корректность набивки и MAC.

Своё название эта атака получила из-за того, что размер заголовка, хешируемого перед «полезной нагрузкой», ограничил перебор вариантов набивки двухбайтными последовательностями. Будь этот заголовок 14-байтным или длинее, скачок во времени отклика сервера пришёлся бы на более короткие куски открытого текста, и перебирать бы приходилось в сотни раз больше вариантов набивки. С другой стороны, будь этот заголовок 11-байтным, скачок бы пришёлся на переход между 8 и 9 блоками открытого текста, и атака была бы совершенно невозможна. Ну а самое счастливое число — конечно же, 12: с такой длиной заголовка для атаки было бы достаточно перебирать значения последнего байта самого по себе, как и в атаке Воденэ.

Техническое замечание: даже если POST-запрос оканчивается на последовательность из байтов 31, перед CBC-шифрованием он будет дополнен MAC и набивкой, так что в описанном виде атака не сработает. Подготовительный этап атаки — варьируя запрашиваемый путь, подобрать такую длину POST-запроса, чтобы MAC и настоящая набивка заняли последние два CBC-блока целиком; затем в ходе атаки эти последние два блока будут отбрасываться, а использоваться будут блоки от пятого до третьего с конца. Наладив такую координацию действий между скриптом, генерирующим HTTPS-запросы, и MitM-сервером, злоумышленник может обеспечить, что результат CBC-расшифровки будет оканчиваться на 31 байт со значением 31.

Confideal: чистим грязный цвет

Кузнецкий техникум: улучшаем читаемость

Aircraft: убираем обводку

Разноторг: улучшаем композицию

Как итог

Цикл статей «DevOps с Kubernetes и VSTS»

CI/CD пайплайн для Kubernetes в VSTS

Развертывание среды k8s с помощью служб контейнеров Azure

# set some variables
export RG="cd-k8s"
export clusterName="cdk8s"
export location="westus"
# create a folder for the cluster ssh-keys
mkdir cdk8s
 
# login and create a resource group
az login
az group create --location $location --name $RG
 
# create an ACS k8s cluster
az acs create --orchestrator-type=kubernetes --resource-group $RG --name=$ClusterName --dns-prefix=$ClusterName --generate-ssh-keys --ssh-key-value ~/cdk8s/id_rsa.pub --location $location --agent-vm-size Standard_DS1_v2 --agent-count 2
 
# create an Azure Container Registry
az acr create --resource-group $RG --name $ClusterName --location $location --sku Basic --admin-enabled
 
# configure kubectl
az acs kubernetes get-credentials --name $ClusterName --resource-group $RG --file ~/cdk8s/kubeconfig --ssh-key-file ~/cdk8s/id_rsa
export KUBECONFIG="~/cdk8s/kubeconfig"
 
# test connection
kubectl get nodes
NAME                    STATUS                     AGE       VERSION
k8s-agent-96607ff6-0    Ready                      17m       v1.6.6
k8s-agent-96607ff6-1    Ready                      17m       v1.6.6
k8s-master-96607ff6-0   Ready,SchedulingDisabled   17m       v1.6.6

• Строки 2–4: создаем переменные.
• Строка 6: создаем каталог для ssh-ключей и файла конфигурации kubeconfig.
• Строка 9: входим в систему в Azure (запрос на открытие в браузере страницы с меню входа; если у вас нет подписки Azure, создайте бесплатную прямо сейчас!).
• Строка 10: создаем группу для размещения всех ресурсов, которые мы собираемся создать.
• Строка 13: развертываем кластер k8s с использованием только что созданной группы ресурсов и имени, которое мы передаем; генерируем ssh-ключи и помещаем в указанный каталог; нам нужны два агента (узла) с указанным размером виртуальной машины.
• Строка 16: создаем реестр контейнеров Azure в той же группе ресурсов с доступом от имени администратора.
• Строка 19: получаем учетные данные для подключения к кластеру с помощью kubectl; используем полученный ssh-ключ и сохраняем учетные данные в указанном файле kubeconfig.
• Строка 20: просим kubectl использовать эту конфигурацию вместо конфигурации по умолчанию (которая может иметь другие кластеры k8s или конфигурацию minikube).
• Строка 23: проверяем возможность подключения к кластеру.
• Строки 24–27: мы успешно подключаемся!

Пространства имен

apiVersion: v1
kind: Namespace
metadata:
  name: dev
---
apiVersion: v1
kind: Namespace
metadata:
  name: prod

kubectl apply -f namespaces.yml
namespace "dev" created
namespace "prod" created
 
kubectl get namespaces
NAME          STATUS    AGE
default       Active    27m
dev           Active    20s
kube-public   Active    27m
kube-system   Active    27m
prod          Active    20s

Настройка секрета для реестра контейнеров

az acr credential show --name $ClusterName --output table
USERNAME    PASSWORD                          PASSWORD2
----------  --------------------------------  --------------------------------
cdk8s       some-long-key-1                   some-long-key-2

kubectl create secret docker-registry regsecret --docker-server=$ClusterName.azurecr.io --docker-username=$ClusterName --docker-password= --docker-email=admin@azurecr.io
secret "regsecret" created
 

Настройка конечных точек VSTS

Сборка

• Tasks -> Process: введите имя, например k8s-demo-CI, и выберите очередь Hosted Linux Preview.
• Опционально: измените формат номера сборки на 1.0.0$(rev:.r), чтобы ваши сборки имели формат 1.0.0.x.
• Tasks -> Get Sources: выберите репозиторий Github с проверкой подлинности OAuth или PAT. Выберите AzureAureliaDemo, а затем docker в качестве ветки по умолчанию. Возможно, вам придется создать «вилку» для репозитория (или просто импортировать его в VSTS), если вы выполняете действия вместе со мной.
• Tasks -> DotNet Restore: не вносите никаких изменений.
• Tasks -> DotNet Build: добавьте --version-suffix $(Build.BuildNumber) в аргументы сборки, чтобы обеспечить соответствие версии и номера сборки.
• Tasks -> DotNet Test: отключите эту задачу, поскольку в нашем решении не применяются тесты DotNet (конечно, если у вас будут тесты, задачу можно снова включить).
• Tasks -> добавьте задачу npm. В качестве рабочего каталога выберите frontend и убедитесь, что используется команда install.
• Tasks -> добавьте задачу Command line. В качестве инструмента (tool) выберите node, укажите аргументы: node_modules/aurelia-cli/bin/aurelia-cli.js test и рабочий каталог: frontend. Так вы запустите тесты Aurelia.
• Tasks -> добавьте задачу Publish test results. В поле Test Results files укажите test*.xml, а в поле Search Folder введите $(Build.SourcesDirectory)/frontend/testresults. Так вы опубликуете результаты тестов Aurelia.
• Tasks -> добавьте задачу Publish code coverage. В поле Coverage Tool введите Cobertura, в поле Summary File — $(Build.SourcesDirectory)/frontend/reports/coverage/cobertura.xml, в поле Report Directory — $(Build.SourcesDirectory)/frontend/reports/coverage/html. Так вы опубликуете данные о покрытии тестов Aurelia.
• Tasks -> добавьте задачу Command line. В качестве инструмента (tool) выберите node, укажите аргументы: node_modules/aurelia-cli/bin/aurelia-cli.js test и рабочий каталог: frontend. Так вы скомпилируете, обработаете и упакуете приложение Aurelia SPA.
• Tasks -> DotNet Publish. В качестве аргументов введите -c $(BuildConfiguration) -o publish и снимите флажок Zip Published Projects.
• Tasks -> добавьте задачу Docker Compose. В поле Container Registry Type укажите Azure Container Registry, в качестве подписки и реестра контейнеров Azure укажите реестр, для которого мы создали конечную точку ранее. В поле Additional Docker Compose Files укажите docker-compose.vsts.yml, в поле Action — Build service images, в поле Additional Image Tags — $(Build.BuildNumber), чтобы номер сборки использовался в качестве тега для образов.
• Создайте клон задачи Docker Compose. В качестве имени укажите Push service images и выберите действие Push service images. Установите флажок Include Latest Tag.
• Tasks -> Publish Artifact. В полях Path to Publish и Artifact Name выберите k8s. Так вы опубликуете файлы k8s yaml, чтобы включить их в выпуск.

Выпуск

• Replace Tokens.
  • Source Path: в проводнике откройте каталог k8s.
  • Target File Pattern: *-release.yml. Таким образом, токен будет заменен в любом файле yml с именем, которое оканчивается на -release. Таких файлов три: файлы службы/развертывания для сервера и клиента, а также файл конфигурации клиента. Эта задача находит токены в файле (с префиксом и постфиксом __) и ищет переменные с таким же именем. Каждая переменная заменяется своим значением. Через некоторое время мы создадим переменные.
• Kubernetes Task 1 (применить конфигурацию для клиента).
  • Настройте подключение k8s к созданной ранее конечной точке. Также необходимо настроить подключение к реестру контейнеров Azure. Это касается всех задач Kubernetes. В поле Command выберите apply, поставьте флажок Use Configuration Files и укажите файл k8s/app-demo-frontend-config-release.yml с помощью средства выбора файлов. Укажите --namespace $(namespace) в текстовом поле для аргументов.
    
• Kubernetes Task 2 (применить определение службы/развертывания на стороне сервера).
  • Задайте одинаковые параметры подключения для службы k8s и реестра контейнеров Azure. В этот раз в поле Secret Name укажите regsecret (это имя секрета, который мы создали при настройке кластера k8s, а также имя, на которое мы ссылаемся в параметре imagePullSecret в определениях развертывания). Поставьте флажок Force update secret. Это обеспечит совпадение значений секрета k8s и ключа из Azure. Этот параметр можно было пропустить, поскольку ключ мы создали вручную.
  • В поле Command выберите apply, поставьте флажок Use Configuration Files и укажите файл k8s/app-demo-backend-release.yml с помощью средства выбора файлов. Укажите --namespace $(namespace) в текстовом поле для аргументов.
    
    
• Kubernetes Task 3 (применить определение службы/развертывания на стороне клиента).
  • Настройки аналогичны предыдущей задаче, только выбираем файл k8s/app-demo-frontend-release.yml.
• Kubernetes Task 4 (обновить образ на стороне сервера).
  • Задайте одинаковые параметры подключения для службы k8s и реестра контейнеров Azure. Секрет здесь не требуется. В поле Command выберите set, а в поле Arguments укажите image deployment/demo-backend-deployment backend=$(ContainerRegistry)/api:$(Build.BuildNumber) --record --namespace=$(namespace).
  • Так вы обновите версию (тег) используемого образа контейнера. K8s выполнит последовательное обновление, запустив новые контейнеры и отключив старые, и служба все это время будет работоспособна.
    
    
• Kubernetes Task 5 (обновить образ на стороне клиента).
  • Параметры аналогичны предыдущей задаче, только в поле Arguments необходимо указать image deployment/demo-frontend-deployment frontend=$(ContainerRegistry)/frontend:$(Build.BuildNumber) --record --namespace=$(namespace)
• Нажмите кнопку «…» на карточке dev и щелкните Configure Variables для настройки переменных. Задайте следующие значения:
  • BackendServicePort: 30081
  • FrontendServicePort: 30080
  • ContainerRegistry: <ваше реестр контейнеров>.azurecr.io
  • namespace: $(Release.EnvironmentName)
  • AspNetCoreEnvironment: development
  • baseUri: http://$(BackendServiceIP)/api
  • BackendServiceIP: 10.0.0.1
    
    

apiVersion: v1
kind: Service
metadata:
  name: demo-frontend-service
  labels:
    app: demo
spec:
  selector:
    app: demo
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      nodePort: __FrontendServicePort__
  type: LoadBalancer
---
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: demo-frontend-deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: demo
        tier: frontend
    spec:
      containers:
        - name: frontend
          image: __ContainerRegistry__/frontend
          ports:
          - containerPort: 80
          env:
          - name: "ASPNETCORE_ENVIRONMENT"
            value: "__AspNetCoreEnvironment__"
          volumeMounts:
            - name: config-volume
              mountPath: /app/wwwroot/config/
          imagePullPolicy: Always
      volumes:
        - name: config-volume
          configMap:
            name: demo-app-frontend-config
      imagePullSecrets:
        - name: regsecret

az acs kubernetes browse -n $ClusterName -g $RG --ssh-key-file ~/cdk8s/id_rsa
 
Proxy running on 127.0.0.1:8001/ui
Press CTRL+C to close the tunnel...
Starting to serve on 127.0.0.1:8001

Создание производственной среды

Проход по всему CI/CD конвееру

Заключение

Введение

Вначале хорошее

Теперь о том, что мы делать не будем

Переходим к делу

Конфигурирование среды для версии, отличной от VS2010

Настраиваем проект в Visual Studio

Небольшой совет для тех, кто загорелся всерьез

Полезно будет сразу в Tools->Options настроить рабочий каталог на c:\FW\VS, но если в VS ведется другой, рабочий проект, то так делать не надо:

Создание проекта

Настройка NMake опций

set NASM_PREFIX=C:\FW\NASM\
call c:\FW\edk2\edksetup.bat --nt32
build

set NASM_PREFIX=C:\FW\NASM\
call c:\FW\edk2\edksetup.bat --nt32 
build clean
build

set NASM_PREFIX=C:\FW\NASM\
call  c:\FW\edk2\edksetup.bat --nt32 
build clean

Настройка опции Debugging

C:\FW\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\SecMain.exe

C:\FW\edk2\Build\NT32IA32\DEBUG_VS2010x86\IA32\

Построение проекта

Работа в UEFI Shell

Выводим свою строку

Print (L"I did it in UEFI!\r\n");

Аналитические обзоры

Практические материалы

Немного о человеческих ресурсах и опыте успешных компаний

Что еще почитать по теме

Несколько источников освещения

1. OpenGL
2. Создание окна
3. Hello Window
4. Hello Triangle
5. Shaders
6. Текстуры
7. Трансформации
8. Системы координат
9. Камера

1. Цвета
2. Основы освещения
3. Материалы
4. Текстурные карты
5. Источники света

Направленный источник освещения

Также как в C и C++, если мы хотим вызвать функцию (в нашем случае внутри функции main) функция должна быть объявлена где-нибудь до того момента, где мы её вызываем. В нашем случае, мы объявим прототип над функцией main, а опишем её где нибудь ниже.

Точечные источники освещения

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

Объединяем всё вместе

Задания