Комментарии 173
Senior в современном мире и без angular/react/vue? Очень странно.
Для верстальщика достаточно понимания того, как работает шаблонизатор в представленных фреймворках. Если бы это бы frontend-разработчик, то, как минимум, знать и понимать их бы требовалось.
Ну не знаю. Всё-таки компонентная парадигма, она требует чуть более глубокого изучения вопроса и конкретного фреймворка/библиотеки. И ладно бы это я, фулстек разработчик, так думал. Но нет, вот недавно встречался с бывшей сотрудницей-верстальщицей. На новом месте активное изучение React именно в контексте вёрстки. Никакой разработкой с её стороны и не пахнет.
Да и jQuery у вас на схеме упомянут, а у него связей с вёрсткой на порядок меньше, чем у упомянутых мною фреймворков и библиотек.
P.S. За статью, в любом случае, спасибо. Как минимум заставляет задуматься над вопросом структуирования необходимых навыков для определённой области разработки.
Да и jQuery у вас на схеме упомянут, а у него связей с вёрсткой на порядок меньше, чем у упомянутых мною фреймворков и библиотек.
P.S. За статью, в любом случае, спасибо. Как минимум заставляет задуматься над вопросом структуирования необходимых навыков для определённой области разработки.
Схему можно бесконечно долго расширять.
Я постарался выделить тот минимум, который является базой, и без которого прям очень сложно.
Можно изучать реакт, и прийти в проект где этого реакта нет. Но да, изучение ЛЮБОГО фреймворка улучшит понимание и процесс разработки. Я намеренно выделил «Шаблонизаторы» в отдельный пункт. Сюда можно было бы добавить и реакт, и ангуляр, и любые другие фреймворки со своей структурой.
Тем не менее уметь делать шаблоны и разрабатывать на фреймворке требует совершенно разных навыков и разного понимания.
Я постарался выделить тот минимум, который является базой, и без которого прям очень сложно.
Можно изучать реакт, и прийти в проект где этого реакта нет. Но да, изучение ЛЮБОГО фреймворка улучшит понимание и процесс разработки. Я намеренно выделил «Шаблонизаторы» в отдельный пункт. Сюда можно было бы добавить и реакт, и ангуляр, и любые другие фреймворки со своей структурой.
Тем не менее уметь делать шаблоны и разрабатывать на фреймворке требует совершенно разных навыков и разного понимания.
У реакта нет шаблонизатора. Верстальщик должен понимать сам реакт, что бы написать код компонента.
Для ангуляра, вуя и всех современных фреймворков отдельно верстать шаблоны — это лишний геморой.
Как у вас выстроен этот процесс? Верстальщик тратит 30 часов на один компонент, а потом фронтендер берет его код, тратит еще 30 часов, разбивает его до неузноваемости навешивая туда логику? Как потом верстальщик исправляет косяки верстки в итоговом результате, лезет в код приложения и навешивает заплатки в css?
Для ангуляра, вуя и всех современных фреймворков отдельно верстать шаблоны — это лишний геморой.
Как у вас выстроен этот процесс? Верстальщик тратит 30 часов на один компонент, а потом фронтендер берет его код, тратит еще 30 часов, разбивает его до неузноваемости навешивая туда логику? Как потом верстальщик исправляет косяки верстки в итоговом результате, лезет в код приложения и навешивает заплатки в css?
Ну таки JSX можно назвать шаблонизатором в каком-то виде.
Даже читые ${} в js можно назвать шаблонизированием, в целом.
Ангуляр, вуй и прочие вполне (иногда) имеют отдельные обособленные HTML участки. Да, с дополнительной логикой типа {#each} или дополнительными аттрибутами тегов, или вообще с собственными тегами-директивами. При понимании того, как работают блоки в целом и начилии базового понимания JS, да и уж с минимальным изучением конкретного фреймворка, у верстальщика не составляет проблем сразу делать как надо.
Если вопрос конкретно про наш проект, то у нас blaze. Можно сказать что Handlebars. Он достаточно прост. Обработчики можно вешать как извне так и добавляя onClick={{someAction}} или подобное. При наличии прочих навыков изучается за день.
Даже читые ${} в js можно назвать шаблонизированием, в целом.
Ангуляр, вуй и прочие вполне (иногда) имеют отдельные обособленные HTML участки. Да, с дополнительной логикой типа {#each} или дополнительными аттрибутами тегов, или вообще с собственными тегами-директивами. При понимании того, как работают блоки в целом и начилии базового понимания JS, да и уж с минимальным изучением конкретного фреймворка, у верстальщика не составляет проблем сразу делать как надо.
Если вопрос конкретно про наш проект, то у нас blaze. Можно сказать что Handlebars. Он достаточно прост. Обработчики можно вешать как извне так и добавляя onClick={{someAction}} или подобное. При наличии прочих навыков изучается за день.
Ну таки JSX можно назвать шаблонизатором в каком-то виде.
Не думаю, что у тех кто понимает что такое JSX, повернется язык назвать это шаблонизатором в каком-то виде.
Даже читые ${} в js можно назвать шаблонизированием, в целом.
так это и называется шаблонные строки
При понимании того, как работают блоки в целом и начилии базового понимания JS, да и уж с минимальным изучением конкретного фреймворка, у верстальщика не составляет проблем сразу делать как надо.
Так в итоге это верстальщик или уже фронтендер? Зачем пускать туда человека, который имеет базовые знания и может делать только какую-то малую часть(возможно даже криво и неэффективно), в итоге же может получится так, что опытному разработчику придется все переделывать за верстальщиком с нуля. Двойная работа на лицо.
У вас в проекте, если меняется логика в приложении, или набор данных который надо визулизировать становится другим, кто правит шаблон, верстальщик или фронтендер, или у вас нет фронтендеров и все делает сеньор верстальщик? Не получается ли у так, что верстальщик говорит что его код работает, а после добавления логики все сломалось и это не его косяк? Как вы определяете кого наказывать, а кого поощрять?
Так в итоге это верстальщик или уже фронтендер?
Верстальщик :-)
Я не разрабатывал приложения конкретно на реакте, могу сказать за ангуляр. Хороший верстальщик может (как бы не было странно) хорошо сверстать. Далеко не каждый фронтендер умеет хорошо верстать — это факт. Если предоставляются данные в шаблон, то верстальщик вполне сможет их вставить как надо, используя простейшую логику.
Полноценная проработка компонентов требует иных компетенций, нежели качественная вёрстка.
У нас сейчас фуллстеки все.
верстальщик говорит что его код работает, а после добавления логики все сломалось и это не его косяк?
Честно говоря слабо представляю как может сломаться вёрстка после добавления логики. Если она, таки, ломается, то это явно проблема фронтендера, в данном контекте.
Вёрстка же может делаться (и делается, зачастую) на моках, а не на реальных данных.
Окей, убедили, в схему нужно добавить умение создавать моки под задачи.
Как вы определяете кого наказывать, а кого поощрять?
Я обязательно напишу отдельную статью про кучу ошибок которые совершил, как руководитель, за последние 3 года разработки своего проекта и чему научился. :-)
Никак не могу понять, как идет разделение на верстальщика для фреймворка и разработчика на фреймворке. Интересно было бы почитать про весь процесс такой разработки на каком-нибудь примере. Я видел вакансии по типу верстальщик реакт, ангуляр но никак не мог понять в чем выгода такого разделения?
Сеньор верстальщик сверстал макет по мокам и протестил его, но он не учел, что реальные данные там окажутся куда больше чем в моках, и, например, появился скролл, в результате чего поехала верстка. Выявили косяки в других браузерах, на других разрешениях(как бы не тестил сеньор верстальщик — это неизбежно).
Это кстати справедливо не только для фонт фреймворков, но так же эта проблема актуальна для различных CMS и бекенд фреймворков
Честно говоря слабо представляю как может сломаться вёрстка после добавления логики
Сеньор верстальщик сверстал макет по мокам и протестил его, но он не учел, что реальные данные там окажутся куда больше чем в моках, и, например, появился скролл, в результате чего поехала верстка. Выявили косяки в других браузерах, на других разрешениях(как бы не тестил сеньор верстальщик — это неизбежно).
Это кстати справедливо не только для фонт фреймворков, но так же эта проблема актуальна для различных CMS и бекенд фреймворков
Выгода от разделения в том, что гораздо проще нанять крутого верстальщика и крутого фронтендера, чем крутого фуллстека (обычно отдельные навыки слабее чем у пары узких спецов).
Ну тут… не учел… а ты учти :-) Важна регулярность таких ошибок. Вообще, ошибки — это нормально, важно как они разрешаются. Ну т.е. вот вылезет проблема у верстальщика что он не учел что-то — поправит и учтёт в следующей работе. Процесс обучения важен, как-никак. Ну и при взаимодействии с разработчиками научится лучше понимать ваш движок.
Ну тут… не учел… а ты учти :-) Важна регулярность таких ошибок. Вообще, ошибки — это нормально, важно как они разрешаются. Ну т.е. вот вылезет проблема у верстальщика что он не учел что-то — поправит и учтёт в следующей работе. Процесс обучения важен, как-никак. Ну и при взаимодействии с разработчиками научится лучше понимать ваш движок.
К примеру вёрстка разломается когда её в Ангулар разобьют по компонентам т.к. вставляться будет уже через дополнительный тег <xxx-component></xxx-component> — как минимум нужно установить каким этот будет блок, блок, инлайн, флекс и т.д. + наследование css может заблудиться т.д.
Так верстальщик Ангулар я понять вполне могу, когда после простой вёрстки — фронтендер разбивал её на компоненты и всё ползло в разные стороны.
Так верстальщик Ангулар я понять вполне могу, когда после простой вёрстки — фронтендер разбивал её на компоненты и всё ползло в разные стороны.
Senior — верстальщик? Всегда думал что верстальщик это зародыш фронтенд разработчика. А тут вон как оказывается!
Жутко субъективная статья. Почему к примеру Джуниору сразу не вникнуть в Бутстрап (и иже с ними)? Что в этом сложного для него? Позабавило упоминание почему-то Вордпресса после 100 работ (на картинке) — раньше нельзя?) И без него тоже никак? В силу излишней субъективности как пособие я бы не стал рекомендовать этот материал
1. Да, субъективная. Об этом даже говорил. Не субъективно это не решить никак.
2. Можно сразу вникнуть в бутстрап. Даже сразу его использовать. Но при необходимости доработки за пределами бутстрапа могут возникнуть проблемы. Бутстрап, таки, это частный случай. Каждый сам для себя выбирает что изучать.
3. Вордпресс можно и раньше, а можно и без него (он помечен как опциональный на схеме и в тексте). И не после 100, а после 50. Числа эти могут быть так же другими (о чем есть в тексте).
Буду рад увидеть какую-либо схему с разделением по градациям не являющуюся субъективной. Спасибо.
2. Можно сразу вникнуть в бутстрап. Даже сразу его использовать. Но при необходимости доработки за пределами бутстрапа могут возникнуть проблемы. Бутстрап, таки, это частный случай. Каждый сам для себя выбирает что изучать.
3. Вордпресс можно и раньше, а можно и без него (он помечен как опциональный на схеме и в тексте). И не после 100, а после 50. Числа эти могут быть так же другими (о чем есть в тексте).
Буду рад увидеть какую-либо схему с разделением по градациям не являющуюся субъективной. Спасибо.
Почему приведён только один способ именования БЭМ? Это не стандарт де-факто.
БЭМ только для синьора и то опционально? Окееей
Поделитесь, как видите картину вы.
Скажу честно, для верстака может быть и да, однако соглашусь с dom1n1k — сомнительно.
БЭМ — это минимум из методологий которые должен «знать» джун, и хотя бы полноценно ей владеть. А с мидла уже начинать понимать что это не высеченные на камне заветы, и не стоит как прилежный ученик юзать их символ в символ как в книжке.
Мидл — это старшекурсник гильдии творцов. Он и сетку сам наколдует, и префиксные заклятия наложит и зарисует это в своей css-книжке словом что джун поймет, да и сеньор похвалит)
Если грубо, БЭМ — это некая основа как типа знать три кита ООП. Он показывает как должно быть, но нигде в больших проектах нет чистой БЭМ.
БЭМ — это минимум из методологий которые должен «знать» джун, и хотя бы полноценно ей владеть. А с мидла уже начинать понимать что это не высеченные на камне заветы, и не стоит как прилежный ученик юзать их символ в символ как в книжке.
Мидл — это старшекурсник гильдии творцов. Он и сетку сам наколдует, и префиксные заклятия наложит и зарисует это в своей css-книжке словом что джун поймет, да и сеньор похвалит)
Если грубо, БЭМ — это некая основа как типа знать три кита ООП. Он показывает как должно быть, но нигде в больших проектах нет чистой БЭМ.
Тут есть разница в требованиях. Я по этому свои требования и описал в начале статьи.
Я раньше тоже от джунов требовал БЭМ. Как начал нанимать людей, понял что картина совершенно иная. И то понимание БЭМ у новичков ценности не имеет практически.
В целом для новичка довольно хорошим результатом является осознанно называть классы, а не .topLeftBlock
Так же добавил блок upd. в статью. Делая, например, лендинги для разных компаний, БЭМ не нужен и даже вреден, т.к. нет переиспользования компонентов.
Я раньше тоже от джунов требовал БЭМ. Как начал нанимать людей, понял что картина совершенно иная. И то понимание БЭМ у новичков ценности не имеет практически.
В целом для новичка довольно хорошим результатом является осознанно называть классы, а не .topLeftBlock
Так же добавил блок upd. в статью. Делая, например, лендинги для разных компаний, БЭМ не нужен и даже вреден, т.к. нет переиспользования компонентов.
Все верно, здесь в статье больше придирки к проф уровням. Просто «задаунгрейдь» требования к методологиям хотя бы до мидлов, а вместо них, чтоб не пустовало место скиллов для сеньоров, добавь паттерны проектирования)
Я для мидлов добавил OOCSS. Как по мне так это довольно крутая и более универсальная методология, нежели БЭМ. Во всяком случае оно лучше применимо на маленьких и средних проектах.
Паттерны проектирования… это уже не для верстальщиков. Я добавил DRY, KISS, SOLID, т.к. изучая их в каком-то виде можно лучше компоновать блоки, но что-то прям такое серьёзное должен делать не верстальщик уже.
Паттерны проектирования… это уже не для верстальщиков. Я добавил DRY, KISS, SOLID, т.к. изучая их в каком-то виде можно лучше компоновать блоки, но что-то прям такое серьёзное должен делать не верстальщик уже.
И то понимание БЭМ у новичков ценности не имеет практически.
В целом для новичка довольно хорошим результатом является осознанно называть классы, а не .topLeftBlock
Мне кажется у вас в статье просто нет четкого обозначения понятия «верстальщик».
Если воспринимать это как совсем отдельную профессию, то сомневаюсь что кому-то будут действительно нужны джуниоры и возможно даже мидлы которых вы описали. Разве что в качестве бесплатных стажеров (иначе могут просто мешать, т.к. придется им все объяснять и возможно даже переделывать после их «работы»)
Знакомые недавно как-раз искали «чистого» верстальщика на проект (single-page app, Angular2). Градации на джунов и т.д. там не было, но основные требование к кандидату были примерно такие:
— HTML5/CSS3, Mobile-first/Responsive, Transitions/Animations, Flexbox
— LESS/SASS (куда без них сейчас в более-менее крупных проектах)
— знание Ангуляра или Реакта (разумеется только на уровне необходимом для верстки)
— гит/гитхаб
— знание всех основных инструментов для фронта: npm/gulp/webpacк и т.д.
— предпочтительно: — знание основ работы с юниксом
— предпочтительно: — опыт с Д3
Под эти требования даже описанный вами сениор может не подойти. А что будет делать на работе ваш джуниор — мне вообще трудно представить, честно говоря.
Кроме того, мне кажется у вас есть несколько 'немного устаревших' пунктов. Например, jQeury и Wordpress с каждым днем становятся все менее востребованы, стоит ли тратить время на их изучение? Возможно лучше потратить его на более глубокое изучения основ HTML/CSS/JS
PS Кстати, если кому-то в спб нужна сейчас работа верстальщика (согласно требованиям описанным выше) — пишите в личку.
Wordpress конечно же не обязателен, а вот jQuery — очень даже. Но только если речь идет о создании сайтов, на которых не используются какие-либо фреймворки.
Почему же? В начале есть описание чего может верстальщик того или иного уровня.
Ну и я не говорил что это обязательно отдельный человек.
jQuery есть в каждом втором проекте. По Wordpress'у настолько нет работ, что всего 8871 открытых вакансий на апворке с тегом wordpress.
Для понимания — по реакту 1307.
На самом деле это разного рода работы, надо понимать, но игнорировать реальный пулл вакансий несколько странно.
Ну и я не говорил что это обязательно отдельный человек.
jQuery есть в каждом втором проекте. По Wordpress'у настолько нет работ, что всего 8871 открытых вакансий на апворке с тегом wordpress.
Для понимания — по реакту 1307.
На самом деле это разного рода работы, надо понимать, но игнорировать реальный пулл вакансий несколько странно.
На самом деле это разного рода работы, надо понимать, но игнорировать реальный пулл вакансий несколько странно.
Ну тогда скажите на какую работу вы бы наняли «дхуниора» из вашего списка? (за 20000р/мес как вы ниже предлагаете)
По Wordpress'у настолько нет работ, что всего 8871 открытых вакансий на апворке с тегом wordpress.
Для понимания — по реакту 1307.
Посмотрите графу `Est. Budget` в ваших списках и увидите что соотношение прямо противоположное.
С апворком не работал, честно говоря, насколько я понимаю — это биржа для фрилансеров. Я думал что речь скорее про работу в офисе / на зарплате.
На headhunter'е:
wordpress — 106 hh.ru/search/vacancy?text=wordpress&area=1
react — 507 hh.ru/search/vacancy?text=react&area=1
Опять же, полностью противоположная ситуация.
Я считаю время Wordpress и jQuery уходит, как возможно и отдельная специальность «верстальщик». Бизнесу так удобнее (посмотрите сколько вакансий на `fullstack`)
Плюс многие люди сами хотят развиваться дальше во фронтенд и не задерживаются надолго в «чистой» верстке.
Вёрстка/доправление простых макетов на потоке.
Покупается готовый готовый макет на любой площадке, доправляется таким верстальщиком, заполняется инфой и продается клиенту.
Есть компании которые делают это на потоке. Их достаточно.
Скучность и монотонность мы тут не обсуждаем.
Est. Budget — ну так опять же, это единоразовые небольшие работы. А реакт разработчики и прочие — постоянная работа над одним проектом. Фрилансер на небольших работах таких вполне может набирать до 3к$/месяц. Я лично знаю таких.
На хедхантере ищут в офис, да, поэтому и картина другая.
Wordpress — отличное решение для рядового сайта. Продаёт, например, друг леденцы ручной работы и просит вас сделать сайт. Взял вордпресс, взял тему, к вечеру сайт готов. Можно взять любую другую популярную CMS. На хостинг загрузил и готово (сравните с приложениями на ноде, хостингов «для обычных пользователей» до сих пор нет адекватных).
Вакансий фуллстек много, реальных фуллстеков кот наплакал. Говорю как реальный фуллстек :-) Приходится нанимать по старинке бекендеров/фронтендеров.
Ну т.е. фуллстек таки может уметь всё, но, например, на бекенде делает 10 единиц работы в час, а на фронте 2 единицы в час. Можно ему давать все задачи, а можно взять фронтендера с перекосом 10 на фронте, 2 на беке. И получить в сумме 20/час, а не 12.
Покупается готовый готовый макет на любой площадке, доправляется таким верстальщиком, заполняется инфой и продается клиенту.
Есть компании которые делают это на потоке. Их достаточно.
Скучность и монотонность мы тут не обсуждаем.
Est. Budget — ну так опять же, это единоразовые небольшие работы. А реакт разработчики и прочие — постоянная работа над одним проектом. Фрилансер на небольших работах таких вполне может набирать до 3к$/месяц. Я лично знаю таких.
На хедхантере ищут в офис, да, поэтому и картина другая.
Wordpress — отличное решение для рядового сайта. Продаёт, например, друг леденцы ручной работы и просит вас сделать сайт. Взял вордпресс, взял тему, к вечеру сайт готов. Можно взять любую другую популярную CMS. На хостинг загрузил и готово (сравните с приложениями на ноде, хостингов «для обычных пользователей» до сих пор нет адекватных).
Вакансий фуллстек много, реальных фуллстеков кот наплакал. Говорю как реальный фуллстек :-) Приходится нанимать по старинке бекендеров/фронтендеров.
Ну т.е. фуллстек таки может уметь всё, но, например, на бекенде делает 10 единиц работы в час, а на фронте 2 единицы в час. Можно ему давать все задачи, а можно взять фронтендера с перекосом 10 на фронте, 2 на беке. И получить в сумме 20/час, а не 12.
Мне в целом ваши мысли понятны, но немного сбивает с толку сама градация на джуниор/мидл/сениор.
Почему джуниору не начать сразу с распространенных практик в современной разработке (BEM, mobile-first, ..)?
Почему сениор ведет непосредственно к вордпрессу, а например не к углублению в ангуляр/реакт (компоненты, и т.п.)?
Довольно субъективная схема получилась в общем.
Почему джуниору не начать сразу с распространенных практик в современной разработке (BEM, mobile-first, ..)?
Почему сениор ведет непосредственно к вордпрессу, а например не к углублению в ангуляр/реакт (компоненты, и т.п.)?
Довольно субъективная схема получилась в общем.
1. Я в начале описал ожидания от верстальщика
2. Распространённые практики СЛОЖНЫ. Серьёзно. Вам может казаться что взял и готово, всё просто. Но это не так. Они требуют много знаний и понимания чего ты делаешь. Для их использования УЖЕ нужен опыт. Это точно не для начинающих.
3. Вордпресс это лишь пример. Ну и почему воддпресс я ответил прям в предыдущем сообщении.
4. Схема субъективна, это факт. Объективной схемы никто никогда не сделает :-)
2. Распространённые практики СЛОЖНЫ. Серьёзно. Вам может казаться что взял и готово, всё просто. Но это не так. Они требуют много знаний и понимания чего ты делаешь. Для их использования УЖЕ нужен опыт. Это точно не для начинающих.
3. Вордпресс это лишь пример. Ну и почему воддпресс я ответил прям в предыдущем сообщении.
4. Схема субъективна, это факт. Объективной схемы никто никогда не сделает :-)
БЭМ на сегодня — стандарт де-факто (хотя выше и возражают), поэтому как минимум знакомым с ним должен быть абсолютно любой верстальщик.
Что касается реального применения, тут вопрос несколько более спорный, хотя лично я считаю это вариантом по умолчанию. То есть применять иные методологии можно, но для этого нужно иметь какие-то особые причины и/или специфику проекта; если таковых нет — не выделывайся, используй бэм :) Это правда хорошая практика.
Что касается реального применения, тут вопрос несколько более спорный, хотя лично я считаю это вариантом по умолчанию. То есть применять иные методологии можно, но для этого нужно иметь какие-то особые причины и/или специфику проекта; если таковых нет — не выделывайся, используй бэм :) Это правда хорошая практика.
Простите, где это сейчас БЭМ «стандарт де-факто»?
Я много фронтов повидал, но только в СНГ встречал «разработчиков на БЭМе» (именно в ковычках излишне фанатичных). Много зарубежных фронтов часто даже не слышали про БЭМ.
P.S. Очень интересное наблюдение: я не встречал зарубежных верстальщиков.
Я много фронтов повидал, но только в СНГ встречал «разработчиков на БЭМе» (именно в ковычках излишне фанатичных). Много зарубежных фронтов часто даже не слышали про БЭМ.
P.S. Очень интересное наблюдение: я не встречал зарубежных верстальщиков.
По опыту хочу сказать что очень не хватает квалифицированных верстальщиков даже в крупных популярных проектах.
Сами верстальщики таки встречаются, но тут зависит от специфики вашей работы.
На хабре много людей работают в высокотехнологичных компаниях, но есть много и гораздо более простых задач.
Сами верстальщики таки встречаются, но тут зависит от специфики вашей работы.
На хабре много людей работают в высокотехнологичных компаниях, но есть много и гораздо более простых задач.
Поправлю: часто можно наблюдать картину, что у команд крупных проектов не хватает квалификации в верстке.
Не хватает именно скилла в верстке у фронтов, а не хорошего верстальщика.
Верстальщик — это вакансия еще более специфичная чем дизайнер. Я часто вижу дизайнеров, которые умеют не только в фотошоп, но и в HTML+CSS. Так же часто вижу фронтов, которые не могут понять как отделить понятие верстки от их работы. Но только у нас в СНГ я встречаю верстальщиков, которые не могут писать код и дизайнеров, которые умеют исключительно рисовать.
Так что рекомендую вам начать изучать путь фронтендера — их очень не хватает, и не только у нас :)
Не хватает именно скилла в верстке у фронтов, а не хорошего верстальщика.
Верстальщик — это вакансия еще более специфичная чем дизайнер. Я часто вижу дизайнеров, которые умеют не только в фотошоп, но и в HTML+CSS. Так же часто вижу фронтов, которые не могут понять как отделить понятие верстки от их работы. Но только у нас в СНГ я встречаю верстальщиков, которые не могут писать код и дизайнеров, которые умеют исключительно рисовать.
Так что рекомендую вам начать изучать путь фронтендера — их очень не хватает, и не только у нас :)
Да, хорошее замечание, не хватает скила в верстке, абсолютно верно.
Хотя под словом «верстальщик» я подразумеваю не обязательно отдельного человека, но и того кто эти задачи выполняет в принципе.
Лично, я, если что, считаю себя software engineer'ом, а не верстальщиком. Это можно увидеть по другим моим статьям :-)
Хотя под словом «верстальщик» я подразумеваю не обязательно отдельного человека, но и того кто эти задачи выполняет в принципе.
Лично, я, если что, считаю себя software engineer'ом, а не верстальщиком. Это можно увидеть по другим моим статьям :-)
Каюсь, не смотрел профиль.
Просто статью я понял немного своеобразно. Ведь для фронта логично испльзование IDE, а в статье это отдельный скилл верстальщика. При этом я не утверждаю, что фронту обязательно знать различные фреймворки — нужно знать язык и различные паттерны (вот интересная статья на эту тему habrahabr.ru/post/253297 ).
Просто статью я понял немного своеобразно. Ведь для фронта логично испльзование IDE, а в статье это отдельный скилл верстальщика. При этом я не утверждаю, что фронту обязательно знать различные фреймворки — нужно знать язык и различные паттерны (вот интересная статья на эту тему habrahabr.ru/post/253297 ).
Хороший результат — в смысле большая карта получилась. Но сильно искаженный масштаб. Именно верстку надо расскрывать подробней, а тут подробней расскрыто неспецифичное client-side программирование. И в смысле количества подробностей и даже геометрически в центр поставлена переферия.
Поясните, пожалуйста, что имеется ввиду под «подробным» раскрытием вёрстки?
Мне видится это как набор множества связанных навыков, которые я и отразил в карте.
Прописывать карту тегов или чего-то такого… это не имеет смысла. Это справочная информация, которую не обязательно держать всегда в голове.
Может быть не совсем понял посыл.
Мне видится это как набор множества связанных навыков, которые я и отразил в карте.
Прописывать карту тегов или чего-то такого… это не имеет смысла. Это справочная информация, которую не обязательно держать всегда в голове.
Может быть не совсем понял посыл.
Вы описываете то что у вас в голове (даже с семантическими связями), и вдруг «в голове держать не надо».
Под раскрытием верстки понимаю именно что приемы верстки, т.е. перелопачивания работы дизайнеров в ХТМЛ. Чтобы их привести — надо их обдумать, сформулировать «чтобы не было просто карты тегов», предложить названия, сгруппировать, отсортировать по сложности — большая работа на самом деле (которая не проделана, хотя сразу этого можно и не понять смотря на масштабы карты).
Не задумывалось? Но вы названием статьи предложили меру которой хотите чтобы было оценено содержание.
Под раскрытием верстки понимаю именно что приемы верстки, т.е. перелопачивания работы дизайнеров в ХТМЛ. Чтобы их привести — надо их обдумать, сформулировать «чтобы не было просто карты тегов», предложить названия, сгруппировать, отсортировать по сложности — большая работа на самом деле (которая не проделана, хотя сразу этого можно и не понять смотря на масштабы карты).
Не задумывалось? Но вы названием статьи предложили меру которой хотите чтобы было оценено содержание.
Хм, ну умение выбрать нужный тег, скажем, я включил в блок «Семантика».
Умение разбивать сайт на блоки в «Блочную верстку».
Что бы оно ещё тянулось прям круто во «flexbox».
Далее мобильная и адаптив.
Я всё ещё не очень понимаю о каких техниках идёт речь.
Умение разбивать сайт на блоки в «Блочную верстку».
Что бы оно ещё тянулось прям круто во «flexbox».
Далее мобильная и адаптив.
Я всё ещё не очень понимаю о каких техниках идёт речь.
Чтобы небыть голословным очевидными примерами приема верстки является понимание и умение пользоваться
1) «col» bootstrap'а ломающиеся от media-type.
2) умение стилизировать jquery plugin'ы
3) умение залезть в Chrome debugger и подгонять стили wyswig
и т.д
4) умение пользоваться тулзами которые загружают картинку и потом выдают названия шрифтов, цвета, гардиенты
5) умения задать вопрос дизайнеру (список вопросов которые можно задавать дизайнеру)
6) тоже программеру
список конечно не звучит — потому что необдумано и сформулировано плохо. и главное он не закончен, ведь система становится «приятной» когда она система, а не ее черновик.
я почему бурчу, сделайте эту работу — большое дело будет. интерес есть.
1) «col» bootstrap'а ломающиеся от media-type.
2) умение стилизировать jquery plugin'ы
3) умение залезть в Chrome debugger и подгонять стили wyswig
и т.д
4) умение пользоваться тулзами которые загружают картинку и потом выдают названия шрифтов, цвета, гардиенты
5) умения задать вопрос дизайнеру (список вопросов которые можно задавать дизайнеру)
6) тоже программеру
список конечно не звучит — потому что необдумано и сформулировано плохо. и главное он не закончен, ведь система становится «приятной» когда она система, а не ее черновик.
я почему бурчу, сделайте эту работу — большое дело будет. интерес есть.
Хм, ну 1 я не счтиаю прям отдельным навыком. Это прям специфический момент с бутстрапом, который я опциональным ставил.
Стилизовать jquery плагины — ну как бы если с CSS и HTML разобрался, то… ну это же не отдельный навык. Почему именно jquery? Можно было бы записать как работу с чужим кодом, это да.
Chrome debugger, включено в джуниоре в инструментах разработчика.
Про тулзы: ну тут специфично. Я конечно назвал одну, CanIUse, но прочие — спорный вопрос на выбор. Шрифты, зачастую, есть в макетах или можно спросить у дизайнера и т.п.
Про вопросы — круто. Вот это можно было бы прям в отдельный пункт, но надо подумать как и куда.
Стилизовать jquery плагины — ну как бы если с CSS и HTML разобрался, то… ну это же не отдельный навык. Почему именно jquery? Можно было бы записать как работу с чужим кодом, это да.
Chrome debugger, включено в джуниоре в инструментах разработчика.
Про тулзы: ну тут специфично. Я конечно назвал одну, CanIUse, но прочие — спорный вопрос на выбор. Шрифты, зачастую, есть в макетах или можно спросить у дизайнера и т.п.
Про вопросы — круто. Вот это можно было бы прям в отдельный пункт, но надо подумать как и куда.
Вашу схему можно назвать «Кого бы мы хотели назвать верстальщиком, чтобы платить ему меньше.»
Верстальщик со знанием PHP и Wordpress уже не совсем верстальщик. Я бы даже сказал, что совсем уже не верстальщик. Аналогично и JS. Верстальщик не обязан знать JS. Верстка подразумевает цепочку действий от принятия макета до создания страницы для отображения в браузере. Статической страницы без какой-либо интерактивной части, максимум рекция на ховеры и анимация при появлении. Потом эту страницу берет Фронт-энд на пару с бэк-энд и цепляют туда логику, интерактив и тд.
Верстальщик со знанием PHP и Wordpress уже не совсем верстальщик. Я бы даже сказал, что совсем уже не верстальщик. Аналогично и JS. Верстальщик не обязан знать JS. Верстка подразумевает цепочку действий от принятия макета до создания страницы для отображения в браузере. Статической страницы без какой-либо интерактивной части, максимум рекция на ховеры и анимация при появлении. Потом эту страницу берет Фронт-энд на пару с бэк-энд и цепляют туда логику, интерактив и тд.
Не совсем так. Более того, я убеждён что реально квалифицированный верстальщик в крупном проекте должен получать не меньше фронтендера.
PHP, JS и прочее на данной схеме я ставил на уровне «ознакомпления». Для того же вордпреса — есть разница в том что бы сделать свой шаблон и написать свой интерактивный модуль.
Про интерактив тоже не было речи. Как выше упоминал, процесс вижу при разработке с шаблонизаторами, в использовании моков (тестовых данных), либо в предоставлении условий (остается сделать только HTML, может с минимальными вставками {{переменных}}) со стороны фронтендера.
PHP, JS и прочее на данной схеме я ставил на уровне «ознакомпления». Для того же вордпреса — есть разница в том что бы сделать свой шаблон и написать свой интерактивный модуль.
Про интерактив тоже не было речи. Как выше упоминал, процесс вижу при разработке с шаблонизаторами, в использовании моков (тестовых данных), либо в предоставлении условий (остается сделать только HTML, может с минимальными вставками {{переменных}}) со стороны фронтендера.
На определённом уровне неплохо бы иметь представление о том как происходит процесс рендеринга страницы (DOM, CSSOM, Render Tree).
Если уж выносить верстку в отдельную профессию, то сеньор верстки должен знать вообще все про способы оптимизации, про рендеринг в разных браузерах, их различия. А всякие методологии стоит учить еще будучи джуниором. И уж точно БЭМ не делает из человека сеньора.
Но вообще, это наверно дико скучно только верстать сайты. Наверно даже только фронт-эндом заниматься надоедает. Но тут уж каждый сам за себя решает.
Но вообще, это наверно дико скучно только верстать сайты. Наверно даже только фронт-эндом заниматься надоедает. Но тут уж каждый сам за себя решает.
Ну так то верстальщики и встречаются как отдельная профессия, либо в составе фронтенд-специалистов (которые не всегда умеют в вёрстку).
Само собой БЭМ не делает из человека серьора. Даже изучение всей карты не делает. Сеньор это способ мышления и умение решать и ставить задачи. В целом по градации было в начале стати.
Касательно того скучно или нет — лично мне нравится вёрстка. В крупных проектах довольно много интересных и не таких простых задач. Даже БЭМ сам по себе не даст все ответы. Простой вопрос: какой zIndex ставить для «блокирующей» области? А для попапа?
Само собой БЭМ не делает из человека серьора. Даже изучение всей карты не делает. Сеньор это способ мышления и умение решать и ставить задачи. В целом по градации было в начале стати.
Касательно того скучно или нет — лично мне нравится вёрстка. В крупных проектах довольно много интересных и не таких простых задач. Даже БЭМ сам по себе не даст все ответы. Простой вопрос: какой zIndex ставить для «блокирующей» области? А для попапа?
Очень бы хотелось узнать за что ставится такое количество минусов.
Оставьте отзывы, пожалуйста, чем так плоха статья.
Спасибо.
Оставьте отзывы, пожалуйста, чем так плоха статья.
Спасибо.
Очень много спорного, можно дискутировать практически по каждому пункту, но начинание хорошее.
Из самого странного — в 2018-м году разносить по-отдельности CSS 1, CSS 2.1 и CSS 3, при чем CSS3 не раньше миддла, ват? Да и препроцессоры наверное уже можно ставить джунам по дефолту. Там же — есть stylus, но нет LESS, зачем вы его обижаете, он же клевый и популярнее стайлуса. А вот инструменты разработчиков браузера я бы расширил ниже — там очень много продвинутых инструментов, о которых даже не все сениоры знают и применяют.
В комментариях выше промелькнула мысль, что даже продвинутые фронтендеры довольно часто оказываются посредственными верстальщиками. Могу это только подтвердить — найти хорошего верстальщика нынче — крайне сложно, ведь все ударились в js.
У меня есть лайфхак — если хочется на собеседовании завалить сениора верстальщика/фронтендера (обычно не хочется, но мало ли), достаточно задать ему/ей три вопроса: о техниках оптимизации производительности, о доступности и о секьюрити клиентской части.
Ладно, скипнем секьюрность, но про accessibility я не увидел у вас пунктов.
Кстати, разметку AMP и ему подобные желательно верстакам уже знать хотя бы в общих чертах.
Из самого странного — в 2018-м году разносить по-отдельности CSS 1, CSS 2.1 и CSS 3, при чем CSS3 не раньше миддла, ват? Да и препроцессоры наверное уже можно ставить джунам по дефолту. Там же — есть stylus, но нет LESS, зачем вы его обижаете, он же клевый и популярнее стайлуса. А вот инструменты разработчиков браузера я бы расширил ниже — там очень много продвинутых инструментов, о которых даже не все сениоры знают и применяют.
В комментариях выше промелькнула мысль, что даже продвинутые фронтендеры довольно часто оказываются посредственными верстальщиками. Могу это только подтвердить — найти хорошего верстальщика нынче — крайне сложно, ведь все ударились в js.
У меня есть лайфхак — если хочется на собеседовании завалить сениора верстальщика/фронтендера (обычно не хочется, но мало ли), достаточно задать ему/ей три вопроса: о техниках оптимизации производительности, о доступности и о секьюрити клиентской части.
Ладно, скипнем секьюрность, но про accessibility я не увидел у вас пунктов.
Кстати, разметку AMP и ему подобные желательно верстакам уже знать хотя бы в общих чертах.
Стандарты CSS наслаиваются друг на друга. В самом посте, в принципе, описано что включено в общих чертах. Ну т.е. изучая CSS 3 ты так или иначе изучишь CSS 2 и CSS 1.
Ну и так то по дефолту можно было бы вообще это всё джунам поставить, только так не бывает :-)
Про LESS было в тексте, например. Тут было важнее показать два лагеря — в одном CSS работает после переноса, а в другом его всегда надо переписывать.
Про инструменты разработчика — да, тут стоит расписать подробнее. Хотя их можно рассматривать в разделе «оптимизация» с ветками.
Про accessibility очень хорошее замечание. Многие забывают про доработки для людей с ограниченными возможностями. Стоит его добавить. Но, пожалуй, на уровень сеньёра, т.к., всё же, в большинстве случаев, это меньшая часть аудитории. Я старался покрывать схемой так, что бы минимум навыков давало максимум результата в плане покрытия.
Про AMP не писал, потому что, к своему стыду, первый раз слышу про эту технологию. Почитаю, спасибо.
Ну и так то по дефолту можно было бы вообще это всё джунам поставить, только так не бывает :-)
Про LESS было в тексте, например. Тут было важнее показать два лагеря — в одном CSS работает после переноса, а в другом его всегда надо переписывать.
Про инструменты разработчика — да, тут стоит расписать подробнее. Хотя их можно рассматривать в разделе «оптимизация» с ветками.
Про accessibility очень хорошее замечание. Многие забывают про доработки для людей с ограниченными возможностями. Стоит его добавить. Но, пожалуй, на уровень сеньёра, т.к., всё же, в большинстве случаев, это меньшая часть аудитории. Я старался покрывать схемой так, что бы минимум навыков давало максимум результата в плане покрытия.
Про AMP не писал, потому что, к своему стыду, первый раз слышу про эту технологию. Почитаю, спасибо.
НЛО прилетело и опубликовало эту надпись здесь
В том числе и про них. Также, есть нюансы с третьесторонними ресурсами, node_modules, индексацией не того, что нужно и все в таком духе. Интернет нынче крайне дырявый, и никто почему-то не чешется по этому поводу. Кстати, неплохая свежая статья на эту тему
Вы раскрываете свое виденье, но вопрос, сами берете таких джунов? Сколько их у вас и сколько им платите?
Что-то мне подсказывает, что если студия не работает над большими проектами, то не могут брать человека "который может внести правки", а возьмут того, кто умеет все от и до, пусть и слабо понимает какой-нибудь Git, особенно с учётом того, что маленькие проекты — это скорость разработки важнее возможности поддержки в будущем.
В общем, минусы за странности в статье, плюсы — за старания и поднятие темы.
Лично у меня нет задач для джунов.
По оплате, если по данным скилам, то условно бы разделил как 20/50/100 тысяч для РФ.
Далеко не всем нужны супер навороченные адаптивные сайты.
Для многих рядовых задач может хватит навыков начинающего специалиста.
Я видел много студий, делающих лендинги на потоке за 10 000р/штука. Там такие начинающие и трудятся, делая по 3 штуки в день (без шуток), за тысяч 30 в месяц.
Это довольно утомительная и скучная работа, однако может быть вполне неплохой для наработки базового опыта.
По оплате, если по данным скилам, то условно бы разделил как 20/50/100 тысяч для РФ.
Далеко не всем нужны супер навороченные адаптивные сайты.
Для многих рядовых задач может хватит навыков начинающего специалиста.
Я видел много студий, делающих лендинги на потоке за 10 000р/штука. Там такие начинающие и трудятся, делая по 3 штуки в день (без шуток), за тысяч 30 в месяц.
Это довольно утомительная и скучная работа, однако может быть вполне неплохой для наработки базового опыта.
Посмотрел Ваш проект consulwar.ru. Впервые в жизни вижу, чтобы фотографии с отзывами использовались адекватно и реально вызывали доверие ))))
На самом деле профессия «верстальщик» — это печальный удел.
Такое узкое самоназвание: «верстальщик», — должно определять человека на конвейерную работу — сверстал страницу, сверстал дргую — сдал проект, взял новый. Это рентабельно только если поток проектов — от 2 штук в месяц на 1 верстальщика.
Если верстальщик делает 2 проекта в месяц — значит он работает в коллективе, который сдаёт по 2 проекта в месяц. Это либо с первого раза сделанные как надо и не развивающиеся проекты (сомнительно), или сделал-забыл проекты с соответствующим отношением.
В реально живущем долго проекте места для чисто-верстальщика — нету, надо развиваться.
Прямой руководитель верстальщика будет от него требовать развития во front-части, пусть даже в ущерб его навыкам в вёрстке. Причина простая — проще ставить задачи на более высоком уровне.
А хороший-хороший фронт — должен любить по-верстать.
И в целом на проектах с нормальным жизненным циклом — дешевле дать хорошему-хорошему фронту сверстать проект. Это для него может оказаться отдыхом.
Такое узкое самоназвание: «верстальщик», — должно определять человека на конвейерную работу — сверстал страницу, сверстал дргую — сдал проект, взял новый. Это рентабельно только если поток проектов — от 2 штук в месяц на 1 верстальщика.
Если верстальщик делает 2 проекта в месяц — значит он работает в коллективе, который сдаёт по 2 проекта в месяц. Это либо с первого раза сделанные как надо и не развивающиеся проекты (сомнительно), или сделал-забыл проекты с соответствующим отношением.
В реально живущем долго проекте места для чисто-верстальщика — нету, надо развиваться.
Прямой руководитель верстальщика будет от него требовать развития во front-части, пусть даже в ущерб его навыкам в вёрстке. Причина простая — проще ставить задачи на более высоком уровне.
А хороший-хороший фронт — должен любить по-верстать.
И в целом на проектах с нормальным жизненным циклом — дешевле дать хорошему-хорошему фронту сверстать проект. Это для него может оказаться отдыхом.
NDA не позволяет мне рассказать деталей, но я не согласен.
Верстальщик — соврешенно не значит конвеерную работу. Крупные проекты имеют сотни экранов, которые более менее регулярно обновляются и так далее. Зачастую не хватает человека, который бы координировал визуальные изменения по нескольким командам.
Тут можно спорить сколько угодно, но всегда есть две стороны монеты. Есть потоковая работа, о которой вы сказали, она вполне подходит для джунов/мидлов. На хай левеле есть много более интересных задач.
Верстальщик — соврешенно не значит конвеерную работу. Крупные проекты имеют сотни экранов, которые более менее регулярно обновляются и так далее. Зачастую не хватает человека, который бы координировал визуальные изменения по нескольким командам.
Тут можно спорить сколько угодно, но всегда есть две стороны монеты. Есть потоковая работа, о которой вы сказали, она вполне подходит для джунов/мидлов. На хай левеле есть много более интересных задач.
НЛО прилетело и опубликовало эту надпись здесь
Спасибо.
Касательно устаревшести не соглашусь. Grunt и Gulp таки вполне используются. Вебпак настраивать ощутимо сложнее. Особенно как обучающий элемент некоей автоматизации вполне заходит.
Насчёт PHP — сейчас такая гора PHP проектов что игнорировать его, при всём желании, глупо. Мне самому не нравится PHP, если что, но считать что он умер (или умрёт ближайшие лет 10) не стоит.
Atomic Design таки уже привязывается к конкретным инструментам и выходит несколько за пределы чистой вёрстки. Но рассмотреть, хотя бы для понимания, подобные инструменты точно стоит.
Репейнт/рефлоу тут в разделе оптимизации отрисовки. Я намеренно не стал расписывать на много параметров, т.к. их всё равно надо изучать скопом.
Дёргать API с помощью jQuery умеют многие. Разбираться что там именно REST или что-то иное, на самом деле, не обязательно. Особенно если бек спроектирован грамотно и удобно. В случае ошибок легко поправить.
Касательно устаревшести не соглашусь. Grunt и Gulp таки вполне используются. Вебпак настраивать ощутимо сложнее. Особенно как обучающий элемент некоей автоматизации вполне заходит.
Насчёт PHP — сейчас такая гора PHP проектов что игнорировать его, при всём желании, глупо. Мне самому не нравится PHP, если что, но считать что он умер (или умрёт ближайшие лет 10) не стоит.
Atomic Design таки уже привязывается к конкретным инструментам и выходит несколько за пределы чистой вёрстки. Но рассмотреть, хотя бы для понимания, подобные инструменты точно стоит.
Репейнт/рефлоу тут в разделе оптимизации отрисовки. Я намеренно не стал расписывать на много параметров, т.к. их всё равно надо изучать скопом.
Дёргать API с помощью jQuery умеют многие. Разбираться что там именно REST или что-то иное, на самом деле, не обязательно. Особенно если бек спроектирован грамотно и удобно. В случае ошибок легко поправить.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А зачем axios? Просто чтоб не использовать jQuery (читай не тянуть огромную библиотеку чтоб "дергать api с помощью jQuery")? А если его и так и так нужно изучать — какой смысл? Он тоже возвращает промисы. Fetch ок, конечно, но IE (как и старым андроидом) он таки не поддерживается. А полифилл тут — опять же, jQuery.
Конечно, лучше уметь использовать стандартные методы, меньше, быстрее, только тру и т.д., но ведь речь про верстальщика.
Сеньор верстальщик? Не слышал такого ранее.
SOLID
В верске?
Gitflow
Только для сеньора?
Вот и я не слышал. Но чего бы не обозначить градации? Ведь не так всё очевидно.
SOLID вполне хорошо в проектирование компонентов ложится. Особенно если решите свой CSS фреймворк делать.
Gitflow полноценный ниже сеньёра не нужен. Процесс организует тимлид или СТО или ещё кто. Главное уметь коммитить, создавать ветки и так далее. Взаимодействовать с командой, в общем. А полноценно понимать что, зачем и как — уже ближе к руководящим позициям.
SOLID вполне хорошо в проектирование компонентов ложится. Особенно если решите свой CSS фреймворк делать.
Gitflow полноценный ниже сеньёра не нужен. Процесс организует тимлид или СТО или ещё кто. Главное уметь коммитить, создавать ветки и так далее. Взаимодействовать с командой, в общем. А полноценно понимать что, зачем и как — уже ближе к руководящим позициям.
НЛО прилетело и опубликовало эту надпись здесь
(это редактор)vsc < — ide -> webstorm || (это библиотека) jQ <-js->nodejs
Посмотрел только на это, хотя ещё notepad видел в 2018… График показывает как новичок представляет себе карьерную лестницу?
Посмотрел только на это, хотя ещё notepad видел в 2018… График показывает как новичок представляет себе карьерную лестницу?
Офигеть, оказывается я не джун, а на 90% сеньор… только чет на работу не берут.
Спасибо огромное за ориентир. буду стараться достичь хотя бы джуна)
Много сообщений о том, что верстальщик без знания фреймворка не нужен. В основном это пишут разработчики в крупных проектах. И, для них, это вполне так. Но есть ещё много студий делающих лендинги, различные шаблоны для вордпресов и других CMS. Это вполне себе хороший рынок и возможность зарабатывать. Есть довольно много совершенно небольших проектов, с гораздо меньшими требованиями, которые верстальщик способен закрыть на отлично.
Здесь нужно понимать, что:
1) Фреймворки — это по большей части именно SPA, и в мире Wordpress/CMS и лендингов SPA действительно чаще всего до сих пор невостребованы.
2) Если я правильно понял, то вы решаете разделить верстальщиков как таковых и фронтендеров (я лично рассматривал свою бытность верстальщиком как ступень к фронтенду, ибо писать логику приложения — это другой уровень), и вставляете в свою систему градаций верстальщиков еще и количество работ — но ведь как мы знаем количество очень часто может быть не равно качеству.
3) То «проектирование компонентов» о котором вы говорите, если я правильно понял то оно имеет прямое отношение к дизайн-системам, а потому и к дизайну как таковому, но почему-то в вашем списке нет пункта, в котором синьёр-помидор должен уметь в UI и гораздо важнее в UX.
2. Не совсем так.
Во-первых это точно не «уровень к фронтенду». Я встречал крутейших фронтентеров не умеющих верстать (точнее с совсем базовыми навыками).
Фактически это разные навыки.
Про качество работ писал в самой статье и выше в комментариях. Можно изучить всё, и быть бесполезным, само собой.
Числа добавил исключительно для ориентации в пространстве.
3. UI/UX, всё же, это отдельные области. Посмотреть десяток макетов и выделить повторяющиеся элементы, грамотно их спроектировать (что бы не дублировались), довольно непросто. Это примерно как сделать свой bootstrap. Ну т.е. это вроде не то что бы сложно, но на рынке реально продуманных систем единицы. Иметь «свой бутстрап» в крупном проекте, с хорошей документацией и продуманой системой компонентов — одно удовольствие для дальнейшей разработки.
Во-первых это точно не «уровень к фронтенду». Я встречал крутейших фронтентеров не умеющих верстать (точнее с совсем базовыми навыками).
Фактически это разные навыки.
Про качество работ писал в самой статье и выше в комментариях. Можно изучить всё, и быть бесполезным, само собой.
Числа добавил исключительно для ориентации в пространстве.
3. UI/UX, всё же, это отдельные области. Посмотреть десяток макетов и выделить повторяющиеся элементы, грамотно их спроектировать (что бы не дублировались), довольно непросто. Это примерно как сделать свой bootstrap. Ну т.е. это вроде не то что бы сложно, но на рынке реально продуманных систем единицы. Иметь «свой бутстрап» в крупном проекте, с хорошей документацией и продуманой системой компонентов — одно удовольствие для дальнейшей разработки.
Чем же UI/UX «это отдельные области»? Не с UI ли вы работаете, верстая странички? Не UX ли лежит в основе всего того, что делают верстальщики и фронтендеры?
Кроме того, вы же не будете писать «свой бутстрап» не зная как и что должно работать?
Дизайнера тоже в сторонку поставим, пускай смотрит? :)
Кроме того, вы же не будете писать «свой бутстрап» не зная как и что должно работать?
Дизайнера тоже в сторонку поставим, пускай смотрит? :)
UI/UX это область дизайнера, по большей части.
В моем понимании задачей верстальщика является перевести картинку в рабочую штуку, но никак не давать советы по тому как эту картинку лучше сделать.
Само собой, с наработкой опыта глаз намётывается и навыки дизайнера в той или иной мере перенимаются.
В моем понимании задачей верстальщика является перевести картинку в рабочую штуку, но никак не давать советы по тому как эту картинку лучше сделать.
Само собой, с наработкой опыта глаз намётывается и навыки дизайнера в той или иной мере перенимаются.
Всё так, вот только UX это не про картинку, на самом деле.
UX про сбор данных, AB тесты и прочее.
Однако релевантным опытом, что бы «попасть» сразу в хорошее обычно обладают дизайнеры.
Однако релевантным опытом, что бы «попасть» сразу в хорошее обычно обладают дизайнеры.
Вижу вы не очень понимаете, о чем на самом деле UX.
Он не про данные, а про пользовательский опыт (что на самом деле и означает «User Experience»).
Сбор данных — он в свою очередь для аналитики. A/B — тоже для аналитики, которая уже в свою очередь может повлиять на предоставляемый пользователю UX.
Имхо, опять же, но ни о каком seniority в верстке не может идти речь, пока человек не отличает плохой UX от хорошего (о в целом не знает что такое UX).
Он не про данные, а про пользовательский опыт (что на самом деле и означает «User Experience»).
Сбор данных — он в свою очередь для аналитики. A/B — тоже для аналитики, которая уже в свою очередь может повлиять на предоставляемый пользователю UX.
Имхо, опять же, но ни о каком seniority в верстке не может идти речь, пока человек не отличает плохой UX от хорошего (о в целом не знает что такое UX).
Я понимаю более чем.
И почему же? :-)
Если предоставляется спека с подробной инфой что и как должно работать. Зачем этот навык верстальщику? :-) Ну т.е. он реально из другой плоскости прям.
Имхо, опять же, но ни о каком seniority в верстке не может идти речь, пока человек не отличает плохой UX от хорошего (о в целом не знает что такое UX).
И почему же? :-)
Если предоставляется спека с подробной инфой что и как должно работать. Зачем этот навык верстальщику? :-) Ну т.е. он реально из другой плоскости прям.
В моем случае, то самое «seniority» о котором я говорю — это более широкое понятие, которое включает в себя и широту познания еще и смежных, взаимодополняющих вёрстку областей. Я снова приведу в пример тот же самый UX, которой у вас в списке не значится :)
«Seniority» — это не только о технических навыках, я вот о чем. Еще один пример — навык эстимирования\оценки задач. Но вы о нем кажется тоже не упоминаете.
«Seniority» — это не только о технических навыках, я вот о чем. Еще один пример — навык эстимирования\оценки задач. Но вы о нем кажется тоже не упоминаете.
Планирование — научиться оценивать сроки по картинке и определять последовательность работ.
Это касательно «не упоминается»
UX не идёт в смежные ни верстальщику, ни фронтендеру, ни, даже, фуллстеку. Это навык из СОВЕРШЕННО другой области, которая решается совсем иными путями и имеет абсолютно другой путь изучения.
UI про картинку. а UX это про то как это должно работать и как им будут пользоваться. А это, в свою очередь, должно ложиться в саму основу основ картинки. Всякие там эффекты и обратная связь добавляемые верстальщиком — это не особенно и UX.
Чем же эффекты «не особенно UX»? Добавим плохой эффект в неправильное место — и получим плохой UX.
Например если пихать везде где нам вздумается анимации — это может вводить в заблуждение и отвлекать пользователя.
Например если пихать везде где нам вздумается анимации — это может вводить в заблуждение и отвлекать пользователя.
Эм. Испортить можно что угодно в каком угодно месте. Но улучшить UX хорошим эффектом там где он (UX) плохой в самом дизайне — навряд ли исправит ситуацию.
Например если пихать везде где нам вздумается анимации — это может вводить в заблуждение и отвлекать пользователя.
Так а кто по вашему должен об этом думать? Верстальщик?
Хороший дизайн — это не только картинка. Это и описание поведения в том числе, чем и занимается UX дизайнер.
Потому что какие эффекты и куда решает дизайнер, а не верстальщик.
Senior не должен быть слепым орудием, он должен осознавать что он делает, и стараться сделать лучше, аргументированно объяснив причину того или иного решения, его плюсы и минусы.
Поэтому когда верстальщик видит, что предложенное решение дизайнера может навредить пользовательскому опыту — он должен, опять же, объяснить всем, как можно сделать лучше.
Поэтому когда верстальщик видит, что предложенное решение дизайнера может навредить пользовательскому опыту — он должен, опять же, объяснить всем, как можно сделать лучше.
На схеме блок WordPress у сеньора расположен — удивился. Посмотрел в тексте, раньше должен быть)
Довольно занятная статейка, хотя и оценивание верстальщика по шкале выполненных работ… это сложно для моего понимания. Чистые верстальщики сейчас никому не нужны. без минимальных знаний JS. (Как минимум переделать готовый слайдер он должен уметь) + из статьи не понятно как оценить уровень, когда ты перешел из одной категории в другую. Я бы оценивал работы верстальщиков по кросбраузерности завершенной работы + Goggle PageSpeed. ПС Пишу как человек который сам проводил собеседование по найму Junior разрабтчика
Оценивать по Google PageSpeed не корректно прям совсем, честно говоря. Он далеко не всегда показывает правду и надо к таким вещам относится с осторожностью.
Так же оценивать работу верстальщика по оптимизации (там много разных механик) — это такое себе.
Так же оценивать работу верстальщика по оптимизации (там много разных механик) — это такое себе.
Это почему же Google PageSpeed вам не показатель? Если работа максимально кроссбраузерная, содержит нормы HTML 5 CSS3, валидатор на ней не краснеет + она не содержит ничего лишнего, (имеет минимальное количество запросов к сторонним сервисам и они выполняются именно тогда когда надо). И при этом PageSpeed тесты показывают >90%. Как по мне это показатель
Это зависит от специфики вашей работы.
Может быть для вас это действительно идеальный показатель, тут я был не прав, выходит.
Может быть для вас это действительно идеальный показатель, тут я был не прав, выходит.
Потому что будет ругаться за свои же компоненты карту шрифты метрику. А советы типо с начало верстку, а шрифты стили и скрипты потом подходят тока для коротких страниц, а других всё видно как прыгает.
Умение оптимизировать под гугл спид это полезный навык.
А можно подробнее про запросы, какие именно запросы, когда выполняются?
А можно подробнее про запросы, какие именно запросы, когда выполняются?
В статье очень недооценен джуниор. Описание больше подходит для трейни.
И получается что джуны начинают себя мнить мидлами.
И получается что джуны начинают себя мнить мидлами.
Добрый вечер.
zav Алексанр (автор поста), мне очень понравился ваш пост, спасибо.
Если у тебя будет желание учесть все комментарии и дополнить/изменить таблицу/пост, добавив всё новое и переосмысленное в схему и в дополнительный абзац после статьи, это будет превосходно, потому что схема получилась годной и если её можно ещё улучшить учитывая отзывы других опытных людей… это будет Вау. Пишу как человек, который повидал много схем и уроков.
zav Алексанр (автор поста), мне очень понравился ваш пост, спасибо.
Если у тебя будет желание учесть все комментарии и дополнить/изменить таблицу/пост, добавив всё новое и переосмысленное в схему и в дополнительный абзац после статьи, это будет превосходно, потому что схема получилась годной и если её можно ещё улучшить учитывая отзывы других опытных людей… это будет Вау. Пишу как человек, который повидал много схем и уроков.
Хорошая статья, а вместе с «инфографикой» еще лучше, как раз для новичков)
А есть ли еще статьи/материалы по веб программированию или по другим направлениям?
А есть ли еще статьи/материалы по веб программированию или по другим направлениям?
ну, проблема нехватки специалистов, она в-принципе в направлении ИТ. Не то, чтобы именно верстальщиков мало. Многим просто верстка кажется не интересной. И потом, в образовательных учреждениях никогда не будут преподавать верстку, и рассказывать, как это классно. + многие ИТшники пренебрежительно относятся к верстальщикам, поэтому мало, кто хочет этим заниматься.
Планирую составить аналогичные карты для frontend и backend разработчиков. Потом объединить все карты в fullstack.
Если, вдруг, кто желает помочь составить адекватную карту и поделиться своим видением — присоединяйтесь к телеграмм каналу https://t.me/zav_programming
Если, вдруг, кто желает помочь составить адекватную карту и поделиться своим видением — присоединяйтесь к телеграмм каналу https://t.me/zav_programming
Автору вопрос.
Вы в комментариях очень много пишете о том, что фронтенд — плохой верстальщик. А можно как-то конкретнее это объяснить? Мне всегда казалось, что фронтенд — это очередная и логичная ступень развития верстальщика, сначала делается сайт, потом на него накладывается логика и динамика. А фронтенд по определению должен хорошо верстать. Мне понятно, что программирование не всем дано и это определённый склад мышления, который есть не у каждого. Но вёрстка то — чисто механическая работа, по определённым правилам расставить блоки с текстом и изображениями на странице. Тем более, что в вашей картинке сначала идёт одна статика для десктопов.
Что в верстке может вызвать такое затруднение, что программист точно не справится? Не сумеет правильно расставить теги? Выберет не те? Не разведет блоки по разным сторонам макета или не сможет построить сетку? Что именно может вызывать и вызывает проблемы у программистов в верстке? Теги, правильный выбор селекторов или набор свойств?
Тогда уж — а что именно вызывает проблемы у верстальщика с небольшим опытом в верстке сайтов? Если судить по вашим словам — эти проблемы должны быть аналогичны тем, что возникают у программистов. Ведь не может быть, что одно только знание ехнологии — продвигает специалиста вперёд. Есть же и особенности применения технологий, одни правильные, другие нет. И разве этому можно научиться только по книжкам, в которых, например, рассказывается про свойства css?
У меня не много опыта в верстке и программировании, и очень интересно, не что именно надо изучать, а как. Потому что подробных карт — множество, реально дофига. Те же самые курсы html academy — можно открыть список и все примерно совпадет, за исключением того, что они не углубляются в более продвинутые технологии на курсах — для этого у них есть интенсивы.
Вы в комментариях очень много пишете о том, что фронтенд — плохой верстальщик. А можно как-то конкретнее это объяснить? Мне всегда казалось, что фронтенд — это очередная и логичная ступень развития верстальщика, сначала делается сайт, потом на него накладывается логика и динамика. А фронтенд по определению должен хорошо верстать. Мне понятно, что программирование не всем дано и это определённый склад мышления, который есть не у каждого. Но вёрстка то — чисто механическая работа, по определённым правилам расставить блоки с текстом и изображениями на странице. Тем более, что в вашей картинке сначала идёт одна статика для десктопов.
Что в верстке может вызвать такое затруднение, что программист точно не справится? Не сумеет правильно расставить теги? Выберет не те? Не разведет блоки по разным сторонам макета или не сможет построить сетку? Что именно может вызывать и вызывает проблемы у программистов в верстке? Теги, правильный выбор селекторов или набор свойств?
Тогда уж — а что именно вызывает проблемы у верстальщика с небольшим опытом в верстке сайтов? Если судить по вашим словам — эти проблемы должны быть аналогичны тем, что возникают у программистов. Ведь не может быть, что одно только знание ехнологии — продвигает специалиста вперёд. Есть же и особенности применения технологий, одни правильные, другие нет. И разве этому можно научиться только по книжкам, в которых, например, рассказывается про свойства css?
У меня не много опыта в верстке и программировании, и очень интересно, не что именно надо изучать, а как. Потому что подробных карт — множество, реально дофига. Те же самые курсы html academy — можно открыть список и все примерно совпадет, за исключением того, что они не углубляются в более продвинутые технологии на курсах — для этого у них есть интенсивы.
Я не писал что фронтенд — плохой верстальщик. Я писал что, зачастую, человек уходя во фронтенд остается на уровне джун-мидл. Это разные навыки, требующие разного мышления, как вы и написали.
С одной стороны вёрстка — чисто механическая работа по определённым правилам. С другой стороны — 95% программирования это чисто механическая работа по определённым правилам. Для большинства уже есть готовые алгоритмы. Вам даже сортировки знать не надо (для большинства рядовых задач), ведь есть .sort().
Хорошего верстальщика отличает именно то, что у него в голове уже есть информация об актуальных браузерах, ограничениях, десятке разрешений экрана, версии для слабовидящих и так далее. Ещё очень важна разница во времени в дальнейшей поддержке. Ну т.е. хороший верстальщик сделает за день, фронтендер со средней версткой сделает за два и ещё 3 будет доправлять баги.
Ну т.е. вопрос, скорее, не в том что вызывает такое затруднение, а затрачиваемое время. Многие программисты не интересуются ни БЭМом, ни OOCSS, ни другими техниками. Они им не интересны. «Это всего лишь вёрстка» — говорят они. А потом проект невозможно поддерживать.
Говорить на английском — простая, чисто механическая задача. Заучить порядка 5000 (для начинающего 500) слов, разобраться в правилах… да и всё. Но почему то даже если человек обладает словарным запасом, понимает синтаксис и так далее, для полноценного выхода на уровень надо «наговорить» хотя бы часов 500. Это просто навык, который нарабатывается.
Вёрстка тоже просто навык, который нарабатывается. И программирование. И дизайн, что бы вам не говорили.
Я сам вёл некоторые курсы и изучал существующие.
То что сейчас есть на рынке — оно, на самом деле, не годится для того уровня, который заявляется. Это сраный маркетинг.
Что бы выйти на нормальный уровень во фронтенеде нужно затратить порядка полугода фуллтайм. Хотя бы 1000 часов суммарно. При этом если заниматься по «паре часов», то итог смело можно умножать на 2-3. Т.е. при 4 часах в неделю, нужно лет 5.
Те, кто реально выходит с этих курсов и потом устраиваются, обычно, самомотивированы и помимо курсов тратят на учебу всё своё свободное время.
У меня было желание сделать курсы на базе существующих платформ (писал письма разным кампаниям). Предлагал полноценный длительный курс. Оказалось всё просто. Его не продать :-) Ну это и вполне очевидно. Многие тешат себя надеждой, что вот сейчас за пару месяцев по выходным пройду супер-курс и начну зарабатывать 100 000. Так НЕ БЫВАЕТ.
Вообще есть желание по данной теме отдельный пост сделать, но либо как-нибудь потом, либо никогда :-)
С одной стороны вёрстка — чисто механическая работа по определённым правилам. С другой стороны — 95% программирования это чисто механическая работа по определённым правилам. Для большинства уже есть готовые алгоритмы. Вам даже сортировки знать не надо (для большинства рядовых задач), ведь есть .sort().
Хорошего верстальщика отличает именно то, что у него в голове уже есть информация об актуальных браузерах, ограничениях, десятке разрешений экрана, версии для слабовидящих и так далее. Ещё очень важна разница во времени в дальнейшей поддержке. Ну т.е. хороший верстальщик сделает за день, фронтендер со средней версткой сделает за два и ещё 3 будет доправлять баги.
Ну т.е. вопрос, скорее, не в том что вызывает такое затруднение, а затрачиваемое время. Многие программисты не интересуются ни БЭМом, ни OOCSS, ни другими техниками. Они им не интересны. «Это всего лишь вёрстка» — говорят они. А потом проект невозможно поддерживать.
Говорить на английском — простая, чисто механическая задача. Заучить порядка 5000 (для начинающего 500) слов, разобраться в правилах… да и всё. Но почему то даже если человек обладает словарным запасом, понимает синтаксис и так далее, для полноценного выхода на уровень надо «наговорить» хотя бы часов 500. Это просто навык, который нарабатывается.
Вёрстка тоже просто навык, который нарабатывается. И программирование. И дизайн, что бы вам не говорили.
Я сам вёл некоторые курсы и изучал существующие.
То что сейчас есть на рынке — оно, на самом деле, не годится для того уровня, который заявляется. Это сраный маркетинг.
Что бы выйти на нормальный уровень во фронтенеде нужно затратить порядка полугода фуллтайм. Хотя бы 1000 часов суммарно. При этом если заниматься по «паре часов», то итог смело можно умножать на 2-3. Т.е. при 4 часах в неделю, нужно лет 5.
Те, кто реально выходит с этих курсов и потом устраиваются, обычно, самомотивированы и помимо курсов тратят на учебу всё своё свободное время.
У меня было желание сделать курсы на базе существующих платформ (писал письма разным кампаниям). Предлагал полноценный длительный курс. Оказалось всё просто. Его не продать :-) Ну это и вполне очевидно. Многие тешат себя надеждой, что вот сейчас за пару месяцев по выходным пройду супер-курс и начну зарабатывать 100 000. Так НЕ БЫВАЕТ.
Вообще есть желание по данной теме отдельный пост сделать, но либо как-нибудь потом, либо никогда :-)
Хорошего верстальщика отличает именно то, что у него в голове уже есть информация об актуальных браузерах, ограничениях, десятке разрешений экрана, версии для слабовидящих и так далее.Собственно говоря — вот что я хотел услышать. Спасиб.
Что касается остального — не согласен с тем, что любой человек может научиться программированию, таки для этого необходим определенный склад мышления. Вы судите по себе и своему окружению, потому вам это кажется чисто механическим навыком.
1000 часов для обучения фронтенду — это что именно? Изучение ЯП и алгоритмов, или языки человек уже должен знать и 1000 часов надо на изучение конкретных технологий и практику?
Сколько тогда будут длиться этапы «пути верстальщика» по вашей схеме? Ориентировочно ессно. Статью про курс — интересно было бы почитать :)
таки для этого необходим определенный склад мышления.
Ну тут мы уйдем больше в философию или типа того.
Я, лично, убеждён что человек способен научиться и делать всё что угодно. История преподносила кучу примеров, когда люди «не способные к чему либо» становились в этом реально лучшими.
Ну и у меня как раз есть обратные примеры. Вообще всё не однозначно. Но зависит только от желания и всё.
1000 часов для обучения фронтенду — это что именно?
Ну тут опять же, это зависит от того к чему стремиться. Само собой сперва нужно определить кучу критериев. У меня они в голове сформировались за последние лет 5, пока более менее плотно обучал людей. Постепенно буду публиковать.
Вообще это такое число (1000 часов) что бы начать хорошо разбираться практически в любой теме с нуля, а не только программирование.
В зависимости от желаемого фронта задач сюда можно будет включить изучение различных математик, алгоритмов, методологий, навыки общения с людьми и так далее. Гора практики (минимум 50% от времени) обязательна.
По схеме… ну сейчас прикину. Но это прям на глаз.
90-100 часов на теорию для джуна. Ещё столько же на практику.
~120 часов на мидла, при исключении всего что можно отложить и опционального. Ещё столько же на практику.
~250 часов на сеньёра, без опциональных вещей (точнее, с частичным охватом). Плюс практика.
На изучение опциональных штук с сеньёра ещё часов сто.
Ну вот то на то и вышло. Около 500 часов теории, около 500 часов практики. И вы крутой верстальщик (коих в мире мало).
Под хорошим уровнем фронтендера я имел ввиду не сеньёра, если что. Фронтендеру (в зависимости от задач) хватит половины навыков джуна, ну или чуть меньше мидла.
Людей обучали в процессе работы, или какие-то курсы вели?
Информация интересная, спасиб. Есть над чем подумать.
Информация интересная, спасиб. Есть над чем подумать.
И в процессе работы, как тимлид/руководитель, и курсы вёл немного.
С курсами ситуация печальная, на самом деле. Большая часть курсов подразумевает пару занятий в неделю по 2 часа. Это 4 часа в неделю. Между занятиями всё забывается :-)
Какие-то узконаправленные курсы, да, работают. А вот что б обучиться как-то с нуля… только самому, по сути. Либо прям с индивидуальными менторами (а это дорого, если толковые).
В угоду маркетингу обещают людям нереальные сроки и результат. Потом такие же на собеседования приходит. Прошел человек курс за 10 000 ничего не зная ранее, просит зарплату сто тысяч. Это дикий неадекват какой-то.
Я даже стал понимать от чего HRы такие злостные в куче компаний. Вот что б фильтровать это всё :-)
С курсами ситуация печальная, на самом деле. Большая часть курсов подразумевает пару занятий в неделю по 2 часа. Это 4 часа в неделю. Между занятиями всё забывается :-)
Какие-то узконаправленные курсы, да, работают. А вот что б обучиться как-то с нуля… только самому, по сути. Либо прям с индивидуальными менторами (а это дорого, если толковые).
В угоду маркетингу обещают людям нереальные сроки и результат. Потом такие же на собеседования приходит. Прошел человек курс за 10 000 ничего не зная ранее, просит зарплату сто тысяч. Это дикий неадекват какой-то.
Я даже стал понимать от чего HRы такие злостные в куче компаний. Вот что б фильтровать это всё :-)
что?)
1000 часов и ты средний джун по верстке.
1000 часов и ты средний джун по верстке.
Блин, вот больше всего не люблю когда начинают коверкать мои слова.
Цитата:
Где тут про «сильный»?
В данной ветки речь про вёрстку.
Ну и 1000 часов до среднего верстальщика только при отсутствии плана и слепом тыканье. Когда знаешь что изучать, как изучать, что и зачем делать. Когда двигаешься по уже готовому пути — всё идёт куда быстрее.
По моим прикидкам с нуля за пол года можно подготовить сильного мидл-фуллстека, при полностью индивидуальных занятиях 1 на 1 по 4 часа каждый день (+ 4 часа самостоятельной работы).
Цитата:
Что бы выйти на нормальный уровень во фронтенеде нужно затратить порядка полугода фуллтайм. Хотя бы 1000 часов суммарно.
Где тут про «сильный»?
В данной ветки речь про вёрстку.
Ну и 1000 часов до среднего верстальщика только при отсутствии плана и слепом тыканье. Когда знаешь что изучать, как изучать, что и зачем делать. Когда двигаешься по уже готовому пути — всё идёт куда быстрее.
По моим прикидкам с нуля за пол года можно подготовить сильного мидл-фуллстека, при полностью индивидуальных занятиях 1 на 1 по 4 часа каждый день (+ 4 часа самостоятельной работы).
Автор молодец. «в верстке есть очень много левых людей», которые не брезгуют высказать свое мнение, которое оправдывает их самих, и в свою очередь, сбивает с толку менее опытных.
У меня на работе фронты отдельно и верстаки отдельно.
Фронды действительно в верстке уровня джун, и за частую так и бывает.
Хотя я бы не делил уровни по количеству работ. Для меня синьйор, это отличные навыки с сложными цсс свойствами. 3д анимации?svg, кенвас, сложные гладиенты, DRY в лучшем его виде и js/
У меня на работе фронты отдельно и верстаки отдельно.
Фронды действительно в верстке уровня джун, и за частую так и бывает.
Хотя я бы не делил уровни по количеству работ. Для меня синьйор, это отличные навыки с сложными цсс свойствами. 3д анимации?svg, кенвас, сложные гладиенты, DRY в лучшем его виде и js/
У меня на работе фронты отдельно и верстаки отдельно.
Как у вас организован процесс совместной разработки при таком разделении?
… сложными цсс свойствами
Это что за свойства такие?
Спасибо.
Про количество работ я уже давал комментарии тут — это просто ориентир для тех, кто хочет пройти путь, не более.
Про количество работ я уже давал комментарии тут — это просто ориентир для тех, кто хочет пройти путь, не более.
Мне вот интересно, почему верстальщики бывают только браузерные? Нет ведь ни iOS-верстальщиков, ни Android-верстальщиков, ни каких-нибудь Delphi-верстальщиков: всё делают разработчики. Хотя на каждой платформе точно так же куча особенностей. Мне кажется, что в веб-верстке происходит куча лишней работы на стыках дизайнер-верстальщик-разработчик, т.к. движение данных между ними никогда не бывает строго одностороннее.
На самом деле всё довольно легко объясняется.
В случае нативных приложений отрисовкой занимается ваша же программа, а в браузерных приложениях — браузер.
Вы можете выпустить нативное приложение только под windows, например, и оно там будет корректно работать. Но нельзя выпускать сайт только под windows (точнее можно, но…).
В задачи врестальщика входит знание целой кучи особенностей комбинаций операционных систем, браузеров и так далее.
Ну и ещё, открою секрет, таки бывают люди специализирующиеся на проработке непосредственно интерфейсов нативных приложений :-)
В случае нативных приложений отрисовкой занимается ваша же программа, а в браузерных приложениях — браузер.
Вы можете выпустить нативное приложение только под windows, например, и оно там будет корректно работать. Но нельзя выпускать сайт только под windows (точнее можно, но…).
В задачи врестальщика входит знание целой кучи особенностей комбинаций операционных систем, браузеров и так далее.
Ну и ещё, открою секрет, таки бывают люди специализирующиеся на проработке непосредственно интерфейсов нативных приложений :-)
Я как верстальщик с более чем 6 летним опытом соглашусь, что воспринимать верстальщика как ступеньку к frontend не совсем верно. Хоть сам изначально планировал быстро проскочить эту ступеньку, полагая что учить и узнавать тут практически нечего и самое интересное ждет в frontend, но в результате бы сильно впечатлен открывшимися передо мной горизонтами и возможностями в познании верстки. И хочу сказать что произошло это далеко не сразу, только спустя года 3-4 пришло осознание того что конца и края новым знаниям и возможностям не видно, особенно после знакомства с БЭМ и посещения пары конференций в Яндексе.
А вот по поводу навыков к каждому уровню не соглашусь. Тут видно что вы скорее их применительно к своему проекту описали. Я к примеру с WordPress так и не столкнулся в работе (вот сам не знаю как так получилось, только из любопытства смотрел) в крупных и старых проектах зачастую используется что-то своё, появившееся иногда раньше того же WordPress. Я бы его просто поменял на умение работать с CMS или понимание принципов их работы на уровне достаточном для взаимодействия.
И пожалуй самое главное что мне хотелось бы добавить (после недавнего набора новых молодых верстальщиков) — это понимание у них того, зачем нужны препроцессоры в работе верстальщика, а то нынче любой джуниор их знает, пользуется, а зачем оно и почему он пишет в нём, а не на простом css объяснить не может. И это при том, что местами они сильно вредят и усложняют дальнейшее поддержание кода до такой степени, что проще всё переписать. (не во всех проектах хранятся исходные файлы less и sass, а сгенерированная белеберда зачастую нечитаема и весит больше чем могла бы, что для проектов с большим трафиком уже существенно)
А вот по поводу навыков к каждому уровню не соглашусь. Тут видно что вы скорее их применительно к своему проекту описали. Я к примеру с WordPress так и не столкнулся в работе (вот сам не знаю как так получилось, только из любопытства смотрел) в крупных и старых проектах зачастую используется что-то своё, появившееся иногда раньше того же WordPress. Я бы его просто поменял на умение работать с CMS или понимание принципов их работы на уровне достаточном для взаимодействия.
И пожалуй самое главное что мне хотелось бы добавить (после недавнего набора новых молодых верстальщиков) — это понимание у них того, зачем нужны препроцессоры в работе верстальщика, а то нынче любой джуниор их знает, пользуется, а зачем оно и почему он пишет в нём, а не на простом css объяснить не может. И это при том, что местами они сильно вредят и усложняют дальнейшее поддержание кода до такой степени, что проще всё переписать. (не во всех проектах хранятся исходные файлы less и sass, а сгенерированная белеберда зачастую нечитаема и весит больше чем могла бы, что для проектов с большим трафиком уже существенно)
Тут видно что вы скорее их применительно к своему проекту описали.
Писал на основании 15-летнего опыта разработки и общения с большим количеством специалистов различного плана.
Я к примеру с WordPress так и не столкнулся в работе… Я бы его просто поменял на умение работать с CMS
В схеме WordPress идёт опциональным, при этом общие знания по CMS обязательны для сеньёра. Невнимательно смотрели.
Ну и я специально делал отдельные пункты как «CSS препроцессоры». Это не просто пункт, это прям изучать надо отдельно.
В схеме WordPress идёт опциональным, при этом общие знания по CMS обязательны для сеньёра. Невнимательно смотрели.
Я скорее к тому, что WordPress как частный и наиболее распространенный пример CMS логичнее было бы поместить на более низкий уровень, а общее понимание CMS считать уже более продвинутым.
А те же media queries сейчас обязательны уже и для джуниора т.к. примерно половина пользователей(возможно уже и больше) пользуются мобильными телефонами и другими девайсами при посещении сайтов, и media queries нужны практически в любой вёрстке.
Ну и я специально делал отдельные пункты как «CSS препроцессоры». Это не просто пункт, это прям изучать надо отдельно.
Это скорее прям запрещать нужно, до момента возникновения понимания хД
А те же media queries сейчас обязательны уже и для джуниора т.к. примерно половина пользователей(возможно уже и больше) пользуются мобильными телефонами и другими девайсами при посещении сайтов, и media queries нужны практически в любой вёрстке.
А вот теперь уже вы применительно к своим проектам применяете :-)
Не всем нужны мобилы (и наоборот, не всем нужны десктопы).
не во всех проектах хранятся исходные файлы less и sassМне кажется — это очень плохие проекты, не годные… Как можно не хранить исходники?!
В частных случаях верстальщик может сдавать работу без исходников.
Например, если у него приобрели Лендинг, то он может отдавать это как конечный продукт, держа исходники у себя.
О морально-этической стороне вопроса мы тут не говорим, но в целом, такие ситуации встречаются.
Например, если у него приобрели Лендинг, то он может отдавать это как конечный продукт, держа исходники у себя.
О морально-этической стороне вопроса мы тут не говорим, но в целом, такие ситуации встречаются.
Это к примеру проекты в которых в силу их возраста и технических особенностей, просто нет возможности хранить эти исходники. Разве что в отдельно созданном месте, к примеру на том же гите, но напрямую с проектом это связано не будет. И в результате в любом случае получаем лишние сложности при обновлении кода, плюс возможные ошибки при переносе и несоответствия кода в гите и в проекте и т.д. и т.п.
В общем частные случаи в работе которые могут возникнуть по тем или иным обстоятельствам. А большинство начинающих верстальщиков сейчас банально не могут без препроцессоров ничего написать. И инструмент который был призван помочь и упростить, в результате превратился в какую-то щайтан машину которая снижает общий уровень начинающих специалистов, которые банально не понимают что за них нужно браться уже после того как смог в простой css
В общем частные случаи в работе которые могут возникнуть по тем или иным обстоятельствам. А большинство начинающих верстальщиков сейчас банально не могут без препроцессоров ничего написать. И инструмент который был призван помочь и упростить, в результате превратился в какую-то щайтан машину которая снижает общий уровень начинающих специалистов, которые банально не понимают что за них нужно браться уже после того как смог в простой css
Для меня это дико. Я полиграфист, потому аналогия типа — как сдать в архив слитые тифы, а слоеные псд стереть.
Что значит «не могут без препроцессоров»? Как можно не знать css и знать препроцессоры? Они ведь только немного упрощают читаемость, принципиально нового там нет и быть не может, это же просто синтаксическая надстройка. Что может писать верстальщик на sass такое, что потом не сможет повторить на простом css? Я не понимаю. Все равно, что сгруппировать по смыслу слои в фотошопе — внешне в файле проще разобраться, но и без группировки коллаж не разваливается.
Если git не хранит файлы sass, less и подобные и не может связать их в css — это как-то неправильно… Оно и правда так устроено? Если что — в git я разбираюсь слабо :)
Что значит «не могут без препроцессоров»? Как можно не знать css и знать препроцессоры? Они ведь только немного упрощают читаемость, принципиально нового там нет и быть не может, это же просто синтаксическая надстройка. Что может писать верстальщик на sass такое, что потом не сможет повторить на простом css? Я не понимаю. Все равно, что сгруппировать по смыслу слои в фотошопе — внешне в файле проще разобраться, но и без группировки коллаж не разваливается.
Если git не хранит файлы sass, less и подобные и не может связать их в css — это как-то неправильно… Оно и правда так устроено? Если что — в git я разбираюсь слабо :)
Исходники всегда в гите, а вот собранные CSS там быть не должны :-)
Так что автор выше рассказывает о каких-то странных моментах.
Так что автор выше рассказывает о каких-то странных моментах.
Момент и правда странный, не буду вдаваться в подробные объяснения т.к. долго и нельзя.
Но это далеко не единственная и не самая главная причина почему тот же less и sass не всегда хорошо. Попробую привести пример. У нас есть некий css написанный на препроцессоре, при развертке он весит к примеру 100кб, но все мы знаем что препроцессоры разворачивают код не оптимально, и тот же css написанный без их участия будет весить 60кб. А теперь выложим это на высоконагруженный сайт, с количеством загрузок более 30 000 000. И получим лишний трафик более чем на 1.2 терабайта в сутки. И вот это пожалуй основная причина моей нелюбви к препроцессорам, сыро и не оптимально (
Но это далеко не единственная и не самая главная причина почему тот же less и sass не всегда хорошо. Попробую привести пример. У нас есть некий css написанный на препроцессоре, при развертке он весит к примеру 100кб, но все мы знаем что препроцессоры разворачивают код не оптимально, и тот же css написанный без их участия будет весить 60кб. А теперь выложим это на высоконагруженный сайт, с количеством загрузок более 30 000 000. И получим лишний трафик более чем на 1.2 терабайта в сутки. И вот это пожалуй основная причина моей нелюбви к препроцессорам, сыро и не оптимально (
Высоконагруженный сайт решил сэкономить и нанял начинающего разработчика, судя по вашему примеру и контексту.
Сэкономил и вот результат.
Сэкономил и вот результат.
Это скорее причина почему для таких разработчиков есть отдельная позиция junior и их код за ними перепроверяют. Ну и даже с таким учетом понимание актуальности инструмента в той или иной ситуации должна быть.
Я таки домучаю вас вопросами, потому что изучение верстки для меня сейчас актуально :)
Есть ли способ изначально писать sass таким образом, что бы он оптимально развертывался в css? Или может есть автоматические оптимизаторы?
//мечтает
Вот было бы здорово — сделать sass и тп вещи стандартом, что бы браузеры понимали их без компиляции… Внедрили же в браузеры онлайн-архиваторы сайтов.
Есть ли способ изначально писать sass таким образом, что бы он оптимально развертывался в css? Или может есть автоматические оптимизаторы?
//мечтает
Вот было бы здорово — сделать sass и тп вещи стандартом, что бы браузеры понимали их без компиляции… Внедрили же в браузеры онлайн-архиваторы сайтов.
Тут нужно определиться о какой оптимальности речь.
Конечный вес или скорость рендера? :-)
В целом и то и то решаемо с любым препроцессором, если понимаешь как он работает. Но, в большинстве случаев, вес и скорость рендера не важны.
Дублирование CSS решается гзипом и как бы (если речь о весе шла) проблемы и нет (ну тут можно ещё поспорить об оптимизациях CPU и о плюсах отправки несжатого контента, но о таких вещах вообще единицы задумываются).
Конечный вес или скорость рендера? :-)
В целом и то и то решаемо с любым препроцессором, если понимаешь как он работает. Но, в большинстве случаев, вес и скорость рендера не важны.
Дублирование CSS решается гзипом и как бы (если речь о весе шла) проблемы и нет (ну тут можно ещё поспорить об оптимизациях CPU и о плюсах отправки несжатого контента, но о таких вещах вообще единицы задумываются).
Вот я тоже не понимал, пока не увидел своими глазами. И ладно бы 1 попался, так такой каждый третий приходил.
Заказчик хочет лендинг, быстро и дешево, платит студенту три копейки и получает соответствующий результат. Страничка работает? Да. За поддержку заплачено? Нет.
Результат предсказуем.
Надо не препроцессоры запрещать, а запрещать жадных заказчиков, которые хотят все, сразу, быстро и много, а главное — дешево. Не технологии виноваты — а глупость человеческая.
Результат предсказуем.
Надо не препроцессоры запрещать, а запрещать жадных заказчиков, которые хотят все, сразу, быстро и много, а главное — дешево. Не технологии виноваты — а глупость человеческая.
В такой ситуации да, но если ты идешь устраиваться на работу в крупную компанию с зп выше средней, и не можешь писать без препроцессоров — это как минимум странно. А учитывая что в резюме опыт работы указан более года, то лично для меня это вообще дико.
Еще раз.
Я не понимаю, как можно не уметь писать без препроцессоров? Мы говорим об одном и том же? Как, к примеру — SASS, который (вкратце) всего лишь позволяет более удобно группировать селекторы и не повторять сто раз зубодробительные гексовые коды цветов — поможет написанию стилей, если человек не знает как эти стили пишутся и не умеет расставлять селекторы?
Можно какойнить конкретный пример?
Я не понимаю, как можно не уметь писать без препроцессоров? Мы говорим об одном и том же? Как, к примеру — SASS, который (вкратце) всего лишь позволяет более удобно группировать селекторы и не повторять сто раз зубодробительные гексовые коды цветов — поможет написанию стилей, если человек не знает как эти стили пишутся и не умеет расставлять селекторы?
Можно какойнить конкретный пример?
К примеру можно не знать префиксы или неспособность самостоятельно прописать полный путь до дочернего элемента #main .block a{}, плюс постоянно забывать ставить { }
Мне сложно объяснить всё с точными примерами, но со стороны видно что для человека привычные действия становятся как буд-то в новинку, чуть ли не слышно как шестеренки скрипят. Мне кажется что тут больше какой-то психологический фактор, как с автомата на механику пересесть (при условии что последний раз на ней ездил на экзамене в гаи), вроде и водить умеешь, но что-то явно не то и какая-то лишняя педаль под левой ногой появилась ))
Мне сложно объяснить всё с точными примерами, но со стороны видно что для человека привычные действия становятся как буд-то в новинку, чуть ли не слышно как шестеренки скрипят. Мне кажется что тут больше какой-то психологический фактор, как с автомата на механику пересесть (при условии что последний раз на ней ездил на экзамене в гаи), вроде и водить умеешь, но что-то явно не то и какая-то лишняя педаль под левой ногой появилась ))
Ну так — это просто неграмотность и некомпетентность, она не является следствием технологии, а только бестолковостью конкретного человека. Я умею писать таблицы стилей без sass и тп, но ощущения не из приятных, как вести велик руками, вместо того — что бы сесть на него и поехать (если что — у меня машина с механикой (; ).
Может проще написать все как привычно, а в продакшне оптимизировать css какимнить автоматическим способом? Есть такие оптимизаторы? Мне кажется, я что-то подобное встречал. А чистый css использовать тогда, когда надо срочно подправить стили на сервере и нет времени пересобирать проект.
Может проще написать все как привычно, а в продакшне оптимизировать css какимнить автоматическим способом? Есть такие оптимизаторы? Мне кажется, я что-то подобное встречал. А чистый css использовать тогда, когда надо срочно подправить стили на сервере и нет времени пересобирать проект.
Вот я как раз в том отделе работаю который отвечает за быстро поправить и не пересобирать проект.
А автоматически код и так оптимизируется(минимизируется), но того что вы имеете в виду я не встречал.
А автоматически код и так оптимизируется(минимизируется), но того что вы имеете в виду я не встречал.
Эх, поделюсь ка и я, своей live-story:
В нашей компании продукт — CRM|CMS. Полтора года я внедрял SCSS-подсистему в него. Обеспечивал переход со 100500 разбитых css-файлов на один единый «выхлоп» из препроцессинга.
Однако за океаном у нас есть «последняя миля» перед конечными клиентами. Конечный дизайн пилят так же там, в кооперативе с клиентами. Как итог, чтобы не нагружать бедный мозг гуманитариев излишне технической «лабудой» я прикрутил override — css файл для кастомных правок. Он не кладется в основной репозиторий, всегда читается браузером после выхлопа препроцессора. За полтора года у всех только положительное отношение к этому опыту.
В нашей компании продукт — CRM|CMS. Полтора года я внедрял SCSS-подсистему в него. Обеспечивал переход со 100500 разбитых css-файлов на один единый «выхлоп» из препроцессинга.
Однако за океаном у нас есть «последняя миля» перед конечными клиентами. Конечный дизайн пилят так же там, в кооперативе с клиентами. Как итог, чтобы не нагружать бедный мозг гуманитариев излишне технической «лабудой» я прикрутил override — css файл для кастомных правок. Он не кладется в основной репозиторий, всегда читается браузером после выхлопа препроцессора. За полтора года у всех только положительное отношение к этому опыту.
Вдогонку.
Не заметил в таблице Emmet, а технология очень полезная и по смыслу близка к препроцессорам. Препроцессоры выделили, а Emmet — нет. Странно.
Не заметил в таблице Emmet, а технология очень полезная и по смыслу близка к препроцессорам. Препроцессоры выделили, а Emmet — нет. Странно.
Я и IDE сам не использую (точнее редко использую). Не считаю важным выделение Emmet'а.
По моему Emmet сейчас любой редактор умеет почти из коробки, в тот же Atom он в два клика ставится плагином. IDE здесь непонятно при чем, Emmet всего лишь ускорение набора, аналог автодополнения, которое умеет делать вообще любой приспособленный для верстки редактор, но автодополнение чрезвычайно гибкое и мощное. Например — одной строчкой можно «сверстать» таблицу из десятков строк, десятков ячеек и расставить в тегах уже пронумерованные как надо классы.
Одна строчка:
Делать такую таблицу руками — убиться можно и ошибиться легко. Хоть такие конструкции не часто нужны, но и в более простых вещах все получается быстрее.
Одна строчка:
table.tabs>tr.tab-row-$((td.tab-cell-${cell $})*20)*20Делать такую таблицу руками — убиться можно и ошибиться легко. Хоть такие конструкции не часто нужны, но и в более простых вещах все получается быстрее.
Не знаю сколько времени сэкономлено. Вероятно, мало.
Я давно пришел к тому что написание кода занимает от силы процентов 5 времени от всей работы. Гораздо лучше вкладываться в оптимизацию других процессов, а не в написание кода.
Ну и, честно говоря, я вообще слабо представляю в какой момент мне понадобилось бы писать как по примеру выше :-)
Я давно пришел к тому что написание кода занимает от силы процентов 5 времени от всей работы. Гораздо лучше вкладываться в оптимизацию других процессов, а не в написание кода.
Ну и, честно говоря, я вообще слабо представляю в какой момент мне понадобилось бы писать как по примеру выше :-)
На самом деле, учить довольно-таки много приходится. Порой, испытываешь такую эйфорию, когда понимаешь, сколько всего уже позади и побеждаешь трудности, которые решаются неделями. Самое затратное дело — читать бесполезные руководства с кучей воды, время летит в унитаз.
Много раз изучая что-либо, ловил себя на мысли, что проще идти от сложного к простому, а не наоборот. Это позволяет видеть общую картину и лучше понимать, для чего нужен тот или иной компонент. Это я к тому, что у самоучек часто WordPress будет на уровне Junior. Возможно, я субъективен, но это, как минимум, позволяет уйти от академической рутины, когда изучать Notepad++ и шрифты просто скучно.
Zav, а что вы под одной работой подразумеваете?
Например, у вас джун — 10 работ, одна работа — это секция лендинга, сам лендинг, страница сайта или все страницы интернет-магазина?
Например, у вас джун — 10 работ, одна работа — это секция лендинга, сам лендинг, страница сайта или все страницы интернет-магазина?
Лично я называл тут работой отдельный лендинг, включая все его секции.
При этом различные по структуре страницы можно считать отдельно даже в рамках одного портала.
Кажется, в чем же разница? Ведь секции тоже разные.
Разница в том, как это поддерживается и взаимодействует. В рамках одной физической страницы всегда легче прийти к согласию. Зачастую лендинги имеют очень схожие структуры в рамках секций и одинаковые приёмы, а отдельные страницы на сайтах я имел ввиду именно структурно разные, т.е. 5 страниц блога это таки одна страница.
При этом различные по структуре страницы можно считать отдельно даже в рамках одного портала.
Кажется, в чем же разница? Ведь секции тоже разные.
Разница в том, как это поддерживается и взаимодействует. В рамках одной физической страницы всегда легче прийти к согласию. Зачастую лендинги имеют очень схожие структуры в рамках секций и одинаковые приёмы, а отдельные страницы на сайтах я имел ввиду именно структурно разные, т.е. 5 страниц блога это таки одна страница.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Путь верстальщика: с нуля до сеньора