tynrare's blog

Я не буду затрагивать детали растеризации, на эту тему много всего написано и очень понятно разрисовано. Меня волнует работа с глубиной и методами наложения. Это не учебный материал, а попытка структурировать собственное изучение по теме. Какая-то типовая инфографика по запросу opengl pipeline В самом начале у нас есть 6 точек, соединенных между собой в треугольники Они соединяются между собой и образуют квадрат - это плоскость, на которой будет рисоваться текстура После этого все для всех плоскостей (На самом деле точек, образующих эти плоскости), считается положение в пространстве - fragment shader После этого наступает самое интересное - нужно решить кто перекрывает кого

Вдруг посреди ночи меня посвятила светлая мысль (Две, вообще-то). Одна из них о концепции source design . Теперь я хочу оформить репозиторий темплейта как полноценный продукт - добавить описания, пояснения, картинки, языки. ./maintenance/ В первую очередь начинаю с папки maintenance, котороя должна содержать в себе доки, темплейт генераторы и всякое подобное. В ней папку docs и файлы с readme для разных языков, я конечно же добавляю repo-readme/ru.md. Попробовал оформить в hand-drawn стиле, но выходит убого: Сами кнопки не вписываются в стиль страницы, а рисовать кучу элементов в таком стиле слишком заморочно. Мне нужно подобрать какой-то нейтральный стиль, в котором при этом я бы мог свободно рисовать свои рарисовки Нашел приятную картинку, по которой попробовал повторить формы. Попутно решил что буду сохранять исходники рисунков тоже в репозиторий, потому что это вроде бы как часть проекта. Хотя наверное по хорошему им бы отдельную репу. Теперь хочу сделать (ил...

Добавление assert Из важного - нужно добавить cgn.assert, для избавления от if проверок в коде. У стандартного нодовского assert, доступного из вепака, есть проблема, что в браузере пре ошибке он пишет что-то типа "Error: Object", поэтому надо обернуть его в try/catch - assert.js Дописывание тестов Поскольку теперь у меня появился анализатор, решил допокрыть базовый код тестами. Проблема в том, что 100% кода по мнению анализатора (И его финальной статистики) не обязательно гарантирует качество самих тестов. В обратную сторону тоже работает - иногда просто покрыть какую-то ветвь тестом таким образом, что бы тест "защитался" - довольно сложно. Но при этом убедительность такого теста с человеческой стороны - сомнительная. Угадывать как убрать эту красную полосочку пришлось наугад Сначала завершить тест, потом кинуть ошибку, при этом не делать никаких проверок что logger.error действительно отработал Зато теперь покрытие 100%, хотя как реально чего-...

Вводные Есть темплейт web проетка: webpack template . Не работает или работает плохо: Очень странно и долго грузятся сурсмапы Поддержка tern-project умерла Не генерится code-coverage Успел придумать еще несколько классов для cgn, вроде asset Успел довольно много правил для eslint поменять Процесс Самое простое: Обновить все зависимости Откопировать .eslintrc и jsconfig из другого проекта  Тесты Теперь настройка тестов - karma coverage . Там была основная проблема, что конфигурации очень плохо друг на друга ложаться, поэтому нужно сначала настроить генерацию покрытия, а потом уже смотреть как запустить остальные тесты. Нашел детальный пример на медиуме . Ставлю все что предлагают (зачем разными командами? Не знаю, копировать было проще): $ npm install karma --save-dev && npm install mocha --save-dev && npm install karma-mocha --save-dev && npm install --save-dev karma-webpack && npm install karma-sourcemap-loade...

Intro Генератор сеток типа этого , но в браузере. Принцип работы - стек модификаторов, по очереди рисующих на изображении. Все модификаторы разбиты по отдельным файлам, можно дописывать дополнительные, просто подключая их. В основной вьюшке приложения - канвас с одной стороны, и список модификаторов с другой. Каждому активному модификатору можно менять параметры, удалять добавлять новые и т.п. Дополнительно можно подумать над тем чтоб рисовать несколько примитивов на webgl и рендерить предпросмотр Проект Хочу попробовать сделать pure-функциональную логику, теплейт возьму свой, заодно допишу туда чего не хватает. Очень хочется подключить анализ покрытия тестов. css попробую наверное bulma.io, и по необходимости подключу vue, хотя надеялся бы обойтись ...  Upd 25.02.20 Довольно интересный Golden Layout и vue адаптер под него ... Модификаторы Grid  Основной модификатор - модификатор сетки. Можно выставить толщину, частоту, длину соединен...

About Заметка еще процессе работы.... Архитектура Technical debt #code_debt В случае, когда в коде намеренно реализуется плохое решение, явно это указывать тегом #code_debt. Можно TODO: code_dept что бы не терялось (ЕСЛИ в вашем проекте это не теряется), или заводить issue, если это поможет когда-нибудь исправить код. #depends Очень часты ситуации, в которых один код неявно зависит от исполнения другого. Вообще это самые опасные дырки в построении программы, но всякое бывает. Это могут быть юнит тесты, которые должны исполняться в определенном порядке, или классы, которые общаются через абстрактный интерфейс и на инициализации обязательно нужен определенный порядок вызова. Кроме человека, который написал этот код, никто с ходу не сможет сказать что там есть зависимость.  В момент, когда в нашем коде появляется неявная зависимость от другого куска, единственный способ это не забыть - написать #depends %от%, желательно с подробностями расписав что и где может слома...