Я кстати тоже люблю совковые микрорайоны. Особенно удачно получалось, когда выгоняли какую-нибудь современный бизнесс-жк-свечку внутри такого района, а рядом ещё натыкать не успели; и тот кто там жил - получал лучшее из двух миров: - топ-планировку старого района с зеленью, пространством, садиками, без пробок на въезд\выезд, и т.д. - и топ видовую современную квартиру (если на высоком этаже).
Мой поинт как раз в том, что если присмотреться как застраивали раньше - то можно увидеть приблизительно то правило выше (расстояние == высота), хоть и не осознанное и не везде. Но тем не менее - там где оно соблюдается - там уютно и классно (на подсознании даже).
И это как раз идеальный балланс - и не муравейник-токио (аля 5-й эелемент), и не канадская сабурбия (где чтоб выпить кофе или встретить человека - нужно садится в пикап и ехать к ближайшему моллу).
Так как же на самом деле можно реализовать правило «3-30-300»?
Строить так, чтоб расстояние между зданиями равнялось высоте этих зданий, не меньше! Это коррелирует со всеми проблемами градостроительства (парковки, зелень, пешеходные зоны, вид из окна, и тд.)
Полгода назад я завис над функцией, в которую не мог внести правку.
Так если это аи-функция - то пусть правку и вносит тот кто её создавал (аи). Просто словами описать правку. Нужно относится к аи-коду - как к write-only, и даже не пытаться вникать (ну если она самодостаточная, чистая).. главное чтоб у говно-аи-кода была граница, а то что там внутри говно-код - не так уже и страшно.. сам же аи и разберётся)
На каком объёме промо это сломалось у вас, или ещё работает?
Не, оно не сломалось)
Человек вырос в "специалиста полного цикла закрытия хотелок от маркетинга"..) Баннеры, лендинги, сео-приседания, частичный контент-менеджмент (пускать маретологов во всякие headless cms не удобно, не все хотят), полная поддержка и развитие публичного сайта. Вцелом он уже в реакте варится. Но во все эти "взрослые фронты" специально не хочет залазить. Взрослый, т.е. умеет общаться з бизнесом, и фильтровать\упразднять хотелки маркетологов, не закатывает глаза на многочисленных созвонах "типа - какие тупые менеджеры".)) Пришёл из вордпресса. Пока никакого выгорания. Ему интересно.. потому что находится на стыке разработки и маркетинга. И собой закрывает этот вечный дрифт\трение между этими двумя мирами. По зарплате - синьёр-помидор!) Всё отлично)
Проходил через это. Все эти конструкторы - путь в никуда. Ни одна абсракция не покроет все кейсы маркетологов, и очень быстро треснет. Решение очень простое: нанимаете джуниор-верстальщика в полное рабство подчинение отдела маркетинга. Всё!
Любой if - добавляется быстро, потому что человек тут - под боком, и знает уже эти баннеры вдоль и поперёк, знает маркетологов и их привычки, через время уже знает что выделять в абстракцию, а что копи-пастнуть. На него же можно навесить поддержку всяких ткстов-переводов, новогодних лендингов, и постепенно вводить в условный react/angular на мелкие таски.
Через годик-два - когда он выгорает - можно его уже забирать к себе в команду в "настоящий фронт", а на его место нанимать другого джуниора-верстальщика. Одни плюсы для всех.
Проскроллил, не читал. Дайте угадаю - надо спать, делать зарядку, правильно питаться, отдыхать, быть в окружении любимых людей, выходить общаться, не стрессовать, не тыкаться в телефон. Т.е. жить нормально, полноценно. Может что-то упустил)
Бонусом, для себя ещё раз убедился - что service-worker-ы - зло злейшее.) не отдебажить нормально, ни обновить, ещё и проблемы idempotency добавляют. Максимум для чего годны - для всяких "чисто локальных" приложений (не для распределённых).
было дико видеть, как для игры, явно претендующей на сетевую, нужно передавать чей-то смартфон из рук в руки.
а теперь прежде чем начать играть - нужно сначала каждому установить приложение и войти в него?) как-то приседаний стало больше.. а если не хочется ничего устанавливать?)
Я пока сомневаюсь в этом. Программу "описывает" программист (в голове, на листике, на митингах, 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к+ евро. Правда есть риск, что к телескопу так и не прийдёшь - потому что бинокуляры круче)) а в телескопы действительно лучше смотреть в професиональных обсерваториях.
Я кстати тоже люблю совковые микрорайоны. Особенно удачно получалось, когда выгоняли какую-нибудь современный бизнесс-жк-свечку внутри такого района, а рядом ещё натыкать не успели; и тот кто там жил - получал лучшее из двух миров:
- топ-планировку старого района с зеленью, пространством, садиками, без пробок на въезд\выезд, и т.д.
- и топ видовую современную квартиру (если на высоком этаже).
Мой поинт как раз в том, что если присмотреться как застраивали раньше - то можно увидеть приблизительно то правило выше (расстояние == высота), хоть и не осознанное и не везде. Но тем не менее - там где оно соблюдается - там уютно и классно (на подсознании даже).
И это как раз идеальный балланс - и не муравейник-токио (аля 5-й эелемент), и не канадская сабурбия (где чтоб выпить кофе или встретить человека - нужно садится в пикап и ехать к ближайшему моллу).
Внутри уже застроенных городов - конечно, это по факту будет элитная планировка.
На новых массивах, если правило для всех - то будет обычный процесс ценообразования.
Но да, города будут расти вширь.. не вижу проблемы.. территорий предостаточно вроде ж.)
Конечно же необходимо законодательно ввести эту норму для всех.
А это точно? Даже если браузер открыт постоянно? и даже если расширение "активно" постоянно?
Строить так, чтоб расстояние между зданиями равнялось высоте этих зданий, не меньше! Это коррелирует со всеми проблемами градостроительства (парковки, зелень, пешеходные зоны, вид из окна, и тд.)
Так если это аи-функция - то пусть правку и вносит тот кто её создавал (аи). Просто словами описать правку.
Нужно относится к аи-коду - как к write-only, и даже не пытаться вникать (ну если она самодостаточная, чистая).. главное чтоб у говно-аи-кода была граница, а то что там внутри говно-код - не так уже и страшно.. сам же аи и разберётся)
Не, оно не сломалось)
Человек вырос в "специалиста полного цикла закрытия хотелок от маркетинга"..) Баннеры, лендинги, сео-приседания, частичный контент-менеджмент (пускать маретологов во всякие headless cms не удобно, не все хотят), полная поддержка и развитие публичного сайта.
Вцелом он уже в реакте варится. Но во все эти "взрослые фронты" специально не хочет залазить. Взрослый, т.е. умеет общаться з бизнесом, и фильтровать\упразднять хотелки маркетологов, не закатывает глаза на многочисленных созвонах "типа - какие тупые менеджеры".))
Пришёл из вордпресса. Пока никакого выгорания. Ему интересно.. потому что находится на стыке разработки и маркетинга. И собой закрывает этот вечный дрифт\трение между этими двумя мирами. По зарплате - синьёр-помидор!) Всё отлично)
Проходил через это. Все эти конструкторы - путь в никуда. Ни одна абсракция не покроет все кейсы маркетологов, и очень быстро треснет.
Решение очень простое: нанимаете джуниор-верстальщика в полное
рабствоподчинение отдела маркетинга. Всё!Любой if - добавляется быстро, потому что человек тут - под боком, и знает уже эти баннеры вдоль и поперёк, знает маркетологов и их привычки, через время уже знает что выделять в абстракцию, а что копи-пастнуть. На него же можно навесить поддержку всяких ткстов-переводов, новогодних лендингов, и постепенно вводить в условный react/angular на мелкие таски.
Через годик-два - когда он выгорает - можно его уже забирать к себе в команду в "настоящий фронт", а на его место нанимать другого джуниора-верстальщика. Одни плюсы для всех.
Проскроллил, не читал. Дайте угадаю - надо спать, делать зарядку, правильно питаться, отдыхать, быть в окружении любимых людей, выходить общаться, не стрессовать, не тыкаться в телефон. Т.е. жить нормально, полноценно. Может что-то упустил)
Спасибо за статью.
Бонусом, для себя ещё раз убедился - что service-worker-ы - зло злейшее.) не отдебажить нормально, ни обновить, ещё и проблемы idempotency добавляют.
Максимум для чего годны - для всяких "чисто локальных" приложений (не для распределённых).
а теперь прежде чем начать играть - нужно сначала каждому установить приложение и войти в него?) как-то приседаний стало больше.. а если не хочется ничего устанавливать?)
На любой аспект жизни - по приложению!!)
Не совсем ясно, с этими протоколами file:// или app:// - не будет каких-то проблем, когда захочется прикрутить например webrtc, которому надо https?
Я пока сомневаюсь в этом. Программу "описывает" программист (в голове, на листике, на митингах, etc). И раньше её нужно было ещё и "закодить", да. Теперь, программист также должен "придумать" программу, но закодить может её через аи.
Менеджеры и продакты оперируют бизнес-требованиями и терминами. А прораммист оперирует программными требованиями и терминами, просто кодить ему уже не обязательно.
Мм, хз. Сейчас работа программиста какая? Взять бизнес требования \ таск \ баг (может быть условно в одно предложение - "нам нужен клон Убера, вот в этом месте, чтобы ... бла бла бла"), распутывает клубок зависимостей, подводных камней, комуницирует ещё с несколькими людьми чтобы сложить полный пазл. И только когда сделал всю подготовительную работу (т.е. самое сложное, понял что именно хотят; или понял - что пока они не знают что хотят, но как минимум он программист понял где подстелить соломку, где городить абстракции, а где сделать в лоб, чтоб быстро отдать; понял где общее, а где частное исключение; понял нужно надёжно и пуленепробиваемо, а где нужно быстро) - только тогда продумывает "контракты" на стыках систем, и уже пишет код. Т.е. написание кода - это процентов 20%, и это самое лёгкое. Собственно - то что ИИ и должен делать, типа автокомплит мыслей программиста (чтоб руками не набивать).
И вот ИИ как бы хорош, когда ему на вход даёшь "контракты", которые сам заранее продумал. Если аналитик или менеджер способен дать на вход эти "контракты" - то это программирование и есть (просто грубо - не в иде, а в чате).
А если на входе будет - "нам нужен аналог амазона" - то не знаю - "нет тз - результат хз".)
Теперь я кажется понял и смаппил ваши абстракции на свои.))
У себя я юзаю условно только "компонентные токены". Т.е внутри компонента лежат все стили\ассеты что ему нужны. У него есть дефолтные какие-то состояния. Ну и окружение диктует этому компоненту как ему быть в каждом каком-то исключительном случае (через пропсы или css-переменные).
И если много разных компонентов используют довольно много похожих стилей (т.е. хотя бы 4 компонента с хотя бы 5 строками одинаковых стилей) - то я эти повторяющиеся стили выношу в миксины или классы. Ну а в компоненте уже пишу @include или @extend . В вашей системе - это "семантический слой".
т.е. эти люди должны будут рассказывать ии, например - как провести некую миграцию; или как отрефакторить некий модуль; или в каком месте кодовой базы имплементировать интеграцию с внешним сервисом, и как именно это сделать; или что, когда и в какую ветку коммитить\мерджить; и т.д. Так для этого им нужно будет знать программистсткую терминологию, процессы и экосистему, т.е. быть хотя бы в прошлом программистом. Есть же ш пословица - что-то типа "shit in - shit out".
и второе - а свою основную работу когда они будут делать, если они будут делать работу программистов? Или вы из тех, кто считает текущую работу аналитиков и менеджеров глупой и безполезной?.)
Кто скажет ИИ что именно делать?
А кто задачу опишет?
А само имя примитива blue-500 - не меняется? А если бизнес решит что теперь фирменный синий не чуть светлее, а сильно светлее, или вообще красный - какой порядок действий тогда?
И второй вопрос.
Если взять, что например бренд-колор\акцент-колор\ховер-колор\итд - бизнес не будет менять никогда на уровне всего бизнеса всех продуктов. Зато будут меняться эти значения на уровне исключений в куче разных мест:
- Тут на новый год - хотим вырвеглазно-зелёный хедер, и только в этом продукте. Соответственно кнопки на нём уже будут тоже другие, ну и каскадно цвета текстов нужно поправить.
- А тут во втором продукте - нужна спец кнопка со скидкой, такого цвета ещё не было нигде.
- А тут эта кнопка что-то не очень смотрится с динамической фотографией на фоне, нужно её немножко изменить.
- А тут в тёмной теме, в этом конкретном окружении - переключение темы согласно дизайн системы не подходит, нужно изменить. Т.е. в светлой теме всё ок, а вот в тёмной - фигня.
И это только цвета. А есть ещё отступы, шрифты, скругления какие-нибудь.
Так вот вопрос.. в этом случае, правильно ли я понимаю, что упарываться в дизайн-систему с токенами не имеет смысла, и все стили простом декларируются внутри компонентов? и этого будет достаточно. Максимум все повторяющееся цвета вынести в переменные.
Есть ощущение, что эти всё дизайн-токены и строгие правила дизайн-систем нарушают т.н. "high cohesion low coupling" - и только выкручивают руки, и вся абстракция начинает течь как только в команду приходит новый дизайнер, или начинает создаваться новый продукт, а текущий ui-kit к нему не очень подходит)
Первым телескопом - должен быть бинокль 8х56 хотя бы от 1000 евро (лучше от 1500). Кайфа больше чем от телескопа за 5к+ евро. Правда есть риск, что к телескопу так и не прийдёшь - потому что бинокуляры круче)) а в телескопы действительно лучше смотреть в професиональных обсерваториях.