Не вижу смысла различать senior от middle, да и вообще употреблять эти термины.
Но насвкиду обычно спрашиваю такое: - что ждёшь от новой работы? - почему ищёшь новую работу? скучно на старой? нет челенджей? надоело легаси? меняешь просто каждые пол-года/год чтоб "развиваться"? тренируешь собеседования? Каждое "да" - маркер для меня что не "синьйор" - расскажи, самую интересную, на твой взгляд, проблему которую приходилось решать? - что не любишь делать? (в контексте разработки) - что нравится делать? (в контексте разработки) - почему реакт хороший? - почему реакт плохой? - сколько разрабатывал продакшн-проектов одновременно? Какая была роль? Как спускались задачки? - ну и на всякий случай, парочка тех. вопросов - типа что там по http, ws, sse; как рендерит информацию браузер; как скопировать объект; опиши ивент-луп своими словами, что это вообще? троттлинг и дебаунс - что это за слова? канвас и свг - что лучше? чем отличается веб-воркер от сервис-воркера? что это за html-символы такие, например A
При ответах, если не может двух слов связать в членораздельные предложения.. значит маркер что не "синьйор". И наоборот если "хорошо подвязанный язык", - значит это хороший знак.
Далее кидаем в воду (испыталка), пусть барахтается. Если выплывает, закрывает проблемы, не создаёт дополнительной энтропии как в коде так и в команде, сам в состоянии достать недостающие требования к задаче, умеет общаться с бизнесом и задавать вопросы - значит наш человек. А синьойр он или нет - как-то пофиг, эйчары пусть думают))
Собеседуя senior-разработчиков, для определения уровня их владения инструментами (bundlers, transpilers, post-processors, compilers), я люблю углубляться в вопросы работы webpack.
Так что я собственно знаю про webpack? Выходит, что ничего.
Так зачем терроризировать такими вопросами на собеседованиях? По честному в вакансии тогда нужно указывать "знать вебпак вдоль и поперёк наизусть, потому что это надо непосредственно для работы"
Что плохого в CRA на продакшене? На работе все фронт-приложения (которые за авторизацией) - созданы с помощью CRA. До авторизации - next.js. И есть прямой запрет на создание своего кастомного стартер-конфига без необходимости. Никаких проблем, всё одинаково, одни плюсы. Особенно на долгосроке, и когда проектов много, преимущества чувствуются хорошо.
Поэтому важность тестирования UI при разработке приложений только растёт.
Автоматическое тестирование UI - одно из самых бездарных прожиганий ресурсов (наравне со сжиганием энергии чтоб записать цифры в бд намайнить криптокойны).
Если ко мне, как к владельцу бизнеса, подошли бы и сказали что нужно внедрить "автоматическое тестирование UI" - сразу бы уволил))
Какие есть способы действительно обезопасить себя от гипер-изменчвого мира фронтенда, чтобы не тратить деньги бизнеса на переход на новые библиотеки или фреймворк каждые 3 года?
как вариант - по умолчанию выделять 20% ресурсов разработки на рефакторинг.. на протяжении всего срока жизни проекта, т.е. всегда.
архитектура островов — подразумевается, что в море статичного SSR'd HTML есть острова интерактивности.
Виджеты что-ли?)
помню делали нормальные сайты на симфони с серверными twig-шаблонами, и там где по дизайну было много интерактива - выделял div и рисовал в него реактом на клиенте. При чём за счёт порталов можно делать несколько разных таких div-обёрток, и они могли общаться между собой и знать состояние друг-друга. Оказывается это "архитектура островов"..)))
(CSS color functions) — это способ задания цвета в CSS при помощи математических функций, а не простого кода цвета. Функции обеспечивают больше контроля и гибкости при работе с цветами, используемыми в таблице стилей.
Никак не могу понять "кайфа" этих функций. Какой от них толк? Есть цвета в макете, раз скопировал, загнал в переменные и работаешь себе дальше. Во первых какая разница в каком формате скопировал цвета в код - rgb, hex, whatever? Во вторых - где, на каком этапе, и в каком месте могут понадобится эти функции-хелперы? Я действительно не могу понять. Ну если только не разрабатываете какой-нибудь онлайн подбор палитры.
На старте просишь дизайнера отрисовать только в двух разрешениях - 320px и 1920px.
Всё что между - делаешь на своё усмотрение (!). Без глобальных брейкпоинтов, а индивидуально по каждому компоненту.
Т.е. делаешь, например, хедер - смотришь в отрыве от всего остального контекста как он себя ведёт на разных разрешениях. Нужно чтоб не ломался и небыл кривым. Этого достаточно. Сам принимаешь решение когда именно спрятать\показать гамбургер меню и т.д.. Условно, ты должен мочь копипастнуть компонент в другой проект без проблем. И такой подход по каждому компоненту (Container Queries сейчас по идее очень облегчают жизнь в этом).
Таким образом ты секономишь кучу времени, энергии и нервов и у себя и у дизайнера.
Сдаёшь работу. Вдруг если где-то на каком-то китайском планшете, на каком-то портретном режиме кому-то что-то не нравится.. просто фиксишь конкретно только этот момент и в рамках новой задачи, и то потом когда-то, когда приоритет этой задаче дадут.
И не программируешь в стилях! Никаких много этажных миксинов. Везде используй px (!) по максимуму, а еm - только в местах где явно понятно, что расстояние зависит от соседнего текста и это очевидно, и прописывается в одном блоке правил рядом (паддинги у кнопок, иконок, марджины между параграфами)
Инедайбог использовать rem - как говорят "лучшие практики" - чтобы удовлетворить юзеров, которые вдруг могут менять размер шрифта в браузере. Не знаю ни однорго, кто знает где эта настройка находится. Все используют или pinch-zoom, или ctrl+, или ctrl+mause-whell-up
Подскажите, если есть возможность, ходить на проф гигиену раз в месяц это вредно или полезно?) Буквально относится к этому как к косметической процедуре (стрижка\маникюр\...). Мой стоматолог говорит - что это ок, ничего страшного (есть подозрение что он не совсем искринен))).
Как вам ещё вброс такая поговорка "самый плохой клиентский код - это тот, который написал бекендер"..)
К слову, два раза уже работал в продуктовых компаниях, где основная причина найма была - это осознание руководством того факта, что "фулстекеры" не вывозят требования "продуктовиков\дизайнеров" к визуальной части приложения, и нужен отдельный новый штат чисто фронтов. И действительно, сейчас-то это уже не просто форма на форме, а много разных аспектов клиентского взаимодействия, которыми нужно управлять и нужно держать под контролем.
Иными словами клиентское приложение - находится в более враждебной среде с большим количеством переменных (адаптив, разные тач-устройства, пользователь-рагуль, ресурсы девайса - с одной стороны, апи с другой стороны, и модель данных внутри которая всё это разруливает с третей стороны, которая должна быть консистентна с тем что видит юзер, и с тем состоянием что сейчас на бекенде условно). В бекенде по ощущениям, всё чуть более "прямо" и понятно, главное структуру данных угадать)
Присылайте ваши варианты оптимизации и масштабирования SSR-приложений
Всё что за авторизацией - на отдельный поддомен, чистый client-side rendering, отдельный репозиторий. Как правило там вся настоящая динамика. Туда ставим работать отдельную команду фронт-синьоров-помидоров.
Всё что до авторизации - любой хороший "бекенд-движок" с генерацией шаблонов. Например Symfony. Там же пусть и будет апи жить к первому проекту. Динамика здесь как правило не сильно сложная, джиквери должно хватить. Если не хватает то можно выделить "очень динамичный" div и в него рисовать реактом. Также отдельный репозиторий. И на фронт-twig-шаблоны отдельная недорогая команда\человек с опытом поменьше (aka верстальщик).
Ну да, придётся однаждый два раза сверстать хедер\футер. Невелека проблема, по сравнению с теми что могут быть при ssr на node.
Всё никак не пойму популярность этих reаct-query\swr. Какие-то слишком замудрённые, а рекламируемый профит так себе. Честно пробовал прикрутить к домашнему проекту, плюнул и отказался через час:
- обалдел когда увидел апи и кучу флажков, напрмиер, isFetching, isLoading, isIdle и куча тонкостей какой когда лучше использовать.
- обалдел когда попытался по сабмиту сделать три параллельных запроса, и потом по результату например второго из них нужно сделать\или не сделать четвёртый запрос. Оно меня отправляет в dependent-queries. Код становится какой-то ужасный. Эти все use.. use.. use-ом погоняет.
- самое главное не получается делать запросы вне компонента без use (у меня проект на mobx, поэтому вся логика в сторах, а реакт просто тупой шаблонизатор с чистой читаемой разметкой). Оно конечно предлагает использовать queryClient.fetchQuery,но как я понял теряются многие рекламируемые плюшки.
Всегда интересовало почему популярно удтверждение "хранить токен в localstorage плохо, потому что если xss то ..." Какая ведь разница в localstorage или нет? если УЖЕ есть xss, т.е. уже всё плохо.. как бы на уровень раньше. Уже и неважно где тот токен лежит, т.к. можно наделать что угодно с помощью xss (выдать себе новый токен, ждать пока залогиниться юзер и делать дальше плохие вещи и т.д.).
Мы изначально неправильно выделили микрофронтенды — нужно было брать всю «шапку» целиком, чтобы она стала общей для обоих кейсов
И в этом вся суть прикладного программирования - вовремя угадать когда выделить частное в общее, и наоборот когда разделять общее на частное. На любых уровнях - просто функции в коде, стили, ui-киты, сервисы\модули, микрофронтенды, компоненты инфраструктуры...
Интересно, а маркетологов ли? Никогда не видел чтоб флоу был маркетолог => конструктор => продакшн. Обычно на каком-то этапе всё-равно дёргают разработчика, например - маркетолог => разработчик => конструктор => продакшн. Т.е. пользователь конструтора это и есть разрабы, но никак не дизайнеры\маркетологи, потому что "сложно", проще через человека делегировать.
2. Внутрь кладу свг-файлики иконок и index.js со списком экспортов типа export { ReactComponent as IconCross } from "./cross.svg";
3. Делаю новую фичу. Вижу иконку в макете, если новая - процесс такой: - ручной экспорт из фигмы, - далее руками вставляю в онлайн-svgo, убираю лишние дефолтные цвета заливок и\или обводок - копирую результат и добавляю новую иконку в папку /icons
Всё!
Пункт 3 не очень сложный и активный только на старте проекта, потом предельно редко выполняется, т.к. все нужные иконки уже "в базе" проекта. Также эта ручная корректировка даёт полный контроль над результатом. Если человек на проекте новый и видит "непоняную" иконку в макете - зашёл в папкку /icons - проклацал быстренько - редактор показал превью иконки - и уже понимает есть ли такая иконка в проекте или нет. В любом случае, через небольшое время, любой разработчик уже "насмотрен" и очень быстро понимает новая ли это иконка, или уже есть "в базе" проекта. No big deal.
Зачем автоматизация при загрузке иконок
Для меня непонятно зачем. Возня с переносом иконок из макетов в проект редкая, и каждый раз "особенная". Подымать целый сервис под это, обслуживать его и т.д. ради того что нужно только на старте проекта - нерентабельно. Любой написанный код - это пассив. По идее, автоматизировать нужно то, что нужно на протяжении всей жизни проекта.
Ещё удобнее было бы иметь под рукой витрину всех наших иконок, на которой мы увидеть их все вместе как на ладони.
Чем макет с иконками в фигме - не витрина? зачем дублировать?
который управляется единственным источником правды – макетами дизайнеров
так себе источник истины. Дизайны приходящие\уходящие, постоянно что-то редизайнят и т.д. Доверять можно только своему коду. Макеты - это не истина, это стартовая точка отсчёта, т.е. один из аспектов который желательно бы учитывать. Истину диктует - текущий срез состояния проекта в коде.
Не вижу смысла различать senior от middle, да и вообще употреблять эти термины.
Но насвкиду обычно спрашиваю такое:
- что ждёшь от новой работы?
- почему ищёшь новую работу? скучно на старой? нет челенджей? надоело легаси? меняешь просто каждые пол-года/год чтоб "развиваться"? тренируешь собеседования? Каждое "да" - маркер для меня что не "синьйор"
- расскажи, самую интересную, на твой взгляд, проблему которую приходилось решать?
- что не любишь делать? (в контексте разработки)
- что нравится делать? (в контексте разработки)
- почему реакт хороший?
- почему реакт плохой?
- сколько разрабатывал продакшн-проектов одновременно? Какая была роль? Как спускались задачки?
- ну и на всякий случай, парочка тех. вопросов - типа что там по http, ws, sse; как рендерит информацию браузер; как скопировать объект; опиши ивент-луп своими словами, что это вообще? троттлинг и дебаунс - что это за слова? канвас и свг - что лучше? чем отличается веб-воркер от сервис-воркера? что это за html-символы такие, например
AПри ответах, если не может двух слов связать в членораздельные предложения.. значит маркер что не "синьйор". И наоборот если "хорошо подвязанный язык", - значит это хороший знак.
Далее кидаем в воду (испыталка), пусть барахтается. Если выплывает, закрывает проблемы, не создаёт дополнительной энтропии как в коде так и в команде, сам в состоянии достать недостающие требования к задаче, умеет общаться с бизнесом и задавать вопросы - значит наш человек. А синьойр он или нет - как-то пофиг, эйчары пусть думают))
Так зачем терроризировать такими вопросами на собеседованиях? По честному в вакансии тогда нужно указывать "знать вебпак вдоль и поперёк наизусть, потому что это надо непосредственно для работы"
Какие-то очень пафосные термины)
скорее не Технологй, а инструментов. Не Изучение, а освоение.)
Сколько всё это добро (zod, rhf, resolver) добавит килобайт в код, инетерсно? без gzip.
Что плохого в CRA на продакшене? На работе все фронт-приложения (которые за авторизацией) - созданы с помощью CRA. До авторизации - next.js.
И есть прямой запрет на создание своего кастомного стартер-конфига без необходимости. Никаких проблем, всё одинаково, одни плюсы. Особенно на долгосроке, и когда проектов много, преимущества чувствуются хорошо.
Автоматическое тестирование UI - одно из самых бездарных прожиганий ресурсов (наравне со сжиганием энергии чтоб
записать цифры в бднамайнить криптокойны).Если ко мне, как к владельцу бизнеса, подошли бы и сказали что нужно внедрить "автоматическое тестирование UI" - сразу бы уволил))
как вариант - по умолчанию выделять 20% ресурсов разработки на рефакторинг.. на протяжении всего срока жизни проекта, т.е. всегда.
Виджеты что-ли?)
помню делали нормальные сайты на симфони с серверными twig-шаблонами, и там где по дизайну было много интерактива - выделял div и рисовал в него реактом на клиенте. При чём за счёт порталов можно делать несколько разных таких div-обёрток, и они могли общаться между собой и знать состояние друг-друга.
Оказывается это "архитектура островов"..)))
Если не делать запросы из разметки (view-слоя) как написано
то судя по всему react-query и не нужен вовсе.
Никак не могу понять "кайфа" этих функций. Какой от них толк? Есть цвета в макете, раз скопировал, загнал в переменные и работаешь себе дальше. Во первых какая разница в каком формате скопировал цвета в код - rgb, hex, whatever? Во вторых - где, на каком этапе, и в каком месте могут понадобится эти функции-хелперы? Я действительно не могу понять. Ну если только не разрабатываете какой-нибудь онлайн подбор палитры.
На старте просишь дизайнера отрисовать только в двух разрешениях - 320px и 1920px.
Всё что между - делаешь на своё усмотрение (!). Без глобальных брейкпоинтов, а индивидуально по каждому компоненту.
Т.е. делаешь, например, хедер - смотришь в отрыве от всего остального контекста как он себя ведёт на разных разрешениях. Нужно чтоб не ломался и небыл кривым. Этого достаточно. Сам принимаешь решение когда именно спрятать\показать гамбургер меню и т.д.. Условно, ты должен мочь копипастнуть компонент в другой проект без проблем. И такой подход по каждому компоненту (Container Queries сейчас по идее очень облегчают жизнь в этом).
Таким образом ты секономишь кучу времени, энергии и нервов и у себя и у дизайнера.
Сдаёшь работу. Вдруг если где-то на каком-то китайском планшете, на каком-то портретном режиме кому-то что-то не нравится.. просто фиксишь конкретно только этот момент и в рамках новой задачи, и то потом когда-то, когда приоритет этой задаче дадут.
И не программируешь в стилях! Никаких много этажных миксинов. Везде используй px (!) по максимуму, а еm - только в местах где явно понятно, что расстояние зависит от соседнего текста и это очевидно, и прописывается в одном блоке правил рядом (паддинги у кнопок, иконок, марджины между параграфами)
Инедайбог использовать rem - как говорят "лучшие практики" - чтобы удовлетворить юзеров, которые вдруг могут менять размер шрифта в браузере. Не знаю ни однорго, кто знает где эта настройка находится. Все используют или pinch-zoom, или ctrl+, или ctrl+mause-whell-up
Подскажите, если есть возможность, ходить на проф гигиену раз в месяц это вредно или полезно?) Буквально относится к этому как к косметической процедуре (стрижка\маникюр\...). Мой стоматолог говорит - что это ок, ничего страшного (есть подозрение что он не совсем искринен))).
Интересно какие есть полезные serverless-приложения для широкого круга пользователей, кроме фото\видео\аудио\текстовых редакторов и игр?.)
Как вам ещё
вбростакая поговорка "самый плохой клиентский код - это тот, который написал бекендер"..)К слову, два раза уже работал в продуктовых компаниях, где основная причина найма была - это осознание руководством того факта, что "фулстекеры" не вывозят требования "продуктовиков\дизайнеров" к визуальной части приложения, и нужен отдельный новый штат чисто фронтов.
И действительно, сейчас-то это уже не просто форма на форме, а много разных аспектов клиентского взаимодействия, которыми нужно управлять и нужно держать под контролем.
Иными словами клиентское приложение - находится в более враждебной среде с большим количеством переменных (адаптив, разные тач-устройства, пользователь-рагуль, ресурсы девайса - с одной стороны, апи с другой стороны, и модель данных внутри которая всё это разруливает с третей стороны, которая должна быть консистентна с тем что видит юзер, и с тем состоянием что сейчас на бекенде условно). В бекенде по ощущениям, всё чуть более "прямо" и понятно, главное структуру данных угадать)
Всё что за авторизацией - на отдельный поддомен, чистый client-side rendering, отдельный репозиторий. Как правило там вся настоящая динамика. Туда ставим работать отдельную команду фронт-синьоров-помидоров.
Всё что до авторизации - любой хороший "бекенд-движок" с генерацией шаблонов. Например Symfony. Там же пусть и будет апи жить к первому проекту. Динамика здесь как правило не сильно сложная, джиквери должно хватить. Если не хватает то можно выделить "очень динамичный" div и в него рисовать реактом. Также отдельный репозиторий. И на фронт-twig-шаблоны отдельная недорогая команда\человек с опытом поменьше (aka верстальщик).
Ну да, придётся однаждый два раза сверстать хедер\футер. Невелека проблема, по сравнению с теми что могут быть при ssr на node.
Всё никак не пойму популярность этих reаct-query\swr. Какие-то слишком замудрённые, а рекламируемый профит так себе. Честно пробовал прикрутить к домашнему проекту, плюнул и отказался через час:
- обалдел когда увидел апи и кучу флажков, напрмиер, isFetching, isLoading, isIdle и куча тонкостей какой когда лучше использовать.
- обалдел когда попытался по сабмиту сделать три параллельных запроса, и потом по результату например второго из них нужно сделать\или не сделать четвёртый запрос. Оно меня отправляет в dependent-queries. Код становится какой-то ужасный. Эти все use.. use.. use-ом погоняет.
- самое главное не получается делать запросы вне компонента без use (у меня проект на mobx, поэтому вся логика в сторах, а реакт просто тупой шаблонизатор с чистой читаемой разметкой). Оно конечно предлагает использовать queryClient.fetchQuery,но как я понял теряются многие рекламируемые плюшки.
Может всё-таки мало времени уделил.
Всегда интересовало почему популярно удтверждение "хранить токен в localstorage плохо, потому что если xss то ..."
Какая ведь разница в localstorage или нет? если УЖЕ есть xss, т.е. уже всё плохо.. как бы на уровень раньше. Уже и неважно где тот токен лежит, т.к. можно наделать что угодно с помощью xss (выдать себе новый токен, ждать пока залогиниться юзер и делать дальше плохие вещи и т.д.).
И в этом вся суть прикладного программирования - вовремя угадать когда выделить частное в общее, и наоборот когда разделять общее на частное. На любых уровнях - просто функции в коде, стили, ui-киты, сервисы\модули, микрофронтенды, компоненты инфраструктуры...
Интересно, а маркетологов ли? Никогда не видел чтоб флоу был маркетолог => конструктор => продакшн. Обычно на каком-то этапе всё-равно дёргают разработчика, например - маркетолог => разработчик => конструктор => продакшн. Т.е. пользователь конструтора это и есть разрабы, но никак не дизайнеры\маркетологи, потому что "сложно", проще через человека делегировать.
у меня какое-то внутреннее противоречие возникло
Мой вариант "автоматизации" иконок:
1. Создал папку /icons
2. Внутрь кладу свг-файлики иконок и index.js со списком экспортов типа
export { ReactComponent as IconCross } from "./cross.svg";3. Делаю новую фичу. Вижу иконку в макете, если новая - процесс такой:
- ручной экспорт из фигмы,
- далее руками вставляю в онлайн-svgo, убираю лишние дефолтные цвета заливок и\или обводок
- копирую результат и добавляю новую иконку в папку /icons
Всё!
Пункт 3 не очень сложный и активный только на старте проекта, потом предельно редко выполняется, т.к. все нужные иконки уже "в базе" проекта. Также эта ручная корректировка даёт полный контроль над результатом.
Если человек на проекте новый и видит "непоняную" иконку в макете - зашёл в папкку /icons - проклацал быстренько - редактор показал превью иконки - и уже понимает есть ли такая иконка в проекте или нет.
В любом случае, через небольшое время, любой разработчик уже "насмотрен" и очень быстро понимает новая ли это иконка, или уже есть "в базе" проекта. No big deal.
Для меня непонятно зачем. Возня с переносом иконок из макетов в проект редкая, и каждый раз "особенная". Подымать целый сервис под это, обслуживать его и т.д. ради того что нужно только на старте проекта - нерентабельно. Любой написанный код - это пассив. По идее, автоматизировать нужно то, что нужно на протяжении всей жизни проекта.
Чем макет с иконками в фигме - не витрина? зачем дублировать?
так себе источник истины. Дизайны приходящие\уходящие, постоянно что-то редизайнят и т.д. Доверять можно только своему коду. Макеты - это не истина, это стартовая точка отсчёта, т.е. один из аспектов который желательно бы учитывать. Истину диктует - текущий срез состояния проекта в коде.