Я пока сомневаюсь в этом. Программу "описывает" программист (в голове, на листике, на митингах, etc). И раньше её нужно было ещё и "закодить", да. Теперь, программист также должен "придумать" программу, но закодить может её через аи. Менеджеры и продакты оперируют бизнес-требованиями и терминами. А прораммист оперирует программными требованиями и терминами, просто кодить ему уже не обязательно.
Мм, хз. Сейчас работа программиста какая? Взять бизнес требования \ таск \ баг (может быть условно в одно предложение - "нам нужен клон Убера, вот в этом месте, чтобы ... бла бла бла"), распутывает клубок зависимостей, подводных камней, комуницирует ещё с несколькими людьми чтобы сложить полный пазл. И только когда сделал всю подготовительную работу (т.е. самое сложное, понял что именно хотят; или понял - что пока они не знают что хотят, но как минимум он программист понял где подстелить соломку, где городить абстракции, а где сделать в лоб, чтоб быстро отдать; понял где общее, а где частное исключение; понял нужно надёжно и пуленепробиваемо, а где нужно быстро) - только тогда продумывает "контракты" на стыках систем, и уже пишет код. Т.е. написание кода - это процентов 20%, и это самое лёгкое. Собственно - то что ИИ и должен делать, типа автокомплит мыслей программиста (чтоб руками не набивать).
И вот ИИ как бы хорош, когда ему на вход даёшь "контракты", которые сам заранее продумал. Если аналитик или менеджер способен дать на вход эти "контракты" - то это программирование и есть (просто грубо - не в иде, а в чате).
А если на входе будет - "нам нужен аналог амазона" - то не знаю - "нет тз - результат хз".)
Теперь я кажется понял и смаппил ваши абстракции на свои.))
У себя я юзаю условно только "компонентные токены". Т.е внутри компонента лежат все стили\ассеты что ему нужны. У него есть дефолтные какие-то состояния. Ну и окружение диктует этому компоненту как ему быть в каждом каком-то исключительном случае (через пропсы или css-переменные).
И если много разных компонентов используют довольно много похожих стилей (т.е. хотя бы 4 компонента с хотя бы 5 строками одинаковых стилей) - то я эти повторяющиеся стили выношу в миксины или классы. Ну а в компоненте уже пишу @include или @extend . В вашей системе - это "семантический слой".
т.е. эти люди должны будут рассказывать ии, например - как провести некую миграцию; или как отрефакторить некий модуль; или в каком месте кодовой базы имплементировать интеграцию с внешним сервисом, и как именно это сделать; или что, когда и в какую ветку коммитить\мерджить; и т.д. Так для этого им нужно будет знать программистсткую терминологию, процессы и экосистему, т.е. быть хотя бы в прошлом программистом. Есть же ш пословица - что-то типа "shit in - shit out".
и второе - а свою основную работу когда они будут делать, если они будут делать работу программистов? Или вы из тех, кто считает текущую работу аналитиков и менеджеров глупой и безполезной?.)
Если бренд решит, что «фирменный синий» должен стать чуть светлее, вы поменяете HEX-код только в одном примитиве blue-500.
А само имя примитива blue-500 - не меняется? А если бизнес решит что теперь фирменный синий не чуть светлее, а сильно светлее, или вообще красный - какой порядок действий тогда?
И второй вопрос. Если взять, что например бренд-колор\акцент-колор\ховер-колор\итд - бизнес не будет менять никогда на уровне всего бизнеса всех продуктов. Зато будут меняться эти значения на уровне исключений в куче разных мест:
- Тут на новый год - хотим вырвеглазно-зелёный хедер, и только в этом продукте. Соответственно кнопки на нём уже будут тоже другие, ну и каскадно цвета текстов нужно поправить. - А тут во втором продукте - нужна спец кнопка со скидкой, такого цвета ещё не было нигде. - А тут эта кнопка что-то не очень смотрится с динамической фотографией на фоне, нужно её немножко изменить. - А тут в тёмной теме, в этом конкретном окружении - переключение темы согласно дизайн системы не подходит, нужно изменить. Т.е. в светлой теме всё ок, а вот в тёмной - фигня.
И это только цвета. А есть ещё отступы, шрифты, скругления какие-нибудь.
Так вот вопрос.. в этом случае, правильно ли я понимаю, что упарываться в дизайн-систему с токенами не имеет смысла, и все стили простом декларируются внутри компонентов? и этого будет достаточно. Максимум все повторяющееся цвета вынести в переменные.
Есть ощущение, что эти всё дизайн-токены и строгие правила дизайн-систем нарушают т.н. "high cohesion low coupling" - и только выкручивают руки, и вся абстракция начинает течь как только в команду приходит новый дизайнер, или начинает создаваться новый продукт, а текущий ui-kit к нему не очень подходит)
Первым телескопом - должен быть бинокль 8х56 хотя бы от 1000 евро (лучше от 1500). Кайфа больше чем от телескопа за 5к+ евро. Правда есть риск, что к телескопу так и не прийдёшь - потому что бинокуляры круче)) а в телескопы действительно лучше смотреть в професиональных обсерваториях.
Чистый UI подразумевает UI логику (только), типа открыть окно, спрятать элемент и тд.
ага! вот и подловил!)) удтверждение выше - противоречит этому:
Presentational (dumb): только пропсы, без хуков/состояния/фетчинга → чистый UI
типа если пришёл пропс text="some text" - то нужно написать тест, что компонент рендерит "some text"? Получается и чистые функции, типа sum(a,b) - тоже нужно тестировать?
Мой поинт в том, что они ж dumb\чистые, т.е. без сайд-эффектов, без каких-то внешних контрактов, без внутренних сложных разветлений. Зачем их тестировать?
Вот связки таких dumb-компонетов между сосбой и с другими не dumb-компонентами - вот их нужно тестить, это понятно. Но вот сжигать энергию (как ментальную, так и ресурсы) ради тупых компонентов?... - я б "уволил" сразу..)
Забавно. Сначало "быканул" на виртаулизацию с помощью js. А потом вконце добавил - "ой, ну она всё-таки нужна для некоторых сценариев" (т.е. почти всегда для продакшена).
Понятное дело, что если есть условно 50 элементов, а рендерить нужно только 10-20ть - никто виртуализацию тянуть не будет в проект.
Именно с потерей мышц и силы связано низкое качество жизни пожилых людей.
Хмм, у меня так по жизни вышло, что есть друзья и знакомые в пожилом возрасте. Мне всегда интересно с ними общаться, им со мной.) Так вот, одна из тем общения - это здоровье, и как "вкатываться" в старость. Никто не жалуется на мышцы. В основном жалуются на кости\колени\общую_гибкость.
Я на основании этого уже как давно сделал вывод, что кпд качалки - самый невыгодный (с перспективы - входа в старость и проживания этой старости). Довольно давно уже сделал ставку на растяжку (ака стрейчинг), турники, массаж, общую зарядку, и баскетбол.
А именно: - один день - баскет (кардио + координация\мозги\общение. надеюсь поможет с паркинсоном.)) - другой день групповой стрейчинг\йога (шпагат почти в 40 лет жене очень заходит.)) - третий день - турники\зарядка на улице - четвёртый день - массаж (каждый раз разный пробою)
Всё это не в одной неделе, а в двух. Комбинирую по настроению\возможностям. Мышечная масса идёт бонусом сама собой - её не нужно качать специально. Вобщем, лет через 25-ть отчитаюсь по результату) Бассейны и бег - отмёл по той же причине.. невыгодный кпд (время\результат\вникание_в_тему)
ПС - очень хотел бы добавить гимнастику и что-то боевое, но позно раздуплился.. надо было где-то лет в 25ть в это заходить.)
ППС. условно гибкий вандамм мне больше нравится как выглядит в старости, чем надутый шварц. Да, знаю, лицо потяганное, жизнь испаганил веществами.. но ведь после всего пережитого - бодряк, и с ровной осанкой..))
Лет десять как пью кофе с перекусом один раз в день, посредине дня, где-то 12:00-13:30. Обед у меня в 15:00. Мотивация была - хакнуть день. Т.е. поместить в один день - два дня в плане перформанса. В итоге до сих пор ооочень кайфую от этой одной чашки. И раздупление и фокус буквально приходят сразу только от самого запаха кофе.
Я пока сомневаюсь в этом. Программу "описывает" программист (в голове, на листике, на митингах, etc). И раньше её нужно было ещё и "закодить", да. Теперь, программист также должен "придумать" программу, но закодить может её через аи.
Менеджеры и продакты оперируют бизнес-требованиями и терминами. А прораммист оперирует программными требованиями и терминами, просто кодить ему уже не обязательно.
Мм, хз. Сейчас работа программиста какая? Взять бизнес требования \ таск \ баг (может быть условно в одно предложение - "нам нужен клон Убера, вот в этом месте, чтобы ... бла бла бла"), распутывает клубок зависимостей, подводных камней, комуницирует ещё с несколькими людьми чтобы сложить полный пазл. И только когда сделал всю подготовительную работу (т.е. самое сложное, понял что именно хотят; или понял - что пока они не знают что хотят, но как минимум он программист понял где подстелить соломку, где городить абстракции, а где сделать в лоб, чтоб быстро отдать; понял где общее, а где частное исключение; понял нужно надёжно и пуленепробиваемо, а где нужно быстро) - только тогда продумывает "контракты" на стыках систем, и уже пишет код. Т.е. написание кода - это процентов 20%, и это самое лёгкое. Собственно - то что ИИ и должен делать, типа автокомплит мыслей программиста (чтоб руками не набивать).
И вот ИИ как бы хорош, когда ему на вход даёшь "контракты", которые сам заранее продумал. Если аналитик или менеджер способен дать на вход эти "контракты" - то это программирование и есть (просто грубо - не в иде, а в чате).
А если на входе будет - "нам нужен аналог амазона" - то не знаю - "нет тз - результат хз".)
Теперь я кажется понял и смаппил ваши абстракции на свои.))
У себя я юзаю условно только "компонентные токены". Т.е внутри компонента лежат все стили\ассеты что ему нужны. У него есть дефолтные какие-то состояния. Ну и окружение диктует этому компоненту как ему быть в каждом каком-то исключительном случае (через пропсы или css-переменные).
И если много разных компонентов используют довольно много похожих стилей (т.е. хотя бы 4 компонента с хотя бы 5 строками одинаковых стилей) - то я эти повторяющиеся стили выношу в миксины или классы. Ну а в компоненте уже пишу @include или @extend . В вашей системе - это "семантический слой".
т.е. эти люди должны будут рассказывать ии, например - как провести некую миграцию; или как отрефакторить некий модуль; или в каком месте кодовой базы имплементировать интеграцию с внешним сервисом, и как именно это сделать; или что, когда и в какую ветку коммитить\мерджить; и т.д. Так для этого им нужно будет знать программистсткую терминологию, процессы и экосистему, т.е. быть хотя бы в прошлом программистом. Есть же ш пословица - что-то типа "shit in - shit out".
и второе - а свою основную работу когда они будут делать, если они будут делать работу программистов? Или вы из тех, кто считает текущую работу аналитиков и менеджеров глупой и безполезной?.)
Кто скажет ИИ что именно делать?
А кто задачу опишет?
А само имя примитива blue-500 - не меняется? А если бизнес решит что теперь фирменный синий не чуть светлее, а сильно светлее, или вообще красный - какой порядок действий тогда?
И второй вопрос.
Если взять, что например бренд-колор\акцент-колор\ховер-колор\итд - бизнес не будет менять никогда на уровне всего бизнеса всех продуктов. Зато будут меняться эти значения на уровне исключений в куче разных мест:
- Тут на новый год - хотим вырвеглазно-зелёный хедер, и только в этом продукте. Соответственно кнопки на нём уже будут тоже другие, ну и каскадно цвета текстов нужно поправить.
- А тут во втором продукте - нужна спец кнопка со скидкой, такого цвета ещё не было нигде.
- А тут эта кнопка что-то не очень смотрится с динамической фотографией на фоне, нужно её немножко изменить.
- А тут в тёмной теме, в этом конкретном окружении - переключение темы согласно дизайн системы не подходит, нужно изменить. Т.е. в светлой теме всё ок, а вот в тёмной - фигня.
И это только цвета. А есть ещё отступы, шрифты, скругления какие-нибудь.
Так вот вопрос.. в этом случае, правильно ли я понимаю, что упарываться в дизайн-систему с токенами не имеет смысла, и все стили простом декларируются внутри компонентов? и этого будет достаточно. Максимум все повторяющееся цвета вынести в переменные.
Есть ощущение, что эти всё дизайн-токены и строгие правила дизайн-систем нарушают т.н. "high cohesion low coupling" - и только выкручивают руки, и вся абстракция начинает течь как только в команду приходит новый дизайнер, или начинает создаваться новый продукт, а текущий ui-kit к нему не очень подходит)
Первым телескопом - должен быть бинокль 8х56 хотя бы от 1000 евро (лучше от 1500). Кайфа больше чем от телескопа за 5к+ евро. Правда есть риск, что к телескопу так и не прийдёшь - потому что бинокуляры круче)) а в телескопы действительно лучше смотреть в професиональных обсерваториях.
ага! вот и подловил!)) удтверждение выше - противоречит этому:
типа если пришёл пропс text="some text" - то нужно написать тест, что компонент рендерит "some text"? Получается и чистые функции, типа sum(a,b) - тоже нужно тестировать?
Мой поинт в том, что они ж dumb\чистые, т.е. без сайд-эффектов, без каких-то внешних контрактов, без внутренних сложных разветлений. Зачем их тестировать?
Вот связки таких dumb-компонетов между сосбой и с другими не dumb-компонентами - вот их нужно тестить, это понятно. Но вот сжигать энергию (как ментальную, так и ресурсы) ради тупых компонентов?... - я б "уволил" сразу..)
Ну в самом деле, зачем пистать тест на это?:
Забавно. Сначало "быканул" на виртаулизацию с помощью js. А потом вконце добавил - "ой, ну она всё-таки нужна для некоторых сценариев" (т.е. почти всегда для продакшена).
Понятное дело, что если есть условно 50 элементов, а рендерить нужно только 10-20ть - никто виртуализацию тянуть не будет в проект.
а зачем "чистый UI" тестировать.. чтоб не скучно было?.)
По идее можно ещё проще - установить и дать доступ к какому-нибудь phpMyAdmin. Админка в первозданном виде)
интересено, какие же это сценарии на практике?.)
ах вот оно что, т.е. если вы не разрабатываете веб- фигму\фотошоп - то всё остаётся как и прежде, а именно:
а уж а каком виде оно скопировалось из макета в код - в hex, rgb, hsl, oklch - абсолютно без разницы..)
Хмм, у меня так по жизни вышло, что есть друзья и знакомые в пожилом возрасте. Мне всегда интересно с ними общаться, им со мной.) Так вот, одна из тем общения - это здоровье, и как "вкатываться" в старость. Никто не жалуется на мышцы. В основном жалуются на кости\колени\общую_гибкость.
Я на основании этого уже как давно сделал вывод, что кпд качалки - самый невыгодный (с перспективы - входа в старость и проживания этой старости). Довольно давно уже сделал ставку на растяжку (ака стрейчинг), турники, массаж, общую зарядку, и баскетбол.
А именно:
- один день - баскет (кардио + координация\мозги\общение. надеюсь поможет с паркинсоном.))
- другой день групповой стрейчинг\йога (шпагат почти в 40 лет жене очень заходит.))
- третий день - турники\зарядка на улице
- четвёртый день - массаж (каждый раз разный пробою)
Всё это не в одной неделе, а в двух. Комбинирую по настроению\возможностям. Мышечная масса идёт бонусом сама собой - её не нужно качать специально.
Вобщем, лет через 25-ть отчитаюсь по результату) Бассейны и бег - отмёл по той же причине.. невыгодный кпд (время\результат\вникание_в_тему)
ПС - очень хотел бы добавить гимнастику и что-то боевое, но позно раздуплился.. надо было где-то лет в 25ть в это заходить.)
ППС. условно гибкий вандамм мне больше нравится как выглядит в старости, чем надутый шварц. Да, знаю, лицо потяганное, жизнь испаганил веществами.. но ведь после всего пережитого - бодряк, и с ровной осанкой..))
та есть же https://docs.astro.build/en/guides/on-demand-rendering/
Astro?
TL;TR
https://hsto.org/getpro/habr/comment_images/a12/ee4/81d/a12ee481df93e55ef57a90c8533d6868.gif
Лет десять как пью кофе с перекусом один раз в день, посредине дня, где-то 12:00-13:30. Обед у меня в 15:00. Мотивация была - хакнуть день. Т.е. поместить в один день - два дня в плане перформанса. В итоге до сих пор ооочень кайфую от этой одной чашки. И раздупление и фокус буквально приходят сразу только от самого запаха кофе.
ну да, и в темноте - максимальный зрачок 7мм у здорового молодого человека.
Не знал про такие. спасибо. Т.е. реально, чтоб одна приточка надувала квартиру теплым, увлажнённым и свежим воздухом?