Как стать автором
Обновить
193
0.1
Ivan Bogachev @sfi0zy

Creative frontend developer

Отправить сообщение

Интересно, что в самой документации они жирным выделяют don’t use @apply just to make things look “cleaner”. И дальше приводят список причин, почему так делать не рекомендуется. В основном аргументы на тему того, что все возвращается назад, к старому доброму CSS (ну или условному LESS/SASS с миксинами), теряется сам смысл Tailwind.

Было бы интересно почитать не только про синтаксис, но и про то, как это готовить, чтобы у коллег в перспективе глаза не вытекали. Потому как разметка шириной 250 символов (и это у вас еще примеры очень простые), десятки сущностей в одной строке без какой-либо подсветки синтаксиса, причем со спрятанными условиями на размер экрана и событиями, абсолютное отсутствие логической структуры в разметке, а в перспективе и необходимость внедрять дополнительный CSS откуда-то со стороны, не очень способствуют ее восприятию в целом. У такого подхода имеется некий предел сложности дизайна, после которого разметка превращается в полный винегрет и все же требует дополнительных действий для поддержания свежести.

Я, конечно, не искушенный сомелье, смотрю на все больше со стороны управления разработкой, чем со стороны бизнеса, но в какой-то момент пришел к похожей, хотя немного другой системе. Любая наша деятельность - это постоянные выборы. Некоторые выборы приводят к проблемам. Проблема = любые лишние траты времени, нервов команды, и, естественно, бюджета. Некоторые выборы повторяются часто, вроде "по какому принципу называть переменные". Некоторые - редко, вроде "какую по специальностям команду собрать под проект". Но даже очень большие выборы повторяются. Поэтому возможен алгоритм:

цикл до посинения {
    1. обнаружить повторяющуюся проблему
    2. вне зависимости от ее важности/эпичности проанализировать контекст
        -> узнать, какой повторяющийся выбор к ней приводит
    3. в следующий раз в такой же ситуации сделать другой выбор
    4. задокументировать для будущих участников
}

Даже если новый выбор будет иногда не очень - через N итераций инструментарий и процессы все равно вычищаются от выборов, которые стабильно приводят к проблемам. А то, что остается - "просто работает".

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

Справедливости ради вот эти "функция, прототип, промисы и асинхронность" - это самые основы Javascript. Виртуальный DOM - это способ перевалить на библиотеку свои обязанности по аккуратному и производительному обновлению частей страницы. Это способ меньше думать в привычных повседневных задачах. Единственное в вашем списке, что может вызвать вопросы - это монады. Мир современного JS сильно повернут в сторону ООП, и люди часто не знают, как какие штуки называются в терминах ФП, хотя что-то очень похожее используют постоянно. Если начать смотреть уже реализованные примеры, то сразу начнутся озарения в духе "ааа, так вы вон ту штуку этим словом обозвали". Так что для человека, занимающегося фронтендом, неделя на "вкатиться" в конкретную библиотеку и начать делать хоть что-нибудь полезное - реальность. Там гораздо сложнее может быть разобраться в том, что люди на местности уже наворотили, чем в самой библиотеке. Хотя если вкатываться с нуля - то да, естественным образом упрешься в незнание основ, и за неделю вообще ничего не получится.

нужно анимировать только определенные CSS-свойства: transform, opacity, filter, backdrop-filter

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

в памяти придется постоянно держать гораздо большее число графических объектов

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

текстура 3200 х 3200 пикселей, не знаю как будет справляться webgl

В мире WebGL есть ограничения на максимальный размер текстур. Зависят от устройств. Текстуры в 2048px сейчас поддерживают 100% устройств и браузеров. Бывают и больше, хотя я бы считал 2048px за безопасный в коммерции предел, где не будет сюрпризов на телефонах. Но даже не беря в расчет теоретические пределы - не обязательно же идти в крайности и все в одну текстуру собирать. Можно найти баланс и собирать кусками по 256x256px например.

массив приходится перебирать полностью

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

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

Сразу возникает вопрос: вы же не делаете это каждый кадр? Файл не меняется. Все, что на карте зафиксировано на одном месте, может быть собрано в текстуры больше, чем 16x16 пикселей. И переиспользовано. Для игровой логики там могут быть и земля, и стены, и десятки тысяч формально разных областей пространства. А картинка для фона - это картинка для фона. Она своей жизнью может жить. Ее даже собрать можно заранее. В реальном времени нужно что-то делать только с текстурами для меняющихся объектов, которых в зафиксированном файле по определению нет.

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

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

Это вы не видели профессиональный стандарт "программист". Если следовать ему, то программист 6 уровня квалификации (высшей, техлид по-нашему) должен иметь высшее образование и 1 год опыта. Но, как мы понимаем, есть нюанс.

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

Я понял. Меня смутило то, что я считал, что чтобы быть хорошим системным аналитиком нужно для начала быть как минимум средненьким техническим архитектором и понимать, как твоя система собственно работает. У меня первые две вертикали слились в одну большую. Но видимо под системным аналитиком принято считать немного другое.

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

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

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

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

Велосипед с прицепом на оленя будет более проходимым, чем квадроцикл. Ага. Ну да.

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

Про инженерное мышление сложно не согласиться. Только вот проблема в том, что мои студенты - уже программисты. Я вижу резюме большей части из них и там преобладают должности "мидлов" с 2-5 лет опыта, в том числе и в модных компаниях типа Сбера и Яндекса, про которые тут на Хабре принято говорить, что у них вроде как с кадрами все ок. То есть это не вайтишники, которые совсем с улицы к нам попадают. Они уже программисты. Окружающие программисты считают их программистами. А мышления, получается, нет. И это меня ставит в ступор. Либо у нас инженерная культура в целом нащупывет новое дно, либо я чего-то не вижу. На самом деле хочется верить, что второе.

Расскажу историю со стороны наставника с курсов "для мидлов" (читай "курсов повышения квалификации"). Все же у нас жалуются, что на курсах не анализируют задачи, контекст задач, все валят в кучу, не говорят про классы задач и классы инструментов, реальные практики их использования, как все это работает не на бумаге, про процессы взаимодействия в команде, с заказчиками и подрядчиками. Да? Ну в общем я попробовал. Благо есть чего рассказать. Сделал процесс, который хотел бы сам себе N лет назад. Менеджмент это не особо поддерживал, но и не возражал. Так что в рамках имеющихся у наставника возможностей я составил параллельную учебнику расширенную программу и начал со своими студентами анализировать происходящее и строить им систему в головах.

Ну и что из этого получилось?

Обратная связь о том, какие крутые ревью в проверках д/з, обсуждения разных практик на консультациях, никаких вопросов в духе "погуглите за меня", мы разбираем только принципы решения задач, контекст вокруг них, а дальше студент уже сам пробует, и поехал, поехал, поехал, задачи из учебника щелкаются как орешки, а потом он прибегает с вопросами о других практиках, которые он где-то откопал, может на работе у него что-то появилось, мы обсуждаем, и он убегает дальше заниматься. И никто не жалуется на нехватку времени. И, что совсем здорово, студентам даже не нужна какая-то дополнительная командная работа - они с какого-то момента уже играют в шахматы сами с собой, могут все процессы в голове построить. Это, конечно, не так круто, как полноценная команда сложившихся специалистов, но в рамках бюджета - это лучше, чем ничего. К середине курса студента сложно воспринимать как студента. Он - скорее коллега, который просто с какой-то узкой темой не сталкивался. Так и должно работать IT-образование. Да?

Только вот таких студентов было 2-3 из 100. Есть еще вторая группа студентов - стабильно появляются молодые девушки (искренне не знаю, почему именно девушки), которым не хватает технической подкованности, но они все делают очень аккуратно, и они могут подхватить темы, связанные с построением процессов в команде, начинают видеть контекст, в котором работают. Плюс они хорошо видят свои слабые места. И вырастают они в... я бы назвал это словом "подмастерье". Их можно взять в помощники, делегировать что-то не очень сложное и быть уверенным, что все будет сделано хорошо, особых проблем не будет. А если что - они спросят, куда посмотреть. По крайней мере скрывать проблемы они не станут. Не идеально, но не всем быть архитекторами. Пойдет. Таких может быть 5-7 из 100.

А почти все остальные, это получается почти 90% студентов, отвергают саму идею анализа задач. Они могут быть более технически подкованными или менее. Это не имеет значения. Для них противоестественна сама мысль, что можно сначала подумать, а потом сделать. Что можно вообще притормозить и подумать. На удивление часто такое отвержение мыслительного процесса доходит до абсурда, когда пытаешься со студентом проанализировать его задачу, дать ему простой универсальный подход ко всем подобным задачам, а он в ответ - "дайте мне правильное решение". Потом следующая задача, по сути такая же, и снова - "дайте правильное решение". Следующая задача - то же самое. Они каждую задачу видят как что-то совершенно новое. Как нейронные сети, которые не помнят истории и каждый раз генерируют что-то с нуля, допуская одни и те же ошибки, привнося одни и те же проблемы в проект. Естественно, что времени и внутренних ресурсов на постоянное изобретение чего-то нужно много. Это очень сильная нагрузка, в которой еще и не видно развития. Каждая задача же решается как новая. Но нет запроса "я что-то запарился, может тут есть какая-то система, которую я не вижу?". Нет. Им не нужно универсальное умение решать задачи в предметной области, им нужно правильное решение для конкретной формулировки в конкретном ТЗ. Им кажется, что все очень сложно, хотя объективно они знают достаточно, просто в голове каша. Факты не собираются в систему для переиспользования. Причем частенько возникает ощущение дежавю, студенты будто говорят одними и теми же предложениями, связанными со словом "правильно". Как зомби. Эти студенты могут "пройти" курс, но будет ли на выходе сильный специалист? Скорее нет. Может быть когда-нибудь, но не сейчас. И что с этим делать - загадка. Иногда кажется, что вот вроде бы подтолкнул студента к каким-то толковым мыслям, но мы переходим в новый модуль, он берет в руки новые инструменты, или просто уходит на новогодние каникулы - и все как с чистого листа.

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

Хайп на ИИ - это понятно, но было бы интересно посмотреть на статистику просмотров вопросов по темам. Возможно, что резкие скачки посещаемости происходят не глобально, на всем Stack Overflow, а локально, в каких-то отдельных больных темах. Например, там традиционно самые популярные языки - это CSS и JS. Но что там происходит? Еще пару лет назад мы поддерживали зоопарк браузеров и решение простейших бытовых задач превращалось в бесконечные вопросы "а почему оно не работает?". Сейчас зоопарк закончился. Как раз весной 2022 года последний IE официально похоронили. Тогда компании массово переходили на подход "с сегодняшнего дня поддерживаем только вечнозеленые браузеры". Соответственно, тонны трафика на вопросы про кроссбраузерность просто исчезли. И в целом многолетнее падение трафика на определенные темы может быть связано просто с тем, что фронтенд взрослеет и какие-то боли, которые когда-то мучали всех в этой отрасли, в какой-то момент просто одна за одной исчезают. Возможно и в других направлениях IT происходит что-то похожее.

Справедливости ради стоит сказать, что ваш код по сути занимается вариантом №2. Раз в секунду навешивает новые классы с новыми стилями. Тут, наверное, нужно говорить не о принципиальной позиции "дергать элемент из JS, или не дергать", потому что дергать придется в любом случае, а о частоте дергания. Мы можем все промежуточные значения в анимации рассчитывать скриптом и дергать элементы 60 раз в секунду, а можем рассчитывать какие-то точки отсчета и создавать keyframes на их основе, дергая элементы по мере необходимости. Тут можно передавать нужные значения в мир CSS через custom properties и их использовать в keyframes, или можно взять Web Animations API, если уж хочется прямо генерировать keyframes в скриптах. Получится почти то же самое, что и вы придумали с генерированием фреймов, только нативное, без завязки на экосистему реакта.

А почему вы решили отказаться от стандартной практики рисования линий через свойства stroke-dasharray и stroke-dashoffset?

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

Побуду адвокатом дьявола и скажу, что CSS - это очень логичный язык. Главное - это идти от основ и смотреть на него как обычный человек с житейской логикой.

У нас есть блоки и инлайны. Блоки - с контролируемым размером, инлайны - с размером, который получается по остаточному принципу. Какой получился, такой и есть. Появляется новый инструмент - flex, который контролирует детей. Вопрос - дети должны быть с контролируемым размером, или нет? Очевидно, что они должны должны быть с контролируемым размером, чтобы его контролировать. Иначе ничего не получится.

Дальше. Calc. Сколько будет 1кг + 2кг? Будет 3кг. Мы можем складывать значения в одних единицах измерения. Сколько будет 1кг + 10? Будет 1кг + 10. Комплексное значение, которое не может быть использовано как мера веса. Мы можем сложить углы в градусах и радианах, потому что эти единицы конвертируются друг в друга. И результат сможем конвертировать или в градусы или в радианы. Но сложим градусы и килограммы - и получим комплексное значение, которое не конвертируется обратно ни в одно, ни в другое. Почему бы нам от CSS ожидать умения конвертировать неконвертируемое? Почему CSS должен делить градусы на килограммы и складывать мили с литрами?

Дальше. Ширина. Есть все те же блоки и инлайны. Если там нет контента, то и ширины может не быть. И минимальной ширины тоже. Ничего не будет. Все схлопнется. А auto - это "на усмотрение браузера". Браузер должен определиться, во что разрешить это auto. Если у элементов может не быть ширины - то пусть будет минимальная ширина в 0px. Довольно топорная логика. Дальше у нас появляется новый инструмент - гриды. А гриды это про что? Правильно, про то, чтобы контролировать детей и задавать им размеры по всякому вне зависимости от контента. Они не должны схлопываться в 0, даже если пустые. В этом смысл гридов. Если все размеры рассчитываются на лету, и в 0 схлопнуть нельзя, то браузер не может их изначально определить. Остается auto до тех пор, пока страница не будет рендериться и не станет понятно, какого на самом деле размера там все делать.

Дальше. Position fixed. Когда-то давно у нас вроде как был один контейнер - окно браузера. Но потом появились инструменты вроде transform или contain, которые создают новые контейнеры для независимого от остальной страницы рендеринга элементов. Но если какая-то часть страницы вырвана из нее, существует независимо, в своем контейнере, и ничего не знает об окружении, то как можно что-то расположить относительно окружения? Никак. Так что fixed все еще работает относительно контейнера, но мы можем иметь много этих самых контейнеров.

По поводу логических свойств. Посмотрите видео Kevin Powell или статьи Ahmad Shadeed. Они используют их так, как я написал в вопросах.

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

То, что они могут сломать верстку при определении другого направления текста? Так люди либо это знают, либо узнают... Статья про расширение кругозора

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

Информация

В рейтинге
2 587-й
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность

Специализация

Специалист
Senior