...

суббота, 27 июля 2019 г.

[Из песочницы] Заметка для фронтендеров: что проверить перед тестированием

Всем привет!

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

Когда вы передаете окончательную версию продукта в службу контроля качества, вы должны рассчитывать на то, что контроль не выявит никаких проблем. Было бы в высшей степени непрофессионально передавать на контроль качества заведомо дефектный код. А какой код является заведомо дефектным? Любой, в качестве которого вы не уверены!

«Идеальный программист. Как стать профессионалом разработки ПО»
Роберт С. Мартин


Верстать по прототипам.

Так бывает, что дизайнеры — это прекрасные эльфы с высокой башни, и «они так видят». И иногда проще сделать по-своему, чем следовать прототипу. Но обычно эти ребята на нашей стороне, и рисуя, они держат голове (или на бумаге) какие-то аргументы почему сделано так, в чём ценность. И если кажется, что нарисовано что-то странное — всегда можно обсудить.

Если что-то невозможно (читай очень дорого) сделать — так и надо сказать. Очень, очень, очень стрёмно видеть свежие прототипы, что не сходятся со свежей задачей.


Найди N отличий. Прототип слева.


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

Но всё меняется, когда есть они — инпуты.

В них крайне необходимо вводить всякое:

  • Много текста.
  • Разный текст: буквы, цифры, спецсимволы и т.д.
  • Мало текста. Можно ли ничего не вводить и как это потом будет выглядеть?
  • Текст не того формата или невалидный текст.
  • На десерт: большие строки вообще без пробелов.
  • Пробелы: лидирующие и замыкающие.

Скрытый текст
Типичный фронтендер может задаться вопросом: а много текста — это сколько? На это есть у меня ответ: столько, сколько влезет в инпут. Нет ограничений на длину? Можно ввести 10-20 тыс. знаков и посмотреть на результат. Может ваш бэкенд не готов к таким объёмам? На минуточку, 20 тыс. знаков — это вот столько:


A4, Times New Roman, 12 кегль, межстрочный — 1.


Про лидирующие и замыкающие пробелы.

Они не нужны в 99% случаев, кроме, быть может, только для паролей, но это неточно. У меня был опыт, когда приложение падало из-за наличия пробела в конце логина. Он остался после копирования строки из почты. Так что: тримьте пробелы!

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

Проверяем всё то же самое:

  • Большие тексты, с пробелами или же без оных.
  • Тексты с переносами строк, абзацами. Иногда вставляю стихи для этого.
  • Минимальный набор данных. Всё ли остаётся на месте, когда ничего или почти ничего нет?
  • Отображение не всех полей от сложной сущности. Они могут быть пустыми.

Под катом, немного живых примеров.
Скрытый текст

Порой нельзя просто взять и ввести что хочется — срабатывают валидации.

Что делать?

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

Хинт: текст можно вводить ещё и копированием.


Я понимаю, первая реакция какая-то такая.

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


Тут почти как с IE, только не больно.

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

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

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

Хочется отметить, что статья будет полезна если у вас и вовсе нет тестировщика. Поэтому в конце ещё раз краткое содержание:

  • Верстать по прототипам.
  • Вводить разнообразные данные: много, мало, в_одно_слово, не вводить.
  • Тримить пробелы.
  • Проверять валидации.
  • IE.
  • Не забыть метрики.

ЧаВо


В: Тестировщики всё найдут!
О: Не всё. Тестировщики — это вам не HEPA-фильтр, а люди. И если на этапе разработки кто-то не сделал свою часть работы, то она никуда не девается, а просто переходит кому-то другому.

Наверстали, но не посмотрели? Значит с этим будут работать другие люди, тратить не только время, но и свои силы. Человек устаёт, глаз замыливается, усталость накапливается. И за валом таких проблем могут быть пропущены более серьёзные вещи.

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

Спасибо за внимание.

Let's block ads! (Why?)

[Перевод] 5 заповедей TypeScript-разработчика

image

Всё больше и больше проектов и команд используют TypeScript. Однако просто применять TypeScript и выжимать из него максимум пользы — это очень разные вещи.

Представляю вам список высокоуровневых передовых практик использования TypeScript, которые помогут получить максимум преимуществ от применения этого языка.


Не лгите

Типы — это контракт. Что это значит? Когда вы реализуете функцию, её тип становится обещанием, данным другим разработчикам (или вам же самим в будущем!), что, будучи вызвана, эта функция вернет определенный тип значения.

В следующем примере тип функции getUser гарантирует, что она возвращает объект, у которого всегда есть два свойства: name и age.

interface User {
  name: string;
  age: number;
}

function getUser(id: number): User { /* ... */ }

TypeScript — очень гибкий язык. В нем много компромиссов, призванных облегчить внедрение языка. Например, он позволяет вам реализовать функцию getUser вот так:

function getUser(id: number): User {
  return { age: 12 } as User;
}

Не делайте так! Это ЛОЖЬ. Создавая такой код, вы ЛЖЕТЕ другим разработчикам (которые будут использовать вашу функцию в своих функциях). Они ожидают, что у объекта, возвращаемого функцией getUser, всегда будет какое-то поле name. Но его нет! Далее, что произойдет, когда ваш коллега напишет getUser(1).name.toString()? Вы прекрасно знаете, что…

Здесь, конечно, ложь выглядит очевидной. Однако, работая с большой базой кода, вы будете часто оказываться в ситуациях, когда значение, которое вы хотите вернуть (или передать), почти совпадает с ожидаемым типом. Чтобы найти причину несовпадения типов, нужны время и усилия, а вы торопитесь… поэтому вы решаете использовать приведение типов.

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

Не лгите. Соблюдайте свои контракты.


Будьте точны

Типы — это документация. Документируя функцию, разве вы не хотите донести как можно больше информации?

// Возвращает объект
function getUser(id) { /* ... */ }

// Возвращает объект с двумя свойствами: name и age
function getUser(id) { /* ... */ }

// Если id является числом и пользователь с данным id существует,
// возвращает объект с двумя свойствами: name и age.
// В противном случае возвращает undefined.
function getUser(id) { /* ... */ }

Какой комментарий для функции getUser вам бы больше понравился? Чем больше вы знаете о том, что возвращает функция, тем лучше. Например, зная, что она может вернуть undefined, вы можете написать блок if для проверки того, определен ли объект, который вернула функция, — перед тем, как запрашивать свойства этого объекта.

Ровно то же самое и с типами: чем более точно описан тип, тем больше информации он передает.

function getUserType(id: number): string { /* ... */ }

function getUserType(id: number): 'standard' | 'premium' | 'admin' { /* ... */ }

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

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

interface State {
  isLoading: boolean;
  data?: string[];
  errorMessage?: string;
}

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

Мы можем сделать тип намного более точным с помощью разграничивающих объединяющих типов (discriminated union types):

type State =
   | { status: 'loading' }
   | { status: 'successful', data: string[] }
   | { status: 'failed', errorMessage: string };

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

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


Начинайте с типов

Так как типы являются одновременно и контрактом, и документацией, они отлично подходят для проектирования ваших функций (или методов).

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

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

В React JS есть понятие компонента высшего порядка (Higher Order Components, HOC). Это функции, которые каким-либо образом расширяют заданный компонент. К примеру, вы можете создать компонент высшего порядка withLoadingIndicator, который добавляет индикатор загрузки в существующий компонент.

Давайте напишем сигнатуру типа для этой функции. Функция принимает на вход компонент и возвращает тоже компонент. Для представления компонента мы можем воспользоваться типом React ComponentType.

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

Окончательно оформим тип. withLoadingIndicator принимает компонент типа ComponentType<P>, где P обозначает тип свойств. withLoadingIndicator возвращает компонент с расширенными свойствами типа P & { isLoading: boolean }.

const withLoadingIndicator = <P>(Component: ComponentType<P>) 
    : ComponentType<P & { isLoading: boolean }> =>
        ({ isLoading, ...props }) => { /* ... */ }

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

Начинайте с типов. Пусть типы вынуждают вас сначала проектировать, и лишь после этого писать реализацию.


Примите строгость

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

Можно помочь компилятору выполнять эту работу еще лучше, включив флаг --strict. Это мета-флаг, который подключает все опции строгой проверки типов: --noImplicitAny, --noImplicitThis, --alwaysStrict, --strictBindCallApply, --strictNullChecks, --strictFunctionTypes и --strictPropertyInitialization.

Что делают это флаги? Говоря в общем, их включение приводит к увеличению количества ошибок компиляции TypeScript. И это хорошо! Больше ошибок компиляции — больше помощи от компилятора.

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

function getUser(id: number): User {
    if (id >= 0) {
        return { name: 'John', age: 12 };
    } else {
        return undefined;
    }
}

Тип getUser гарантирует, что функция всегда возвращает объект типа User. Однако посмотрите на реализацию: функция может также вернуть значение undefined!

К счастью, включение флага --strictNullChecks приводит к ошибке компиляции:

Type 'undefined' is not assignable to type 'User'.

Компилятор TypeScript обнаруживает ложь. Чтобы избавиться от этой ошибки, просто честно скажите всю правду:

function getUser(id: number): User | undefined { /* ... */ }

Примите строгость проверки типов. Пусть компилятор оберегает вас от ошибок.


Будьте в курсе

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

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

Например, в версии 2.0 были представлены Discriminated Union Types (я упомянул их в заповеди Будьте точны).

Версия 3.2 представила флаг компилятора --strictBindCallApply, который включает корректную типизацию для функций bind, call и apply.

Версия 3.4 улучшила выведение типов (type inference) в функциях высшего порядка, что облегчило использование точных типов при написании кода в функциональном стиле.

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

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

Будьте в курсе новых возможностей языка, и пусть это знание работает на вас.


Резюме

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

Буду рад увидеть ваши мысли на этот счет в комментариях.


Бонус

Понравилась эта статья о TypeScript? Уверен, вам также понравится и этот бесплатный PDF: 10 ошибок разработки на TypeScript, которые делают ваш код небезопасным

Let's block ads! (Why?)

Пост-анализ: что известно о последней атаке на сеть серверов криптоключей SKS Keyserver

Хакеры использовали особенность протокола OpenPGP, о которой известно более десяти лет.

Рассказываем, в чем суть и почему её не могут закрыть.


/ Unsplash / Chunlea Ju

Проблемы в сети


В середине июня неизвестные провели атаку на сеть серверов криптографических ключей SKS Keyserver, построенную на базе протокола OpenPGP. Это — стандарт IETF (RFC 4880), который используется для шифрования электронной почты и других сообщений. Сеть SKS создали тридцать лет назад для распространения публичных сертификатов. К ней подключаются такие инструменты, как GnuPG для шифрования данных и создания электронных цифровых подписей.

Хакеры скомпрометировали сертификаты двух мейнтейнеров проекта GnuPG — Роберта Хансена (Robert Hansen) и Дэниела Гиллмора (Daniel Gillmor). Загрузка испорченного сертификата с сервера приводит к сбою в работе GnuPG — система просто зависает. Есть основания полагать, что на этом злоумышленники не остановятся, и число скомпрометированных сертификатов будет лишь увеличиваться. На текущий момент масштабы проблемы остаются неизвестными.

Суть атаки


Хакеры воспользовались уязвимостью в протоколе OpenPGP. Она известна сообществу уже не один десяток лет. Даже на GitHub можно найти соответствующие эксплойты. Но пока никто не взял на себя ответственность по закрытию «дырки» (далее поговорим о причинах подробнее).
Пара подборок из нашего блога на Хабре:

Согласно спецификации OpenPGP кто угодно может добавлять цифровые подписи к сертификатам для подтверждения их владельца. Причем максимальное число подписей никак не регламентировано. И здесь возникает проблема — сеть SKS позволяет разместить до 150 тыс. подписей на один сертификат, но GnuPG такое их количество не поддерживает. Таким образом, при загрузке сертификата GnuPG (как, впрочем, и другие реализации OpenPGP) зависает.

Один из пользователей провел эксперимент — импорт сертификата занял у него примерно 10 минут. Сертификат имел более 54 тыс. подписей, а его вес составил 17 Мбайт:

$ gpg --homedir=$PWD --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6
gpg: key F20691179038E5C6: 4 duplicate signatures removed
gpg: key F20691179038E5C6: 54614 signatures not checked due to missing keys
gpg: key F20691179038E5C6: 4 signatures reordered
gpg: key F20691179038E5C6: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1
$ ls -lh pubring.gpg
-rw-r--r--  1 filippo  staff    17M  2 Jul 16:30 pubring.gpg


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

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

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


Для закрытия уязвимости не было повода. Ранее её не использовали для проведения хакерских атак. Хотя ИТ-сообщество давно просило разработчиков SKS и OpenPGP обратить внимание на проблему.

Справедливости ради стоит отметить, что в июне они все же запустили экспериментальный сервер ключей keys.openpgp.org. В нем реализована защита от подобных типов атак. Однако его база данных заполняется с нуля, а сам сервер не является частью SKS. Поэтому пройдет время, прежде чем им можно будет пользоваться.


/ Unsplash / Rubén Bagüés

Что касается бага в оригинальной системе, то исправить его мешает сложный механизм синхронизации. Сеть серверов ключей изначально писалась как proof of concept для защиты докторской диссертации Яроном Мински (Yaron Minsky). Причем для работы был выбран довольно специфический язык OCaml. По словам мейнтейнера Роберта Хансена, разобраться в коде сложно, поэтому в него вносятся лишь небольшие исправления. Чтобы модифицировать архитектуру SKS, её придется переписать с нуля.

В любом случае в GnuPG не верят, что сеть когда-нибудь удастся исправить. В посте на GitHub разработчики даже написали, что не рекомендуют работать с SKS Keyserver. Собственно, это одна из главных причин, почему они инициировали переход на новый сервис keys.openpgp.org. Нам остается лишь наблюдать за дальнейшим развитием событий.

Пара материалов из нашего корпоративного блога:

Let's block ads! (Why?)

Самодельная лазерная установка на парах меди “Lightsaber” – часть 3, заключительная

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

image
Итак, Вам понадобится следующая утварь:

  1. Неповрежденное тело скоропостижно скончавшегося. Поврежденные, фрагментированные, деформированные тела не подходят.
  2. Высоковольтный источник питания с необходимыми выходными параметрами.
  3. Вакуумный насос (достаточно любого роторного двухступенчатого).
  4. Сосуд со сжатым духом для нашего клиента. Где брать – спрашивайте у торговцев мертвыми душами. Не любой «дух» подходит, остерегайтесь контрафакта.
  5. Любое зеркало и любой кусок любого прозрачного стекла.
  6. Шланги, измеритель давления, самая тонкая медицинская игла для дозировки.

Проведение ритуала: уложите неповрежденный труп на жесткую диэлектрическую и огнеупорную поверхность. Срежьте стеклянные «бородавки» на теле, в левой и правой части и приварите на их место штуцеры из такого же сорта стекла для полной приживаемости. Соедините левый штуцер с насосом, правый – с источником «духа», который непосвященные неоном называют. Подключите кабель от высоковольтного источника к металлическим конечностям на теле. Выкачайте весь воздух из тела вакуумным насосом и впустите ровно столько неона, чтобы давление было в пределах 100 мм рт. ст. Начинайте гальванизировать труп напряжением примерно в 25-30% от номинального, должно наблюдаться яркое красно-оранжевое свечение. Выждите время в 5-10 минут. Продолжайте гальванизацию полным напряжением в течении получаса, пока внутренности тела не раскалятся дожелта, а свечение не приобретет оттенок гнилого болота. В скорости после этого труп должен проявить признаки жизни в виде излучаемого им сравнительно яркого и направленного зеленого свечения в виде 2 пучков. Расположите зеркало и кусок стекла в голове и ногах так, чтобы они были параллельны и создавали в себе бесконечное количество отражений нашего клиента. В этом случае подопытный должен излучать очень яркий и разрушительный свет в виде узкого параллельного пучка с такими же показателями как и у вполне живого и на 100% здорового лазера на парах меди. Тем не менее, живым он в полной мере не является, так как нуждается в аппаратуре, отключение от которой убьет его снова, до следующего раза.

Дополнительную информацию не вошедшую в данную инструкцию ищите в «Книге мертвых», «Некрономиконе» в списке литературы.

Черт знает, были ли лазеры с вакуумными насосами у Виктора Франкенштейна, но источник питания у него был точно.

А теперь серьёзно.

Да, я давно тут ничего не писал. За это время я успел проделать много экспериментов, попутно удалось улучшить условия для работы, обзавестись новым оборудованием. Основная «домашняя лаборатория» переместилась в сухой и хорошо защищенный подвал дома.
В ней удалось разместить небольшой вакуумный пост с форвакуумным и диффузионным насосом.

image

image

Рядом расположился набор баллонов с основными газами, которые нужны для лазеров – это гелий, аргон ОСЧ 6.0 и ещё неон ОСЧ 5.0.

image

Таким образом, появилась возможность откачивать и заново заправлять АЭ газовых лазеров. В первой и второй частях я упоминал, что активный элемент лазера типа УЛ-102, который послужил основой для данного проекта внезапно натек и стал более непригодным к использованию. В результате пришлось искать и приобретать новый АЭ, который и работает безотказно в данном лазере до сих пор. Тем не менее, неисправный АЭ не остался бесполезным. Потренироваться решил именно на нём.

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

image

Тогда я смог подключить к одному штуцеру вакуумный насос 3НВР1Д, а ко второму шланг для напуска газа в лазер. Внутрь шланга вставлена инсулиновая игла, которая выполняет функцию натекателя для точной дозировки газа. Другим шлангом она соединяется уже непосредственно с редуктором на баллоне. Между лазерной трубкой и насосом включена обычная склянка Дрекселя для улавливания выброшенного масла из насоса, если он внезапно остановится и точный вакуумметр с ценой деления порядка 2 мм рт. ст. Питание же к лазеру подключается как обычно – параллельно электродам включен обостряющий конденсатор из двух к15у-1 по 470 пФ 15 кВ и коаксиальный кабель соединяющий трубку с источником питания. Источник питания подробно описан в предыдущих частях.

Первоначально была идея заменить в лазере рабочий газ – использовать аргон вместо неона, поскольку согласно литературе лазер сохраняет работоспособоность с аргоном и при этом сильно удешевляется первичная тренировка трубки, направленная на удаление всех нежелательных примесей из активной зоны попавших туда с воздухом. Но это не сработало. Разряд поджигался со значительным перенапряжением в момент поджига, поскольку у аргона более высокий потенциал ионизации в отличии от неона и сильно нарушалось согласование лазерной трубки с источником. Кроме того, разряд имел тенденцию к сильному сжатию в тонкий шнур и последующему нестабильному горению, вплоть до зажигания не с рабочих электродов а с окружающих металлических частей и дальнейшему срыву. Итог был один – отключение источника по защите от КЗ, поскольку тиратрон в силовой части терял управляемость, или загоралась дуга в самом источнике. Жертвами этого эксперимента стали 2 вентилятора в силовом блоке, схема РЗА и автотрансформатор в блоке ИВН. Достичь рабочего теплового режима лазерной трубки так и не вышло. Варьирование давления аргона, частоты повторения импульсов, напряжения результатов не давало – работа оставалось нестабильной. Пришлось отказаться от дальнейшей работы с аргоном в этой трубке.

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

image

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

image

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

Начало генерации.

image

image

Луч с одним зеркалом.

image

С двумя зеркалами.

image

Получив стабильное излучение, я решил поэкспериментировать с подбором давления неона, так как оно довольно сильно влияет на выходную мощность. Включил снова насос, со снижением давления мощность выхода стала монотонно увеличиваться. После откачки примерно до 10 мм рт. ст. впустил в трубку новую порцию чистого неона – мощность ещё прибавилась. Это говорило о том, что «отработанный» газ был достаточно грязный, чтобы снижать мощность. Довел давление до 200 мм рт. ст. и снова откачал и снова напустил новую порцию, «промыв» трубку. К этому моменту мощность с резонатором была неотличима от мощности собранного лазера с этим же активным элементом. Таким образом, операция с кодовым названием «восстание из мертвых» прошла успешно.

image

В излучении присутствуют 2 линии – зеленая и жёлтая.

image

Оставалось только узнать величину долговременного натекания трубки. Шланг откачки пережал зажимом и также пережал шланг напуска газа, сделав трубку снова «отпаянной». За 10 дней она натекла примерно на 20 мм рт. ст., что давало скорость натекания 2 мм рт.ст. в сутки. А это уже вполне согласуется с той величиной, на которую она натекла за 2 месяца лежания. Возможно, действительно, проблема в браке, который был допущен при производстве, а может, течет через неплотности моей вакуумной системы. После этого оставалось провести ещё один эксперимент. Согласно литературе лазеры на парах меди сохраняют работоспособность при давлении неона равном… 760 мм рт.ст., т.е. атмосферному. В таком случае лазерная трубка вообще перестает быть вакуумным прибором, а значит, натекание в такую трубку через малые неплотности будет пренебрежимо мало, да и неон, будучи тяжелым и плотным газом (по сравнению с воздухом) не так охотно будет улетучиваться. Но и тут произошел фейл – у источника питания не хватило напряжения для сквозного пробоя разрядного канала. Наблюдался только очень яркий и интенсивный, но коронный разряд на электродах. Скорее всего, утверждение относительно работы при атмосферном давлении справедливо только для малогабаритных АЭ серии «Кулон».

Использованная литература:

  1. Григорьянц А. Г., Казарян М. А., Лябин Н. А. Лазеры на парах меди: конструкция характеристики и применения. Физматлит, 2005
  2. Батенин В.М., Бохан П.А., Бучанов В.В., Евтушенко Г.С., Казарян М.А., Карпухин В.Т., Климовский И.И., Маликов М.М. Лазеры на самоограниченных переходах металлов. Физматлит, 2011
  3. Лябин Н. А. Создание современных промышленных лазеров и лазерных систем на парах меди для прецизионной обработки материалов. Диссертация на соискние ученой степени доктора технических наук, Москва, 2014

Let's block ads! (Why?)

[Из песочницы] Arduino таймер

[Из песочницы] Визуализации в Google Spreadsheets

С момента появления Excel стал самым популярным и универсальным инструментом автоматизации расчетов для непрограммистов и полупрограммистов (таких, как я). В свое время я много всякого писал на VBA, делал в студенчестве скрипты для оформления курсовых, даже запилил для диссертации мощный итерационный расчет распространения тепла в твердом топливе во время горения, который минут на 20 парализовывал комп. Сегодня в эпоху облаков и веб-решений эту нишу захватывают Google Sheets.

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


Работаю я в сфере управления и планирования строительством, а на стройке что-то сложнее икселя приживается очень плохо. Поэтому у гугл таблиц есть все шансы завоевать сердца (а может даже умы) строителей. Некоторые приемы, уже ставшие стандартом работы в электронных таблицах, гугл перенимает у предшественников, поэтому на первый взгляд разница с искселем незначительна. При этом некоторые возможности реализуются в новом виде и одной из таких удачных на мой взгляд реализаций стали формулы массива. Они были и в икселе, но посмотрев на них, хотелось сказать “слава богу, что я не знаю где они мне могут понадобиться”. В гугле же с ними прямо приятно работать и, думаю, они еще проявят свою полезность во многих задачах. Я же покажу, как их можно применять для работы со строительными визуализациями.

Демонстрировать все это в видеоформате проще, поэтому сделал небольшой эксплейнер:


А вот код скрипта, который позволяет увязать визуализацию с разными обозначениями со справочником параметров:
/**
 * Подставляет вместо закодированных значений соответствующие значения из справочника
 * @param {"A5:D20"} arr массив исходных закодированных значений
 * @param {"A21:D25"} sprav справочник (массив)
 * @param {"цена"} param искомый в справочнике параметр
 * @customfunction
 */
function ВИСП(arr, sprav, param) {
  if(typeof sprav=="object"&&sprav.length!=undefined) {
    if(typeof arr=="object"&&arr.length!=undefined) {
      for (var i = 0; i<arr.length; i++){
        for (var j= 0; j<arr[i].length; j++){
          if (arr[i][j] != ""){
            var r = sprav.map(function(value){return value[0]}).indexOf(arr[i][j]);
            var c = sprav[0].indexOf(param);
            if (r!=-1 && c!=-1) {arr[i][j] = sprav[r][c]}
          }
        }
      }
    }  
  }
  return  arr;
}


Возможно оптимизация кода не на высоте, я все таки не PROграммист, но он работает.

Конечно, те кто в теме, скажут что это все фигня, давно уже есть BIM. Да, есть. Но мы быстрей прикрутим таблицы к модели в SketchUp (тоже гугл, чтоб его), чем внедрим BIM. Потому что пока в BIM не работают все от производителей стройматериалов и проектировщиков до строителей и эксплуатации, от него больше трудозатрат, чем пользы. А в нашей стране это произойдет не скоро.

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

Let's block ads! (Why?)

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

На прошлой неделе бывший подрядчик Siemens, разработчик из Питтсбурга Дэвид Тинли (David Tinley) признан виновным в «умышленном повреждении защищённого компьютера» и компьютерном саботаже.

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

Такие действия Тинли напоминают «запланированное устаревание», которое умышленно планируют производители электроники и компьютеров, чтобы пользователи через несколько лет покупали новый гаджет вместо устаревшего или сломанного. Но если компаниям удаётся выйти сухими из воды, Тинли не сможет избежать наказания: ему грозит до десяти лет лишения свободы.
52-летний Дэвид Тинли признал себя виновным в том, что оставил «логические бомбы» в пользовательских электронных таблицах, которые Siemens использовала для управления заказами на электрогенерирующее оборудование и для медицинской диагностики. После определённой даты этот код создаёт сбои в программе, которые Тинли затем «исправлял» простым переносом даты появления сбоев на более поздний срок, сказали прокуроры.

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

Тинли был независимым подрядчиком подразделения Siemens в Монровилле, штат Пенсильвания, около 15-ти лет, с начала 2000-х годов. Он написал «автоматизированные электронные таблицы, которые рассчитывали рабочий процесс и смету затрат для заказов клиентов в подразделении производства электроэнергии Siemens».

Прокуратура утверждала, что Тинли вставил «логические бомбы» в защищённый паролем код, чтобы после определённой даты электронные таблицы «начали беспорядочно глючить, создавая сообщения об ошибках и изменяя размер экранных кнопок». Затем Siemens звонили своему проверенному подрядчику, чтобы исправить проблему. Он это делал, открыв свой код и просто передвинув дату, когда электронные таблицы снова перестанут работать.

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

Детали судебного разбирательства тоже довольно любопытны. Во-первых, логические бомбы не причинили компании особого ущерба, потому что программист быстро всё исправлял. Более того, на него даже не завели бы уголовного дела, потому что сумма ущерба не превысила положенного по законодательству порога в $5000. Однако прокуроры сказали, что порог ущерба в размере $5000 для классификации преступления как уголовного преступления был соблюден, потому что Siemens потратила около $42 тыс. на оплату сотрудников и адвокатов, которые расследовали, не повредили ли глюки компании и её бизнесу каким-либо образом (оказалось, что не повредили, но это не важно для оценки стоимости работ по аудиту). Ответчик обязан компенсировать эти расходы (вдобавок к потенциальному сроку тюремного заключения). Кроме того, суд постановил конфисковать два его ноутбука (вероятно, как «орудия преступления»).

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

Судья вынесет окончательный приговор Тинли 8 ноября. Ему грозит до 10 лет тюрьмы, штраф в размере 250 000 долларов или и то, и другое. Дело «США протии Тинли», № 2:19-cr-00156 рассматривается в Окружном суде США по Западному округу Пенсильвании.

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

В похожем процессе 2006 года системный администратор компании UBS PaineWebber Роджер Дуронио (Roger Duronio) получил восемь лет тюрьмы за размещение логической бомбы в корпоративную сеть работодателя и сделав ставку на бирже на падение его акций. Этот сотрудник неоднократно жаловался на плохие условия работы в компании, затем он уволился, но 4 марта 2002 года примерно на 1000 из 1500 корпоративных компьютеров сработала логическая бомба, которая начала удалять файлы с машин. Сам он тем временем купил пут-опционы на падение акций UBS после 4 марта на общую сумму $23 тыс. Вероятно, таким способом системный администратор хотел «компенсировать ущерб», который нанесла ему компания своими плохими условиями работы и недоплачивая ему положенные деньги. Сама фирма заявила об ущербе $3,1 млн, которые ответчик должен компенсировать.

В сентябре 2018 года житель Атланты Миттеш Дас (Mittesh Das) был приговорён к двум годам тюрьмы за размещение логической бомбы в бухгалтерское приложение Regional Level Application Software (RLAS) для выплаты жалования солдатам Армии США, что привело к задержкам выплаты зарплаты в 17 дней. Программист перед этим сам два года обслуживал эту базу данных по договору подряда. Логическая бомба сработала, когда заказчик заключил договор на обслуживание с другим подрядчиком. Армия заявила, что потратила $2,6 млн на расследование инцидента и аудит системы RLAS. В итоге разработчик был приговорён к двум годам тюрьмы и выплате $15 млн штрафов и компенсации издержек.

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

Let's block ads! (Why?)

Домашний ПК с 32 ГБ RAM за четыре месяца решил кубик Рубика 32768×32768×32768

У обычного кубика Рубика по девять цветных плиток с каждой стороны. Алгоритм решения включает всего семь действий. Мировой рекорд по сборке кубика человеком двумя руками составляет 3,47 секунды, среднее по пяти попыткам — 5,69 с, а робот делает это за 0,38 секунды (если кубик не разлетается на составные части, что частенько случалось из-за скорости).

Но у кубика не обязательно должны быть такие пропорции. Сам венгерский изобретатель Эрнё Рубик предложил несколько вариантов, а вообще ничто не мешает делать кубики произвольного размера. Такие головоломки гораздо сложнее решить, чем классическую.
Пользователь YouTube под ником ShellPuppy написал компьютерную программу, которая имитирует решение массивных кубиков Рубика. Самый большой кубик, который программе удалось «собрать», состоит из 32 768 плиток в высоту, ширину и глубину. Это в общей сложности 6.442.450.944 цветных квадратов. Если сделать такой кубик в реальности со стандартными размерами плиток, то он почти сравняется с дубайским небоскрёбом Бурдж-Халифа высотой 828 метров. Согласно описанию на YouTube, компьютеру понадобилось примерно 2700 часов для решения головоломки. На видео этот процесс показан в ускоренной съёмке.


ShellPuppy — американский инженер и разработчика программного обеспечения. Он говорит, что начал работу над проектом, когда посмотрел на YouTube видео с компьютером, который собирает кубик Рубика 55×55. Тогда он подумал, что он может попробовать что-то ещё более сложное. Кубик 55×55 он называет «крошечным»: «У компьютеров гораздо больше памяти и вычислительной мощности, — сказал ShellPuppy. — Поэтому я сел, быстро прикинул математику и посчитал, что можно сделать на 32 гигабайтах оперативной памяти. У меня вышло 65536×65536 (мне нравятся степени двойки)».

Разработчик начал тестировать программу, но быстро понял, что куб такого размера компьютер будет вычислять как минимум несколько лет. Причина в том числе в не очень эффективном алгоритме. Автор самокритично назвал его «абсурдно неэффективным алгоритма сортировки». Поэтому он решил остановиться на кубике в четыре раза меньшего размера, то есть 32768×32768. По его расчётам получалось, такой кубик программа должна собрать в восемь раз быстрее. ShellPuppy за выходные написал код для компьютерной симуляции кубика.

Но оставалась проблема: разработчик ничего не знал об алгоритме сборки этой симуляции: «Честно скажу, я понятия не имел, как решить кубик Рубика», — сказал он. — До сих пор я никогда не брал и не собирал настоящий кубик».

Ему пришлось делать то, что и каждый новичок, то есть смотреть учебники на YouTube и читать статьи о решении кубиков. Только его интересовали кубики необычного размера: «Мне пришлось отказаться от первых нескольких попыток, так как они не всегда приводили к удачной сборке или были слишком медленными», — сказал он. Написание кода для этой программы оказалось уже сложнее, заняв несколько вечеров и уикендов.

На видео показаны несколько первых неудачных подходов, от которых пришлось отказаться.


Очевидно, что решение виртуального кубика Рубика размером с массивный небоскрёб представляет некоторые уникальные проблемы. Согласно ShellPuppy, решение углов ничем не отличались от классического кубика 3×3×3, и поэтому их было легко решить с учётом центров. Самым сложным стало решение граней, то есть краёв массивного куба: «Решение граней было не так элегантно, — сказал автор. — Я написал алгоритм, который „работал”, но уверен, что он далеко не самый эффективный. Однако эффективность не имела значения для краёв, так как их размер незначителен по сравнению с центрами».

Хотя алгоритм не самый элегантный, но программа делает свою работу и в конце концов всё-таки решает кубик. ShellPuppy говорит, что она даже масштабируема, то есть при увеличении числа компьютеров можно распаралеллить вычисления. Но вот с решением кубиков большего размера уже возникнут проблемы, потому что одновременно с вычислениями усложняется и рендеринг: «Вы словно упираетесь в стену с точки зрения сложности. Даже если у вас компьютер в 10 или 100 раз быстрее, вы просто переместите эту стену немного дальше», — сказал он.

Можно добавить, что в последнее время исследователи начали подключать к решению кубика Рубика глубокое обучение и нейросети. Недавно в научном журнале Nature публиковалось описание системы DeepCubeA, которая по некоторым параметрам оказалась эффективнее, чем традиционные методы машинного обучения для сборки кубика Рубика, основанные на базах с паттернами (pattern databases, PDB).

Let's block ads! (Why?)

Текстурирование, или что нужно знать, чтобы стать Художником по поверхностям. Часть 5. Система материалов

В предыдущих частях туторов мы рассматривали то, как создаются текстуры. Точнее, то, как всё выглядит под капотом (как выразился Yoooriii в комментариях к 4-ой части). Расставили на свои места термины — пиксели и тексели. Разобрали немного развертку и сетку моделей, PBR и материалы. И, наконец, подвели черту под профессией «художник по текстурам». Казалось бы, можно остановиться и начать уже работу.

Часть 1. Пиксель здесь.
Часть 2. Маски и текстуры здесь.
Часть 3. PBR и Материалы здесь.
Часть 4. Модели, нормали и развертка здесь.
Часть 5. Система материалов — вы ее читаете.

Вводный блок.
В этой части у нас не будет практики, так как 5ая часть получилась достаточно большого объема. Всю информацию о том, как можно создавать материалы и настраивать их в Unreal Engine 4 можно найти в туторах Flakky и многих других. Наша задача сейчас разобрать теорию максимально подробно (И если какой-то информации будет недоставать, пожалуйста, сообщите мне об этом).
В 2017-ом году на Unreal Dev Day Montreal выступил технический художник Harrison Moore. Он рассказывал о том, какой подход для текстурирования он и его команда применяли для того, чтобы в игре Paragon были очень красивые материалы. Ниже приведена ссылка на его лекцию.

Дело в том, что мы создаем VR проект, где качество текстур имеет огромное значение. Например, создавая текстуры для крупных объектов (стены, пол, большие шкафы, коробки и прочее), мы наталкивались на то, что стандартный метод давал очень пикселизованные текстуры, а фаски, которые создавались при помощи жестких граней и карты нормалей (мы это разбирали в 4 части) при приближении объектов близко к глазам, смотрелись настолько пиксельно и убого, что нам приходилось увеличивать размер текстур, чтобы это исправить. В конечном счете, чтобы добиться хотя бы приближенного к желаемому результата, мы стали клепать 8к текстуры. Получалось, что на основные большие объекты создавать текстуры 8к очень накладно, но визуально это было удовлетворительно (максимум).
image

По началу все шло гладко. Текстуры клепались, качество нормальное, но собрав сцену из объектов с такими текстурами, мы поняли, что это не работает. Объем текстур был очень большим — для того, чтобы наш проект заработал у конечного пользователя, требовалось, чтобы видеокарта имела объем оперативной памяти не менее 3 гигабайт. Да и размер одной такой текстуры составлял 67 млн текселей. Даже не смотря на то, что это уже полностью просчитанные и запеченные текстуры, требовались не малые вычислительные способности видеокарты, чтобы прогнать все тексели и отобразить их на экране. А мы же понимаем, что для полноценной реализации PBR нам требуется не 1 текстура (и не 1 канал), а минимум 9 каналов.
В итоге, у нас получались сцены, в которых объем текстур имел огромные размеры, требовал дичайших расчетов и проваливал FPS с нужных нам 90 кадров до 45. Стало понятно, почему почти во всех играх используются только текстуры BaseColor, а другие практически не подключают. Например, игра Torn для VR:
image

Большая часть (я бы сказал, 90%) объектов сделана просто — материал состоял исключительно из BaseColor. Ни карт нормалей, ни металлика ни шероховатости. К сожалению, скриншоты игры, доступные в сети, не позволяют показать минус данного подхода, и наоборот, очень часто скриншоты показывают, что там есть все карты, и картинка очень красивая. Но не будем об этой игре.
По началу я проигнорировал лекцию, видео которой я вставил выше. Точнее, просмотрел и подумал, что вроде бы неплохой подход, однако менять pipeline создания объектов и текстур в нашей команде мы не стали, так как для этого потребуется достаточно большой кусок времени, чтобы освоить, чтобы внедрить, чтобы наработать навыки. И всё же, столкнувшись с проблемой качества материала, я решил пересмотреть под к текстурированию.
Мы начали разбирать, что же такое предлагал Harrison Moore.

Предпосылки к становлению понятия «художник поверхностей».


И так. Ребята из Epic Games разработали интересный подход для текстурирования (Точнее, рассказали о нем). Они взяли подход к созданию текстур в Substance Painter (или любой другой программе по текстурированию) и перенесли само запекание текстур из программы в движок напрямую (если быть точнее, то этот процесс можно назвать процедурной генерацией материалов). То есть, теперь расчеты для запекания текстур уже проводятся в самом движке, а текстуры не создаются, а компилируются заранее. Результат компиляции (шейдер) хранится в формате, который понимает движок, и, когда отображается модель с этим шейдером, то результат накладывается на модель.
Как это работает?
В движок загружают текстуры какой-либо фактуры (материала) размерами по 1к. То есть, стандартный набор — Base Color, ORM, Normal Map. Таких фактур загружают 10-20 штук. Например, 4 разновидности металла, 5 разновидностей кожи, несколько вариантов пластика, дерево и так далее. Все это объединяют в шейдерные функции, чтобы потом можно было легко подключать их. 1 фактура = 1 функция.
image

image

После этого создают маски для нужного нам объекта. Вот здесь Substance Painter снова становится необходим — с помощью него создаются маски на объект. То есть, нужно указать, в каких местах объекта какие фактуры должны отображаться, чтобы потом отрисовывать нужную фактуру в нужном месте на объекте:
image

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

Эти маски выгружаются в движок. Так же создают карту нормалей для каждого объекта отдельно, чтобы сгладить фаски, отобразить какие-то мелкие технические элементы с помощью нее и так же загружают в движок.
Далее создается новый шейдер (материал), в который добавляются созданные маски. Добавляются нужные шейдерные функции с нужными фактурами (например, ржавый металл, пластик и свежий металл) и далее прописывается код (практически ничего писать не нужно, все таки Epic Games все сделали все возможное, чтобы нам было удобно работать), в котором мы указываем, как смешивать правильно маски, какие фактуры отображать под какими масками, как отображать фактуру грязи и прочее-прочее.
После того, как все собрано, компилируется шейдер и выводится результат.
Ну, казалось бы, чего такого — ведь то же самое можно сделать в Painter и получить уже готовый результат. Однако это не так. И всему виной тайлинг.

Немного о тайлинге.
Тайлинг (Tiling) (дословно — плиточный, плитка, ) — Это повторение текстуры, как будто плитки, если она меньше размером, чем зона для текстурирования (UV). Это необходимо для того, чтобы заполнить пробелы, которые образуются в UV-пространстве, если текстура меньше размером. Видеокарта просто начинает ее дублировать столько раз, сколько нужно, чтобы закрыть брешь. Тайлинг работает интересным способом — видеокарта рассчитывает каждый тексель текстуры (например, размером 1к). И когда дело доходит до той части, которая продублирована — никаких расчетов уже не производится, так как они уже есть. Видеокарта просто копирует и вставляет данные. Копи-паст. И это практически ничего не стоит для производительности. Это настолько не требовательно к ресурсам, что не влияет ни на что, даже если вы сделаете тайлинг 10000*10000 повторений, (а это с нашим примером порядка 10 миллиардов текселей повторить, на минуточку о цифрах), ваш проект ни на секунду ни затормозит.

Продолжаем.
То есть, мы можем взять теперь фактуру. Показать в нужном месте на объекте и зайтайлить (продублировать) ее ровно столько, сколько нужно для достижения нужного качества. За счет тайлинга размер текселей очень сильно уменьшается, что увеличивает качество самой фактуры.
Минусом такого подхода является математика — теперь, чтобы отобразить текстуры на объекте, шейдеру необходимо просчитать различные операции по многу раз, чтобы отобразить конечный результат, и вместо стандартных 3-х текстур движку необходимо учитывать маски, смешивание нормалей, цветов и так далее.
На самом деле проигрыш в расчетах нивелируется:

  1. Вы можете и будете использовать фактурные функции повторно. Раз за разом на других объектах. То есть, расчеты будут суммарно те же, но количество самих текстурных карт будет меньше в разы. Вам уже не нужно для каждого объекта создавать новые текстуры, только определить зоны для фактур и использовать одни и те же фактуры.
  2. Вы можете создавать меньше размером маски — например, 128 на 128 пикселей. Что уменьшает расчеты в сотни раз.
  3. Вы можете тайлить текстуры сколько вам будет угодно, добиваясь результата, которого не получится добиться стандартным методом текстурирования.
  4. Добавляя другие расчеты и маски, вы можете играть с отдельными каналами, например, сделать тайлинг канала шероховатости меньше, чем карты цвета, тем самым нарушив визуальное повторение рисунка и создав ощущение уникальности всей поверхности.
  5. Вы можете накладывать текстурные функции таким образом, чтобы они смещались относительно координат объекта в мировом пространстве — таким образом можно поставить 2 одинаковых объекта с одинаковыми шейдерами, но они оба будут выглядеть уникально.

Стоит понимать, что этот подход не ко всем платформам. Например, мобильные игры уже сложно собирать таким образом из-за сложности в расчетах.
Самый простой пример минусов стандартного подхода к текстурированию и новой Системы Слоев Материалов (Material Layer System — так назвали данный подход ребята из Epic Games) — игра Final Fantasy 15. Для того, чтобы улучшить качество картинки, они выпустили пак с 8к текстурами. А что такое — 4к текстуры? Это 16 млн просчетов текселя на 1 канал. А если их 9 для стандарта PBR?
И вот тут мощь Системы Слоев Материалов начинает проступать максимально. Чтобы собрать с помощью фактур одежду на персонаже — достаточно использовать 3-4 фактуры (может больше). В сумме это будет меньше, чем стандартные текстуры высокого разрешения, производительность примерно на одном уровне, а качество можно контролировать с помощью тайлинга и выставлять намного выше.

Material Layer System.


Ребята из Epic Games пошли дальше и представили бета-версию «Системы Слоев Материалов» (Material Layer System), которая не создала шумихи и оказалась достаточно забагованной.
Пример ее работы можно посмотреть на этом видео:

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

Как мы избавились от карт нормалей.
Сначала работа с фактурами шла не совсем гладко — нужного эффекта с текстурами мы достигали, но все еще нас сильно тормозила карта нормалей, так как ее необходимо было генерировать для каждого объекта, чтобы создавать ощущение красивых фасок. Не смотря на качество фактур, создаваемых нами, при приближении к объекту камеры фаски оставляли желать лучшего даже при 8к текстурах (напомню, что мы разрабатывали проект под VR). Но 8к текстуры — это очень большой объем текселей. Настолько большой, что 2 полных комплекта текстур просаживали FPS до 45 кадров (для VR надо 90).
Тогда мы ознакомились с методом создания фасок, о котором я рассказывал кратко в 4-ой части. Создание фасок на моделях объектов позволило практически полностью избавиться от карт нормалей. Да, у нас увеличился полигонаж моделей, но не более 20-40%, при этом качество фасок взлетело до небес.
Такой подход позволил нам избавиться и от другой проблемы — швов на гранях. Создавая на модели фаски, более не требовалось резать модель по жестким граням. Жестких граней в принципе более не было на моделях, поэтому острова стали большими, они стали включать в себя большие пространства, и теперь, когда мы накладываем фактуры на модели — на моделях практически нет швов.
Это не значит, что теперь на всех объектах у нас нет отдельной карты нормалей. Просто большинство из стандартных объектов может обойтись одними фасками в моделях без дополнительной карты нормалей.
В конечном счете, постепенно уменьшая маски, увеличивая и усложняя шейдеры мы начали создавать сложные материалы, которые позволяют нам текстурировать очень красивые поверхности:
image

Выше пол состоит из 2х фактур — железные полоски — 32х32 пикселя и гексагоны — 32х32 пикселя. У материала очень сложная формула — очень большое количество операций для расчетов — порядка 295 инструкций. Для обычного материала такой шейдер потребовал бы большие вычислительные мощности, но мы используем всего 32х32 = 1024 текселя на канал. 9 каналов = 10к текселей, которые необходимо учесть при расчетах данного материала + маска 128х128. Очень большое количество операций нивелируется маленьким количеством текселей для обработки. В итоге, у нас получилась красивая картинка очень быстрым и легким шейдером.
За счет масок, грамотного управления тайлингом и каналами можно создавать очень сложные шейдеры, которые будут генерировать красивые материалы и при этом практически не кушать ресурсов.
Для примера — на текущий момент мы используем около 10-15 фактур на весь проект (плюс несколько уникальных полностью затекстуренных объектов по стандартному методу). Один и тот же металл есть практически на каждом объекте. Он видоизменяется в шейдерах — мы добавляем к материалу разные цвета, мы сдвигаем карты шероховатости фактур, накладываем по маске царапины, а их смещением управляют координаты объекта (если речь идет о статических объектах), что приводит к уникальным объектам со своими сколами, трещинами, грязью.
При увеличении разрешения экрана нам достаточно просто отрегулировать тайлинг, чтобы кол-во текселей совпадало с кол-вом пикселей экрана. При стандартном методе текстурирования придется перелопачивать все текстуры, поднимать старые проекты в Painter и пересохранять их. А еще нужно убедиться, что текстура не поедет. А потом это все необходимо будет реимпортировать в движок и убедиться, что там все будет нормально, что шейдеры будут достаточно быстро просчитывать текстуры большего объема, чем прежде.
Мыслить фактурами.
Когда я общался с 3D-художниками на тему фактур, мне не раз говорили, что большинство объектов невозможно собрать с помощью фактур, что для этого требуется отдельная текстура с уникальными рисунками и прочим составляющим. Например, вот эта беседка:
image

Сложность представления этого объекта в фактурном плане состоит в том, что у него есть уникальные моменты:
image

Паттерн ремня сверху ткани можно сделать отдельной фактурой и просто наложить поверх фактуры ткани. Или вшить ремень в фактуру ткани, и тогда у нас получится уникальная фактура ткани с ремнем:
image

При использовании такой фактуры пришивка ремней к ткани будет постоянно на одном и том же участке повторяться, но это не будет бросаться в глаза.
Мокрые пятна делаются маской и накладывается грязь или что-то еше. И это уже выглядит уникально.
Бахрома так же выделяется фактурой, причем ее размер будет очень маленьким, так как она повторяется. Отобразить ее на модели можно через маску.
Уникальный узор на металлическом крючке можно наложить либо декалью либо отдельным слоем карты нормали небольшого размера, который зайтайлить под положение развертки и проявить через маску.
Складки на рулоне ткани можно реализовать с помощью геометрии или наложить маски с затенениями. В текущем поколении железа добавление небольшого кол-ва вертексов не вызовет никакой нагрузки, а лодами всегда можно будет спрятать их при отдалении.
Деревянные объекты можно сделать фаской, и тем самым, убрать полностью из расчетов карту нормалей. И так далее. Самое главное здесь то, что всё это очень быстро поддается корректировке без сторонних программ и трат времени.
И самое важное, все эти фактуры можно использовать в любом другом шейдере, подкорректировав цвета и пятна.
Исключения.
Большая часть, я бы сказал, 95% всех объектов в игре покрываются этим методом. В целом, даже хендпейнтинг попадает под фактуры и может быть реализован через него. Однако не все объекты на данном технологическом этапе можно реализовать. Например, сложные персонажи, у которых есть особые элементы. И даже их, если хорошенько подумать, можно покрыть фактурами — важно их своевременно увидеть, обрезать и затайлить.
Мне предложили продемонстрировать диван (картинка ниже), как элемент, который нельзя затекстурить фактурно.
image

Однако, если внимательно присмотреться, то у дивана есть 3 фактуры (кожа сверху, обивка, дерево для ножек) и 2 сложности — это складки и швы.Складки можно имитировать 2-мя способами:
1. Дополнительные вертексы.
2. Дополнительная небольшая карта нормалей, которая будет эмитировать волны складок (более привлекательный метод).
Тоже касается и швов — их можно выделить маской и просветить фактуру для швов или, опять же, дополнительной картой нормали.
Все обрывы, все переходы можно имитировать фактурами и масками, создавая тот же результат, но с меньшим кол-вом текстур (нам достаточно использовать фактуры стандартной для нашего проекта ткани и просто изменять ее цвет в шейдере напрямую).
Тут можно задать вопрос — а что делать с выцветаниями вокруг подушек? Маски решают такие проблемы на ура =)
Далее мы можем использовать эти же фактуры для кресел. Для других диванов, для стульев с такой же тканью на сидушке. И все это мы можем многообразить, перемножив цвета фактур на нужные нам. И нам не потребуется более с нуля создавать текстуры — достаточно собрать маски и правильно наложить слои фактур. Таким образом, мы уменьшим объем загружаемых текстур, но сохраним качество и даже поднимем его. Однако, стоит отметить, что это наш пайплайн, и сбор материалов может отличаться от студии к студии, платформ и в целом проектов.

Художник по поверхностям.
И вот мы плавно подошли к художнику по поверхностям. Основная задача художника по поверхностям научиться видеть, что можно делать фактурами, что вертексами, а что — стандартным методом текстурирования. Понимать, какие маски использовать и где, чтобы добиваться нужного результата.
Так же нужно понимать, что не все можно сделать фасками — бывает так, что некоторые объекты должны иметь карту нормалей с хай-поли модели, чтобы передать все тонкости изгибов поверхностей. Например, сложные изгибы тканей одежды на персонаже, или тонкости деталей на оружии. Саму ткань, опять же, уже текстурировать с помощью фактур и масок.
Распознавание фактур, как мне кажется, достаточно сложная задача, потому что наш мозг нацелен на уникальные текстуры, так как просто привык с ними работать. Тем более, что это стандарт игровой индустрии, который является основой всего. А ведь, когда-то стандартом была простая текстура цвета без дополнительных параметров.
Важно научиться пользоваться Substance Designer — это та программа, которая позволит вам создавать собственные маски и фактуры очень высокого качества.
А еще ребята из Epic Games выложили замечательную статью "Jobs in Unreal Engine — Surface Artist", где рассматриваются требования к тому, чтобы стать полноценным художником по поверхностям. Очень рекомендую ознакомиться с ними, чтобы понимать, куда расти и к чему стремиться.

Вместо заключения:
Мое имя Денис Кузнецов, и я представляю компанию Qbercat Studio, мы так же разрабатываем игру Movies Tycoon (на данный момент об игре информацию мы не выкладываем, однако у нас есть группа в контакте, в которой мы планируем выпускать дневники разработчиков и промо-материалы. Поэтому не удивляйтесь, что группа пуста) и практически все наши материалы созданы исключительно фактурным методом. В нашей студии три 3D-художника и 1 художник по поверхностям. На 1-го художника по поверхностям в среднем хватает 3-5 3D-художников. Все зависит от сложности шейдеров, конечного результата, платформы и самого проекта.

Отдельное спасибо Snake из discord-чата "Unreal Engine — RuCommunity", с которым мы в жаркой полемике рождали выводы.
Спасибо Flakky за то, что внес правки по тексту.

Помните, если вы видите в статье какие-то неточности или неверную информацию — я всегда буду рад вашим замечаниям. Эти туторы созданы не для рекламы, а для того, чтобы все желающие могли максимально быстро включиться в работу, поняв саму суть текстурирования и его видов.
Спасибо вам за внимание =)

Let's block ads! (Why?)

ОС для контейнеров Fedora CoreOS продолжит развитие Fedora Atomic и Container Linux

На этой неделе состоялся анонс первой предварительной версии Fedora CoreOS — специальной редакции Linux-дистрибутива Fedora, предназначенной для запуска приложений в контейнерах. По факту новая система продолжила развитие двух других проектов: Fedora Atomic Host и CoreOS Container Linux.

Наработки компании CoreOS, появившейся в 2013 году и ставшей хорошо известной в среде DevOps-инженеров и других любителей Linux-контейнеров, перешли к Red Hat в результате поглощения, что случилось полтора года назад. В то же самое время у американского Linux-вендора уже не один год формировалось своё видение нового дивного контейнерного мира — и происходило это, в частности, в рамках Project Atomic (о результатах его деятельности мы писали, например, здесь).

Появление Fedora CoreOS подтвердило намерения Red Hat объединить лучшее из собственных и приобретённых наработок в виде одного дистрибутива, призванного стать стандартом для развёртывания и запуска приложений в контейнерах. Как сообщается в анонсе проекта, он «сочетает инструменты provisioning'а, модель автоматических обновлений и философию Container Linux [от CoreOS] и технологию пакетирования, поддержку [стандарта] OCI, а также безопасность от SELinux из Atomic Host».

Среди основных фич Fedora CoreOS на данный момент называются:

  • следование принципам неизменной инфраструктуры (immutable infrastructure) в виде базового образа ОС (generic OS image) и последующего использования Ignition для provisioning'а: конфигурация системы описывается в YAML-документе FCC (Fedora CoreOS Config) и передаётся в FCCT (Fedora CoreOS Config Transpiler) для валидации и преобразования в конфиг для Ignition; после запуска машины изменение её конфигурации возможно только путём модификации FCC-файла и повторного provisioning'а;
  • автоматические обновления: новые релизы ОС автоматически скачиваются и устанавливаются, выкатываясь постепенно во времени и не требуя вмешательства пользователей; сами релизы при этом распространяются в нескольких «потоках» (release streams): testing, stable, next, — каждый из которых получает обновления безопасности и исправление критических багов;
  • встроенный сервис телеметрии fedora-coreos-pinger, периодически собирающий информацию о машине (версию ОС, облачную платформу, тип сущности) — без каких-либо уникальных идентификаторов — и передающий её на серверы проекта Fedora (авторы обещают инструкцию, как отключить этот сервис).

Проект всё ещё находится в стадии разработки, и в первой его версии есть ряд ограничений, таких как единственный поток с релизами (testing), поддержка только x86_64, отключённая функция телеметрии, неполная документация. Также авторы сообщают, что ведутся активные дискуссии по тесной интеграции с дистрибутивами Kubernetes, а в частности — OKD(используется в основе другого продукта Red Hat — OpenShift).

Fedora CoreOS предназначен для использования в production, но это не относится к текущей предварительной версии. Ожидается, что систему объявят стабильной через полгода. Её предшественник в лице Fedora Atomic Host будет поддерживаться до конца жизни Fedora 29 (т.е. по конец ноября), и всем его пользователям рекомендуется мигрировать на Fedora CoreOS.

Образы для загрузки доступны здесь, а быстрая инструкция по запуску — здесь.

P.S.


Читайте также в нашем блоге:

Let's block ads! (Why?)

Отжим компании по-русски. Акции «Яндекса» рухнули после внесения законопроекта о национализации «значимых IT-ресурсов»

Всего за пять часов вчерашних торгов на NASDAQ акции «Яндекса» упали с $42,37 до $36,13, то есть примерно на 14,8% (см. график). Компания в моменте виртуально потеряла больше миллиарда долларов капитализации. Это падение полностью съело утренний рост котировок после публикации отличной квартальной отчётности, так что на закрытии торгов по итогам дня зафиксировано общее снижение на 2,37%. Можно предположить и дальнейшее снижение, если законопроект о «национализации значимых сайтов» всё-таки будет принят в Госдуме.

Законопроект № 763517-7 об ограничении доли иностранных инвесторов для «значимых сайтов» Рунета вчера в районе 17-00 внёс на рассмотрение Госдумы депутат Горелкин. Этот момент хорошо виден на графике.
Законопроект об ограничении в 20% для иностранного владения относится к ресурсам, «значимым для развития информационной инфраструктуры России».

Поправки в закон «Об информации, информационных технологиях и о защите информации» и статью 18 Федерального закона «О персональных данных» предполагают создание «реестра значимых ресурсов», куда внесут сайты, страницы сайтов, информационные системы или программы, которые дают их владельцу возможность собирать данные о пользователях на территории России.

Позже депутат Горелкин прокомментировал «Ведомостям», что ограничение направлено на IT-компании, работающие в России, прежде всего «Яндекс» и Mail.ru Group. Он отметил, что информационно значимыми, вероятно, будут признаны 3–5 сервисов, в их число могут попасть и операторы связи.

По информации издания The Bell, законопроект специально внесён в один из последних дней работы Госдумы, чтобы у властей было время провести с «Яндексом» переговоры о какой-либо реструктуризации, которая повысит госконтроль над компанией.

Депутат пояснил, что инициатива затронет стратегических игроков, которые обрабатывают огромное количество данных, включая персональные данные россиян. При этом это фактически иностранные компании с непрозрачной, по мнению депутата, структурой собственности. Как и в ситуации с официально зарегистрированными СМИ, владение иностранцев и иностранных компаний в случае принятия законопроекта будет ограничено 20% долей или акций. Но в отличие от СМИ работу в России такого ресурса с большей долей иностранцев всё же может разрешить специальная правительственная комиссия. В случае несоответствия таким ресурсам будет запрещено размещать рекламу в Рунете. А это основной бизнес «Яндекса», что ещё раз указывает на специальную задачу законопроекта, направленного конкретно на национализацию «Яндекса». Ниже приведена инфографика РБК: она наглядно объясняет схему, которую предлагает реализовать депутат Горелкин.

Представитель «Яндекса» заявил, что документ в текущем виде не должен быть принят и компания готова участвовать в его обсуждении. «В случае принятия законопроекта может быть разрушена уникальная экосистема интернет-бизнесов в России, где локальные игроки успешно конкурируют с глобальными компаниями. В результате пострадают конечные пользователи, подчеркнул он.

В свободном обращении на американской Nasdaq находится 85% акций «Яндекса» класса А (у каждой такой акции один голос). Крупнейший акционер поисковика — его основатель Аркадий Волож, у которого по состоянию на февраль 2019 г. было около 10% капитала компании и 48,4% голосов. Головная компания «Яндекса» — нидерландская Yandex N.V., акции компании торгуются на бирже NASDAQ. Аркадий Волож является гражданином России и Мальты.

В октябре 2018 года СМИ сообщили о том, что Сбербанк ведет переговоры о покупке не менее чем 30-процентной доли в капитале интернет-компании. Несмотря на то что глава Сбербанка Герман Греф и его первый заместитель Лев Хасис сразу опровергли эту информацию, акции интернет-компании упали на 17,81% на NASDAQ. По итогам двух дней торгов на бирже в Нью-Йорке «Яндекс» подешевел на $2,77 млрд по сравнению с 17 октября — по итогам торгов в пятницу капитализация группы составила $9,005 млрд. Как тогда рассказывали источники «Ведомостей», «Сбербанк пытался спасти «Яндекс» от прямого госконтроля». По словам собеседника издания, идею госконтроля над компанией высказывали силовики (им была непонятна структура владения «Яндексом») и чиновники администрации президента, которые хотели бы получить контроль над сервисами «Яндекс.Новости» и «Яндекс.Дзен», пишет РБК.

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

Переход «Яндекса» под госуправление практически неизбежно предполагает участие в сделке Аркадия Воложа. «Яндекс» по стандартной схеме эмитировал акции класса А (1 голос) и класса B (10 голосов). До начала 2018 года крупнейшему акционеру принадлежало 10,35% капитала и 49,2% голосов, но в течение года Аркадий начал постепенно продавать акции и его доля снизилась до 9,8%.


Аркадий Волож

Другие крупнейшие акционеры — один из первых сотрудников фирмы Владимир Иванов (3,83% капитала, 6,23% голосов) и американская компания WMC (5,12% капитала, 2,46% голосов).

До настоящего момента Сбербанку принадлежала только «золотая акция», которая даёт право накладывать вето на продажу более 25% акций «Яндекса». Сбербанк приобрёл «золотую акцию» в 2009 году за 1 евро. С тех пор сотрудничество партнёров развивалось: сначала было запущено совместное предприятие «Яндекс.Деньги», затем Герман Греф вошёл в совет директоров «Яндекса», а в прошлом году партнёры запустили на основе «Яндекс.Маркета» интернет-магазин «Беру».

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

«Для нас, профессионалов, давно очевидно, что киберпространство должно находиться под контролем компетентных органов», — сказал тогда замглавы ФСБ России Сергей Смирнов.

Let's block ads! (Why?)

Визуализация сна первого года ребенка на узорах одеяла

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

Сбор и обработка данных.

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

Далее, данные из приложения BabyConnect экспортировались в файлы формата CSV, которые отфильтровывались и преобразовывались в JSON (с использованием Google Apps Script и Python).

Таким образом, Ли получил нужные компоненты данных для визуализации.

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

Затем он создал свой швейно-браузерный инструмент в HTML/Javascript, который преобразовывал данные в цвета и компоновку стежков, а также позволял Ли работать с данными с любого устройства, где бы он не находился.

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

Ссылка на инструмент Ли.

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

Создание сонного одеяла.

После получения и обработки данных о периодах бодрствования и сна своего сына, Ли осталось их визуализировать с помощью двух цветов (синий — сон\светлый — активность) и трехсот часов ручного вязания.

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

Параметры одеялка:

— 365 строк (+ внешний защитный контур), каждая строка представляет один день из жизни ребенка;

— 185000 стежков (включая стежки на внешний контур), каждый стежок внутри контура представляет собой 6 минут времени, проведенного сыном Ли бодрствующим или спящим;

— размер одеялка 42x45 дюймов (107х114 см);

— потрачено времени на вязание около 300 часов (в режиме реального времени 104 дня).

Как читать одеялко.

Каждый ряд на одеялке представляет собой один день жизни сына Ли.

Самый верхний ряд — когда родился ребенок, а нижний ряд — первый день рождения сына Ли.

Каждый стежок представляет шесть минут времени, проведенного ребенком бодрствующим (серого цвета) или спящим (синего цвета).

Одеяло «читается» слева направо, причем крайняя левая строчка начинается в 12:00 AM, а крайняя правая строчка заканчивается в 11:54 PM.

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

Ли рассматривал возможность корректировки этих временных меток, но оставил их как часть истории сына.

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

Let's block ads! (Why?)

C++, FIX, Oracle и PL/SQL: что нужно знать IT-специалисту для получения работы в сфере финансов + реальные вакансии

image

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

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

Бонус: ссылки на реальные вакансии!

Распространенные языки программирования


Начнем с аспектов, связанных непосредственно с продуктами для биржевой торговли. Большая часть инфраструктуры бирж и брокерских компаний создается с помощью языка C++. Сам создатель языка Бьерн Страуструп (Bjarne Stroustrup) до сих пор работает в инвестбанке Morgan Stanley в должности директора по технологиям.

Созданный им инструмент применяется для создания самого разного софта – от библиотек для расчета ценовых моделей производных инструментов до модулей обработки потоков данных

Помимо C++, широко распространены C# и Java — с их помощью часто реализуют определенные части торговых приложений или фронтенд-сервисы финансовых компаний (например, GUI торговых терминалов).

Для описания торговых стратегий и прототипирования моделей применяют в том числе и скриптовые языки, вроде Python, MATLAB и R. Пользуются популярностью и скриптовые языки, которые могут быть даже встроены в торговые терминалы — как например язык TradeScript, с помощью которого торговых роботов можно писать прямо внутри терминала SMARTx.

Простая стратегия на TradeScript, записанная в окне торгового терминала

Разработчики со знанием этих языков всегда найдут себе интересные проекты в сфере финансов.

Помимо этого, согласно данным опросов, есть спрос на разработчиков Python — этот язык незаменим при создании аналитических инструментов и квантовых моделей. Помимо этого можно встретить проекты, в которых применяются технологии обработки данных вроде Hadoop, Cassandra и Scala.

Протоколы передачи данных


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

Мы писали про те из них, что используются на российском рынке, цикл статей (один, два, три, четыре). Важно сказать, что часть из этих протоколов – международные стандарты, но есть и проприетарные протоколы, которые используют конкретные биржи и компании. Поэтому если вы планируете в будущем переехать на работу за границу, то там скорее всего придется знакомиться и с новыми протоколами – вроде ITCH и OUCH c американской Nasdaq.

Не только торговые приложения


В каждой компании свои требования, однако можно сформулировать и некоторые тренды в этом направлении. Специалистам по работе с инфраструктурой при переходе в сферу финансов не придется серьезно перестраиваться. Например, разработчикам систем бэк-офиса нужно уметь работать с популярными СУБД – на российском рынке популярна Oracle и, соответственно, язык PL/SQL, также часто используется MS-SQL.

Пример вакансии:


Разработчик Back Office

Обязанности:


  • Разработка и поддержка интеграционных решений для бэкофисной системы;
  • Разработка отчетов для бэкофиса;
  • Участие в иных интеграционных проектах ИТ департамента;
  • Миграция приложений в среду APEX.

Требования:


  • Высшее техническое образование;
  • Опыт работы не менее 5 лет;
  • Хорошее знание PL/SQL;
  • Опыт оптимизации запросов;
  • Навыки администрирования Oracle;
  • Опыт разработки приложений с использованием Oracle SQL, PL/SQL, Oracle APEX
  • Опыт разработки Web Services;
  • Знание и опыт разработки в MS-SQL будет плюсом;
  • Английский достаточный для чтения документации, разговорный будет плюсом;
  • Знание предметной области торговли и учета ценных бумаг будет большим плюсом.

Присылайте письма и резюме на адрес job@iticapital.ru.

Отдельное направление – разработка баз данных, которые активно применяются в финансах. Здесь плюсом будет знание специализированных платформ, например backQORT. Обязательно и знание SQL, T-SQL и умение работать с MS SQL Server. Поскольку на этом продукте «завязано» многое, то обычно плюсом является и знание MS SQL Server Reporting Service, MS SQL Server Integration Services.

Пример вакансии:


Разработчик Oracle (PL/SQL, Oracle APEX)

Обязанности:


  • Разработка и поддержка функционала бэкофисной системы организации;
  • Разработка отчетов для бэкофиса;
  • Участие в интеграционных проектах ИТ департамента;
  • Миграция приложений в среду APEX;

Требования:


  • Высшее техническое образование;
  • Опыт работы не менее 5 лет;
  • Опыт разработки приложений с использованием PL/SQL и хорошее знание PL/SQL;
  • Опыт оптимизации запросов;
  • Навыки администрирования Oracle;
  • Навыки разработки в Oracle APEX;
  • Английский достаточный для чтения документации, разговорный будет плюсом;
  • Знание предметной области торговли и учета ценных бумаг будет большим плюсом;

Присылайте письма и резюме на адрес job@iticapital.ru.

Отдельный и довольно большой пласт проектов — разработка мобильных приложений для онлайн-трейдинга. В ITI Capital есть собственные мобильные приложения — ранее мы рассказывали об эволюции интерфейсов этих терминалов с начала двухтысячных годов до наших дней.

Над какими проектами можно поработать


Проще всего понять, с какими проектами можно столкнуться в сфере финансов, рассмотрев реальные примеры. Например, мы в ITI Capital разрабатываем собственную торговую систему MATRIX, терминал SMARTx – отдельное направление работы связано с оптимизацией его производительности, – развиваем API к нашей инфраструктуре под названием SMARTcom.

image

Скриншот документации по API SMARTcom

Заключение


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

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

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

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

Бонус: еще IT-вакансии от ITI Capital (только для аудитории Хабра)

Head of Service Desk (руководитель отдела технической поддержки)

Обязанности:


  • Организация работа 1 и 2 й линии глобального HelpDesk IT (Лондон и Москва);
  • Внедрение системы Service Desk;
  • Построение, контроль и автоматизация ключевых ИТ процессов с применением мировых практик ITIL и MoF;
  • Руководство отделом Service Desk
  • Разработка KPI в рамках сервисной модели
  • Разработка SLA в рамках сервисной модели
  • Взаимозаменяемость с IT manager Лондонского офиса по поддержке сотрудников офисов в Великобритании

Требования:


  • Высшее техническое образование;
  • Опыт работы не менее 10 лет;
  • Свободное владение английским языком;
  • Опыт руководства отделом технической поддержки;
  • Опыт работы в международной инвестиционной компании;
  • Опыт в управлении проектами;
  • Опыт проведения IT треннингов для руководства компании
  • Опыт организации IT поддержки во время разного рода мероприятий организуемых компанией ( например конференции для инвесторов, собрание акционеров и так далее).
  • Опыт подмены регионального IT менеджера в англоязычном офисе
  • Знание ITIL
  • Знание Microsoft Windows
  • Знание MacOS
  • Опыт внедрения систем Service Desk
  • Опыт внедрения систем управления IT ресурсами
  • Опыт внедрения и поддержки систем корпоротивного портала и систем электронных заявок.


IT Security Officer
  • Review and development of security framework, information security policies, processes/procedures and guidelines on an ongoing basis.
  • Administer compliance with these policies/procedures through ongoing security reviews and audits, not limited to log analysis and security assessment of IT systems
  • Review and approve PAM (Privilege Access Management) requests
  • Develop strategies to respond to and recover from security breaches
  • Ensure IT and security compliance with local regulatory requirements and laws
  • Identify IT security risks including IT business application and infrastructure projects
  • Conduct security assessments for business application and infrastructure projects
  • Undertake new security projects to improve the security controls, efficiency and ease of use
  • Assist in Conducting periodic network scans, penetration testing, simulating attacks on systems to find exploitable weaknesses
  • Investigate security breaches
  • Support IT audits at global and branch level.
  • Be the point of contact to assist and advise customers for IT security-related matters

Key Competencies & Qualifications


  • Ideal candidate profile would be Bachelor's degree in information technology / Computer Engineering / Computer Science or related discipline
  • In depth knowledge of Network firewalls, VPN & Security products
  • In depth knowledge in anti-virus software, intrusion detection, firewalls and content filtering
  • Knowledge of risk assessment tools, technologies and methods
  • Experience of vulnerability and penetration testing
  • Professional Certifications: CISSP/CISM/CISA/MCSP/CCSK/CCSP is preferred
  • Strong analytical and critical thinking skills and meticulous attitude.
  • Able to work independently or in a team with minimal supervision
  • Extensive experience in working collaboratively across global teams and to lead others through problem solving challenges.
  • Strong communication skills, both verbal and written are essential.
  • Previous working experience with financial organization in a similar capacity is desirable


Присылайте письма с рассказом о себе на job@iticapital.ru. Спасибо за внимание!

Let's block ads! (Why?)