Не столько совет, сколько мысли вслух, которые может наведут на какие-то другие мысли:
За последние годы широкая публика бессознательно привыкла к картинке с беззеркальных кропов и полных кадров, с большой глубиной цвета, хорошим динамическим диапазоном, и уменьшенной до FullHD с честных 4K/6K. Для нее видео с любой камеры за 10 тысяч рублей будет выглядеть как снятое на тапок. Чудес не бывает. А люди быстро привыкают к хорошему.
Но и камера сама по себе не решает, хотя нам всем хочется верить, что купишь вон ту, и все сразу станет по-другому. Само по себе не станет. Лучшее, что тут можно сделать - это вложиться в место для съемок, контролируемый объемный свет, и, собственно, в процесс. Планирование, аккуратное кадрирование, стабильное экспонирование, стабильный звук и дальнейшая обработка. Вот это вот все. Чтобы все было на автомате и выжимались все соки из имеющейся техники и окружения. Никто не хочет заниматься созданием своего мини-продакшена, нужно время и силы, но он дает гораздо больший прирост к качеству, чем замена одного тапка на другой, пусть и немного более дорогой. Свой уникальный контент у вас уже есть, его завернуть нужно красиво. А толковая камера для видео рано или поздно придет, добавится к процессу, только уже немного в другом бюджете.
Подобные внезапные вопросы, заданные в условиях стресса (как на собеседовании) могут показывать на какую роль в проектах человек будет метить естественным образом, где ему будет комфортно. В случае с люками, как прийти к необходимости в круглых:
"Круглые тягать удобно, можно катать, и в люки они не проваливаются." - Персонаж думает о себе и своем удобстве. Позиция линейного исполнителя.
"Если строить колодны из камня, то круглые лучше всего держат давление грунта, не обваливаются, если из железобетона - то можно и квадратный построить, а форма люков обычно подгоняется под колодец, но в целом это не так важно и можно хоть в форме кракозябры сделать..." - Персонаж видит, что там есть техническая система, в которой одни вещи как-то связаны с другими, физику не обманешь, а какие-то решения вторичны. Позиция инженера-конструктора.
Сначала персонаж уточняет контекст, узнает, что на самом деле мы владеем металлургическим комбинатом и у нас тендер покрыть все люки в городе, и уже пляшет от этого. "Если у нас есть легаси-система круглых колодцев, то ее дешевле всего покрыть круглыми люками. Это минимальный необходимый размер, меньше всего металла уйдет, плюс они легче других вариантов, так что логистика будет дешевле, а еще они не проваливаются - будет хороший маркетинговый булшит о том, как мы заботимся о линейных работягах." - Персонаж видит, что на самом деле мы тут деньги делаем, и что не все вопросы лежат в инженерной плоскости. Позиция лида/аналитика/PM.
С аптеками то же самое - можно идти от позиции "не знаю, не положено знать, дайте угадаю", можно от "тут есть система, зависимость от плотности населения, и миллиона других факторов и давайте ИИ прикрутим", а можно от "зачем мы это делаем, в чем ценность информации?", уточнить контекст, и там уже смотреть в зависимости от того, что бизнес на самом деле делает (в статье знакомый автора не уточнял по всей видимости).
Вы можете написать свой крохотный метод с удобным API и так, как вам нужно
Приводит к тому, что в разных местах проекта плодятся крохотные, почти одинаковые, но не совсем, методы, от разных авторов, которые делают вроде одно и то же, но не совсем. Это такой зоопарк, от которого увеличивается вероятность логических ошибок, которые сложно отлавливать. Нужно постоянно в новый контекст влезать. Плюс дублирующийся код, который порой сложно просто так сократить в дальнейшем из-за едва различимой разницы во внутренней логике. Тут нужно сильно заморачиваться с ревью и документацией, чтобы этого не допустить. Но это тоже время, да и вечные споры, как какую помогалку лучше сделать и назвать. Библиотеки - сборники утилит, вроде lodash или D3, дают тот же эффект, что и инструменты по типу prettier - тимлид приходит, бъет кулаком в стол и говорит "мы делаем так!". И все, больше никакого зоопарка. Это далеко не идеальный вариант, но тем не менее проблему синхронизации всех участников решает.
А они никуда не деваются. Просто они научены решать задачи в искусственно ограниченных условиях, но не научены смотреть вширь и видеть продукт целиком. Поэтому они до последнего возят бананы за 1000 км на верблюде, но не настаивают на том, что пора уже его сдать в зоопарк и купить машину.
Интересно, что в самой документации они жирным выделяют 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 происходит что-то похожее.
Не столько совет, сколько мысли вслух, которые может наведут на какие-то другие мысли:
За последние годы широкая публика бессознательно привыкла к картинке с беззеркальных кропов и полных кадров, с большой глубиной цвета, хорошим динамическим диапазоном, и уменьшенной до FullHD с честных 4K/6K. Для нее видео с любой камеры за 10 тысяч рублей будет выглядеть как снятое на тапок. Чудес не бывает. А люди быстро привыкают к хорошему.
Но и камера сама по себе не решает, хотя нам всем хочется верить, что купишь вон ту, и все сразу станет по-другому. Само по себе не станет. Лучшее, что тут можно сделать - это вложиться в место для съемок, контролируемый объемный свет, и, собственно, в процесс. Планирование, аккуратное кадрирование, стабильное экспонирование, стабильный звук и дальнейшая обработка. Вот это вот все. Чтобы все было на автомате и выжимались все соки из имеющейся техники и окружения. Никто не хочет заниматься созданием своего мини-продакшена, нужно время и силы, но он дает гораздо больший прирост к качеству, чем замена одного тапка на другой, пусть и немного более дорогой. Свой уникальный контент у вас уже есть, его завернуть нужно красиво. А толковая камера для видео рано или поздно придет, добавится к процессу, только уже немного в другом бюджете.
Подобные внезапные вопросы, заданные в условиях стресса (как на собеседовании) могут показывать на какую роль в проектах человек будет метить естественным образом, где ему будет комфортно. В случае с люками, как прийти к необходимости в круглых:
"Круглые тягать удобно, можно катать, и в люки они не проваливаются." - Персонаж думает о себе и своем удобстве. Позиция линейного исполнителя.
"Если строить колодны из камня, то круглые лучше всего держат давление грунта, не обваливаются, если из железобетона - то можно и квадратный построить, а форма люков обычно подгоняется под колодец, но в целом это не так важно и можно хоть в форме кракозябры сделать..." - Персонаж видит, что там есть техническая система, в которой одни вещи как-то связаны с другими, физику не обманешь, а какие-то решения вторичны. Позиция инженера-конструктора.
Сначала персонаж уточняет контекст, узнает, что на самом деле мы владеем металлургическим комбинатом и у нас тендер покрыть все люки в городе, и уже пляшет от этого. "Если у нас есть легаси-система круглых колодцев, то ее дешевле всего покрыть круглыми люками. Это минимальный необходимый размер, меньше всего металла уйдет, плюс они легче других вариантов, так что логистика будет дешевле, а еще они не проваливаются - будет хороший маркетинговый булшит о том, как мы заботимся о линейных работягах." - Персонаж видит, что на самом деле мы тут деньги делаем, и что не все вопросы лежат в инженерной плоскости. Позиция лида/аналитика/PM.
С аптеками то же самое - можно идти от позиции "не знаю, не положено знать, дайте угадаю", можно от "тут есть система, зависимость от плотности населения, и миллиона других факторов и давайте ИИ прикрутим", а можно от "зачем мы это делаем, в чем ценность информации?", уточнить контекст, и там уже смотреть в зависимости от того, что бизнес на самом деле делает (в статье знакомый автора не уточнял по всей видимости).
В целом я со всем согласен, но
Приводит к тому, что в разных местах проекта плодятся крохотные, почти одинаковые, но не совсем, методы, от разных авторов, которые делают вроде одно и то же, но не совсем. Это такой зоопарк, от которого увеличивается вероятность логических ошибок, которые сложно отлавливать. Нужно постоянно в новый контекст влезать. Плюс дублирующийся код, который порой сложно просто так сократить в дальнейшем из-за едва различимой разницы во внутренней логике. Тут нужно сильно заморачиваться с ревью и документацией, чтобы этого не допустить. Но это тоже время, да и вечные споры, как какую помогалку лучше сделать и назвать. Библиотеки - сборники утилит, вроде lodash или D3, дают тот же эффект, что и инструменты по типу prettier - тимлид приходит, бъет кулаком в стол и говорит "мы делаем так!". И все, больше никакого зоопарка. Это далеко не идеальный вариант, но тем не менее проблему синхронизации всех участников решает.
А они никуда не деваются. Просто они научены решать задачи в искусственно ограниченных условиях, но не научены смотреть вширь и видеть продукт целиком. Поэтому они до последнего возят бананы за 1000 км на верблюде, но не настаивают на том, что пора уже его сдать в зоопарк и купить машину.
Интересно, что в самой документации они жирным выделяют
don’t use @apply just to make things look “cleaner”. И дальше приводят список причин, почему так делать не рекомендуется. В основном аргументы на тему того, что все возвращается назад, к старому доброму CSS (ну или условному LESS/SASS с миксинами), теряется сам смысл Tailwind.Было бы интересно почитать не только про синтаксис, но и про то, как это готовить, чтобы у коллег в перспективе глаза не вытекали. Потому как разметка шириной 250 символов (и это у вас еще примеры очень простые), десятки сущностей в одной строке без какой-либо подсветки синтаксиса, причем со спрятанными условиями на размер экрана и событиями, абсолютное отсутствие логической структуры в разметке, а в перспективе и необходимость внедрять дополнительный CSS откуда-то со стороны, не очень способствуют ее восприятию в целом. У такого подхода имеется некий предел сложности дизайна, после которого разметка превращается в полный винегрет и все же требует дополнительных действий для поддержания свежести.
Я, конечно, не искушенный сомелье, смотрю на все больше со стороны управления разработкой, чем со стороны бизнеса, но в какой-то момент пришел к похожей, хотя немного другой системе. Любая наша деятельность - это постоянные выборы. Некоторые выборы приводят к проблемам. Проблема = любые лишние траты времени, нервов команды, и, естественно, бюджета. Некоторые выборы повторяются часто, вроде "по какому принципу называть переменные". Некоторые - редко, вроде "какую по специальностям команду собрать под проект". Но даже очень большие выборы повторяются. Поэтому возможен алгоритм:
Даже если новый выбор будет иногда не очень - через N итераций инструментарий и процессы все равно вычищаются от выборов, которые стабильно приводят к проблемам. А то, что остается - "просто работает".
Мне такой подход нравится больше анализа конкретных больших успехов или провалов, потому что к завершению чего-то обычно приводит целая гора маленьких выборов, и не только инженерных, и постфактум сложно понять, а какие из них действительно помогали идти к цели, а какие мешали. Можно себя случайно убедить в том, что не имеет смысла. А методичная чистка просто потихоньку работает в фоновом режиме, полируя все процессы. Она работает как стабилизатор процессов. К успешному успеху сама по себе не приведет, но и не даст эпично провалиться на случайно сложившейся комбинации проблемных выборов.
Справедливости ради вот эти "функция, прототип, промисы и асинхронность" - это самые основы Javascript. Виртуальный DOM - это способ перевалить на библиотеку свои обязанности по аккуратному и производительному обновлению частей страницы. Это способ меньше думать в привычных повседневных задачах. Единственное в вашем списке, что может вызвать вопросы - это монады. Мир современного JS сильно повернут в сторону ООП, и люди часто не знают, как какие штуки называются в терминах ФП, хотя что-то очень похожее используют постоянно. Если начать смотреть уже реализованные примеры, то сразу начнутся озарения в духе "ааа, так вы вон ту штуку этим словом обозвали". Так что для человека, занимающегося фронтендом, неделя на "вкатиться" в конкретную библиотеку и начать делать хоть что-нибудь полезное - реальность. Там гораздо сложнее может быть разобраться в том, что люди на местности уже наворотили, чем в самой библиотеке. Хотя если вкатываться с нуля - то да, естественным образом упрешься в незнание основ, и за неделю вообще ничего не получится.
Добавлю еще такой момент, что не все фильтры одинаковые. И помимо самого факта использования GPU есть еще вопрос алгоритма рендеринга. Алгоритмы для blur или drop-shadow с большим радиусом - очень затратные. С ними можно убить производительность на корню и все остальное станет не важно.
Текстуры будут большего размера, но полигонов будет на порядок меньше по количеству. Мы размениваем одно на другое, а не ухудшаем все сразу.
В мире WebGL есть ограничения на максимальный размер текстур. Зависят от устройств. Текстуры в 2048px сейчас поддерживают 100% устройств и браузеров. Бывают и больше, хотя я бы считал 2048px за безопасный в коммерции предел, где не будет сюрпризов на телефонах. Но даже не беря в расчет теоретические пределы - не обязательно же идти в крайности и все в одну текстуру собирать. Можно найти баланс и собирать кусками по 256x256px например.
Плоский массив придется перебирать. На то он и плоский. Но "другая структура данных" - это не обязательно что-то логически сложное. Вам на карте из квадратных ячеек не нужна полноценная кластеризация, не нужны хитрые сравнения расстояний во все стороны. Вопрос только в том, чтобы добавить размерностей в массив объектов.
Сразу возникает вопрос: вы же не делаете это каждый кадр? Файл не меняется. Все, что на карте зафиксировано на одном месте, может быть собрано в текстуры больше, чем 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 происходит что-то похожее.