Типы конвейеров в WebGL — шейдеры/1

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

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

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

- Установить все три матрицы из прошлого поста - model, view & projection.
- Включить текстурирование, привязать текстуру стула.
- Отправить данные о вершинах на видяху.
- Привязать эти данные в отрисовку.
- Настроить светильники.
- Вызвать отрисовку.
- Отключить светильники, отвязать данные вершин, отключить текстурирование.

И вот эта последовательность действий у нас выполняется каждый кадр для каждой модели. Казалось бы, все логично, но фиксированный конвейер накладывает свои ограничения:
💣 1. Мы ограничены в светильниках, максимум — 8
🔮 2. Мы не можем влиять на отрисовку, все растрирование лежит на зашитых алгоритмах
🧿 3. Сложно сделать красиво, в основном приходится прибегать к хакам

И в какой-то момент ребята подумали, и решили: а почему бы нам не дать разработчикам возможность настраивать рендер целиком? Так появились шейдеры (ждите, ща второй пост).
#rdclr_frontend #WebGL

Типы конвейеров в WebGL — шейдеры/2

Если коротко, то шейдер — это маленькая программка на C-подобном языке, которая сначала выполняется для каждой вершины, а потом для каждого пикселя модели на экране, и определяет какой цвет должен быть в этом пикселе.
Благодаря шейдерам нам становится доступен огромнейший пласт эффектов, ведь теперь мы не ограничены растрированием со стороны OpenGL.

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

💛 Вся матричная математика уезжает на видеокарту — не просто так у нее есть compute-ядра, которые считают перемножения матриц в сотни раз быстрее ЦП, тут и выигрыш.
💙 Освещение целиком и полностью ложится на программиста, так как на пиксели, которые выводит шейдер, не распространяется фиксированный конвейер.
💜 Наложение текстуры тоже теперь должно считаться на видяхе, делается очень просто, но мы можем полностью контролировать какой пиксель с текстуры брать для текущего пикселя.
🤎 Мы можем передавать в шейдеры какие угодно данные: как общие, например текущий цвет освещения, так и повершинные, например текстурная координата этой вершины.
❤️ Вершинный и фрагментный (попиксельный) шейдеры могут обмениваться информацией для удобства рендера.

Но лучше всего будет объяснить это наглядно, чем мы и займемся в следующем посте. 👀
#rdclr_frontend #WebGL

Разбираем тени / 1 (простой пример работы шейдеров)

Из-за того, что Blitz3D, с которого я начинал знакомство с графикой, не сильно был способен реализовать какие-либо графические эффекты (а связано это было с тем, что он был довольно старым и использовал под капотом Direct3D 7), меня всегда впечатляли приемы, которые использовали «взрослые» игры, например — тени. 👣

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

На самом деле, чтобы представить и посчитать тени, мы должны подумать немного нестандартно, и представить: «а что бы мы видели, если бы именно мы были солнцем?» Звучит странно, но именно такой подход является ключом к реализации нашего эффекта. Чтобы полностью понять принцип, мы откажемся от наших мебельных условностей и соберем абстрактную сцену, как на картинке. —>

#rdclr_frontend #WebGL

Разбираем тени / 2 (простой пример работы шейдеров)

☀️ За первый проход с камерой нужно поступить немного по-другому: нам нужно поставить ее не туда, где мы хотим, чтобы она была, а именно туда, откуда «светит» солнце.

Мало того, что мы по-особенному ставим камеру, так еще и рисуем не прямо на экран, а в отдельный буфер, который на самом деле является обычной текстурой. Плюсом ко всему, нам не нужен цвет или освещение, нам нужно просто понять, насколько отрисованный пиксель находится далеко от «солнца» — поэтому нам хватит текстуры только с красным каналом, куда мы и пишем расстояние от камеры до пикселя. Если все сделано правильно, мы получим карту теней, или shadow map.

🌪Второй проход — это как раз стандартная отрисовка нашей сцены, но с небольшой оговоркой.

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

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

#rdclr_frontend #WebGL

Про стадии рендера на почитать

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

#rdclr_frontend #WebGL #read

А вот все то же самое, только уже в виде видоса, с разделением по дроуколлам. 🛴

#rdclr_frontend #WebGL #read

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

🦚 На этой неделе мы с вами поговорим о дизайн-системах для фронтенда, обсудим Component Driven Development и заглянем в Storybook.

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

🕵🏻 Перейду сразу к примеру. (Все имена и персонажи выдуманы, любое сходство считать совпадением)

Представим, что разработчик Серёжа пишет приложение с нуля. Все кажется понятным и простым. Но со временем кодовая база разрастается, заказчик вносит правки, на которые Серёжа не рассчитывал, дизайнер переделал пару макетов, а дедлайн все ближе. Что происходит? «Быстрые» правки и костыли превращаются в снежный ком, который растет вместе с проектом. Проблема? Проблема.

🧑🏻‍🌾 Второй пример. Разработчик Ваня попал в проект, который писал Серёжа. Ваня долго вникает в исходники, пытается что-то изменить в подходе, но это трудно: система негибкая и зависимая. В результате Ваня вынужден подстраиваться под проект, чтобы ничего не сломалось. Работа идет медленнее, трудо- и времязатраты увеличиваются, количество багов растет. Проблема? Проблема.

Думаю, оба примера знакомы многим. Что делать?

🍅 1. Если заказчик дает добро, финансы и время, можно переписать проект. Но это очень редкий случай.
🍒 2. Можно нанять больше разработчиков, чтобы быстрее выполнить задачи. Но это дорого и неэффективно в долгосрочной перспективе.
🥝 3. Можно начать внедрять компонентный подход (CDD) и собирать дизайн-систему для UI — медленно, но верно.

🚀 Самый лучший вариант — использовать CDD с самого начала и стартануть проект с дизайн-системы.

Дальше расскажу, что дает Component Driven Development и как его использовать. Не переключайтесь.

📌 Итак, Component Driven Development

CDD в разработке интерфейсов — подход, в котором вы сначала создаете систему компонентов, а потом собираете из них UI, как конструктор Lego.

Компонент — независимая строительная единица интерфейса. Сам процесс разработки идет «снизу вверх»: от базовых элементов (компонентов) — к блокам (композиции из компонентов), а затем к страницам, из которых собирается проект.

Какие преимущества дает CDD?

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

✏️Простое тестирование.
Тестировать код на уровне компонента гораздо проще и эффективнее.

✏️Скорость разработки в долгосрочной перспективе.
Да, на начальном этапе разработка займет больше времени, в отличие, например, от Page-based development. Но если проект большой или его нужно масштабировать, это получится сделать гораздо быстрее и безопаснее за счет переиспользования компонентов.

✏️ Простота обучения команды.
Если к работе подключается новый разработчик, он быстрее разберется в коде и вольется в проект.

✏️Удобный рефакторинг.
Внося изменения в одни компоненты, вы не сломаете другие, потому что они изолированы.

В результате вы получаете собранный UI kit с чистым, читабельным кодом. Круто, но это все еще не дотягивает до конструктора Lego. Чего не хватает?

🍹Хороший UI — это результат плотной работы дизайнеров и разработчиков. Чтобы спроектировать такой интерфейс, нам нужно создать мост, который объединит усилия команд дизайна и разработки в единое целое. Этот мост — дизайн-система.

О ней я расскажу завтра. А вы пока подумайте, как начать разработку не с хедера или футера)
#rdclr_frontend #product

Дизайн-система для frontend-разработчика
Как будто что-то на дизайнерском. Но нет.

Дизайн-система — это набор компонентов, правил и паттернов проектирования UI.
Это результат совместной работы дизайнеров и разработчиков, единый источник правды в процессе разработки проекта.

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

Что должно быть в дизайн-системе:
🌔 набор стилевых правил - цветовая палитра, шрифты, типографика;
🌓 набор компонентов и блоков интерфейса;
🌒 документация — для каждого элемента есть описание интерфейса, свойств и состояний;
🌑 иерархия — компоненты разделены по уровням.

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

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

🌪 И еще один момент: дизайн-система — не конечный результат, а живой организм. Она растет и развивается вместе с проектом, поэтому у вас всегда будут задачи по ее поддержке.

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

#rdclr_frontend #product

Storybook
(ссылка в конце)

Мы выяснили, что дизайн-система — это часть инфраструктуры проекта, как дизайн-макеты и кодовая база. А значит, было бы неплохо иметь инструмент, который позволяет удобно c ней взаимодействовать: разрабатывать, хранить, документировать и пользоваться.

⚙️ Знакомьтесь, это Storybook. Он позволяет делать все то, что я перечислила выше. Его используют Airbnb, Microsoft, Audi, JetBrains, Atlassian и еще много-много компаний. Он дружит с React, Vue, Angular, Svelte и даже Vanilla JS. Подключить его в проект очень просто, а пользоваться реально удобно.

Для каждого компонента, блока или целой страницы создается история — файл с расширением .stories.js (ts, mdx), который и отвечает за отображение вашего элемента. Storybook собирает все эти файлы и формирует библиотеку компонентов. Он разворачивает в браузере интерактивный интерфейс, где можно посмотреть каждый элемент библиотеки изолированно: как он выглядит, как работает, какие у него состояния и пропсы. И да, со всем этим можно взаимодействовать.

⚗️ Я не буду описывать, как подключить Storybook, потому что у него отличная дока и много понятных демок — они расскажут гораздо лучше. Если коротко: скачали npm пакет, запустили из консоли — все. Дальше все зависит от того, насколько хорошо вы опишете компонент. Придерживайтесь правила: одна история — один компонент со всеми его состояниями.

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

Я думаю, вы уже поняли, что Storybook — крутая штука. Так что я предлагаю не медлить, а пойти и установить! Потыкайте и посмотрите, как он работает: не оторваться! Вот вам ссылка https://storybook.js.org/ и увлекательное занятие на выходные. 😜

#rdclr_frontend #product

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

Для компутерщиков про компутерщиков, так сказать. Так что, если не знали, что посмотреть в выходные — теперь знаете. «SAO» мы сюда включать не стали!

— «BPS» или «Battle Programmer Shirase» — анимешка старая и больше для тех, кто с компьютером на «вы», но дух программирования передан неплохо.

— «Калигула» — действие происходит в месте под названием Мёбиус, где вы будете свободны от ужасов реальности, а любое желание будет исполнено. Управляет пространством виртуальный идол Мю, каким-то образом обретший сознание сознание. Она поет и заманивает людей в цифровой рай. Оттуда — нет выхода в реальность, там — нет понятия возраста и пола, ведь все равны.

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

— «Нет игры — нет жизни» — История фокусируется на Соре и Сиро, брате и сестре, репутация которых как безупречных NEET, хикикомори и игроманов породила легенды по всему интернету. Вся их жизнь — очередная «отстойная игра».

Дополняйте список чем-нибудь, что считаете качественным.

Всем привет!
👋

Меня зовут Настя, я middle QA в компании Red Collar, и на этой неделе мы с вами поговорим о тестировании.

📌 Эвристики и мнемоники в тестировании: что это и как применять — первая тема

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

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

SFDPOT (Structures, Functions, Data, Platforms, Operations, Time):
✌🏻 Structure — структура приложения, проверка составляющих его частей. На данном этапе разрабатываются тестовые идеи и сценарии, связанные со структурой приложения.
🖖🏻 Function — функциональность приложения, проверка того, что приложение делает. На этом этапе разрабатывается функциональное тестирование программного продукта.
🤜🏻 Data — работа с данными; проверка того, как приложение работает с данными. Тестировщики должны узнать, с какими данными работает система, и разработать тесты, проверяющие, как система получает, обрабатывает и выдает различные виды данных.
🤘🏻 Platform — платформа; проверка того, как приложение взаимодействует с платформой, на которой запущено. Тестировщики должны определить, на каких платформах выполнять ручное и автоматизированное тестирование.
👌🏻 Operations — использование, проверка сценариев использования приложения. В этом пункте тестировщики должны выяснить, кто конечные пользователи тестируемого программного продукта, для каких задач пользователи собираются его использовать.
🤏🏻 Time — время, проверка того, как приложение ведет себя в зависимости от времени.

Самая известная мнемоника для тестирования мобильных приложений — I SLICED UP FUN.
🕴🏻 Inputs — входные данные (вводимые с клавиатуры или набираемые пальцем).
👨🏼‍🦽 Store — Хранилище. Android Market, например.
🧍🏾‍♂️ Location — Расположение (ошибки гео-координат, движение, быстрая остановка).
🧑🏻‍🦯 Interactions/Interruptions — взаимодействие / прерывания. Сворачивание приложение, когда играет музыка, например.
🏃🏻 Communications — входящий звонок, смс, уведомление.
👬 Ergonomics — мелкие детали напрягают глаза, ищите такие проблемы.
🧍🏿‍♀️ Data — Данные. Все, что приложение обрабатывает.
🕺 Usability — удобство использования.
🧑🏽‍🦼 Platform — для каких платформ выпущено ПО, где будет работать.
🧎🏻‍♀️ Function — Функционал.
👯‍♀️ User Scenarioes — пользовательские сценарии.
🤳🏻 Network — сеть.

RCRCRC — эвристика, применяемая для регрессионного тестирования.
👕 Recent — какие новые функции были добавлены в текущей итерации, что было изменено из уже существующего функционала.
🩱 Core — основные сценарии. Что должно всегда работать.
🥼 Risk — какой функционал имеет максимальные риски — его и проверяем.
👘 Configuration — на каких окружениях и в каких конфигурация должно работать.
👞 Repaired — какой функционал мы чинили в релизе. Ретест багов, как минимум самых важных.
🧣 Chronic — регрессия областей с хроническими болезнями (где чаще всего находились баги ранее).

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

#rdclr_QA

📎 В первой статье (VPN) вы прочитаете более подробно о преимуществах и недостатках тестовых эвристик, об «оракуле» — дополнительном эвристическом механизме.
Во второй — расшифровку самых известных мнемоник и эвристик и их описание.

Как писать хорошие тест-кейсы?

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

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

2️⃣ Один тест-кейс — одни тестовые данные
Тестовые данные — данные, которые понадобятся тебе для тестирования. Например, ты проверяешь, что в поле можно ввести текст от 2 до 10 символов. Символы, которые ты вводишь в поле для проверки, — тестовые данные. В одном тест-кейсе используй одни тестовые данные. Например, если нужно протестировать поле с коротким и длинным именем, составь два разных тест-кейса.

3️⃣ Уникальный ID
ID тест-кейса не должен повторять другие. Если будет два одинаковых, команда запутается. Иногда ID для тест-кейсов задаёт система, в которой работает тестировщик. Если такого нет, следует уточнить у коллег какая система учет принята в команде.

4️⃣ Уникальный и полный заголовок
Хороший заголовок не повторяет заголовки других тест-кейсов, чтобы не запутаться. Он конкретный и отвечает на вопрос: «Что я проверяю?» или «Что? Где? Когда?».

5️⃣ Лаконичные и чёткие шаги
Когда описываешь шаги: не расписывай их чересчур подробно: включай в них только необходимую информацию: следи, чтобы каждый шаг отвечал на вопрос «Что нужно сделать?».

6️⃣ Если для проверки нужны особые настройки, укажи предусловие
Предусловие — всё, что нужно сделать до того, как приступать к основным шагам тест-кейса. Например, зайти в приложение под определённым логином или включить какие-то настройки.

7️⃣ Если после проверки нужно дополнительно проверить изменившиеся состояние, укажи постусловие
Постусловие — всё, что нужно сделать после того, как были выполнены основные шаги тест-кейса или вернуть систему в исходное состояние (выйти из профиля пользователя, удалить сохраненные данные).

8️⃣ Словарный запас
Избегай использование в тест-кейсе слов:
человек —> пользователь
есть —> находится, отображается
посмотреть —> проверить
как на макете —> согласно макету
Замени их на предложенные (—>)

И самое главное — соблюдай правила орфографии! 🌺

#rdclr_QA

Введение в тест-анализ #1: декомпозиция, визуализация, поиск серых зон

🍼 Тест-анализ (test analysis) — один из этапов тестирования, направленный на изучение требований и макетов. Когда будешь изучать, постарайся ответить на вопрос: что именно предстоит тестировать? Так ты составишь список объектов тестирования.

Объекты тестирования (test objects) — части приложения, которые нужно проверить. Например, компания сделала почтовый клиент — приложение, в котором можно обмениваться электронными письмами. В последнем обновлении разработчики добавили фичу: теперь приложение определяет спам и сохраняет его в отдельной папке.

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

🌽 1. Декомпозиция
Декомпозиция — разделение целого на части. На этом этапе тебе предстоит разбить крупные объекты тестирования на более мелкие. Так с ними удобнее работать. Например, функциональность работы со спамом можно разбить на два объекта: определение спама и сохранение в отдельной папке

🍫 2. Визуализация
Когда декомпозируешь требования, попробуй их визуализировать. Визуализация — создание наглядной схемы всех объектов тестирования. Так проще воспринимать и структурировать информацию. Если поймёшь, что на схеме чего-то не хватает, уточни требования. Визуализировать можно с помощью mind-карт и блок-схем.

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

Следом я расскажу о проблемах с поиском серых зон.
#rdclr_QA