Oscar Handsome

main: nectarjs.com
github: https://github.com/NectarJS/nectarjs
demo: nectar-lang.com
blog: blog.seraum.com

> И в некоторых ситуациях обфускация не помогает(html,css,js,jquery).

Она никогда не помогает.
Эффективности столько же как писать против ветра.

Верстальщик преобразует графический макет (Photoshop или иной) в набор HTML + CSS + картинки. Иногда к свёрстанному макету может подключить типовые библиотеки Javascript, например, slider для картинок, или всплывающие подсказки (tooltip), или диалоговые окна (dialog/popup).
Знания и навыки:

• работа с графическими программами, чтобы понять, как собран макет
  
• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты и другие технологии
  
• пригодятся знания по HTML-фреймворкам, например, Twitter Bootstrap или Semantic UI
• навыки кроссбраузерной вёрстки, чтобы в разных браузерах выглядело и работало одинаково
  
• навыки отзывчивой вёрстки, чтобы можно было использовать на устройствах с разными возможностями и разрешениями
  
• знание типовых решений javascript, чтобы реализовать простейшие вещи, заложенные в макете
  

Фронтенд-разработчик делает так, чтобы макеты, полученные от верстальщика, были наполнены реальными данными. Если приложение построено как client-side (то есть вся основная логика загружается в виде огромного javascript в браузер, а данные запрашиваются с сервера по AJAX; это называется "толстый клиент"), то фронтенд-разработчику потребуется следующее:

• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты, Comet и другие технологии
• глубокое знание Javascript, включая использование готовых фреймворков, библиотек и написание расширений для них, что подразумевает объектно-ориентированное и событийное программирование
  
• знание AJAX, CORS и навык создания тестовых затычек на стороне сервера, чтобы можно было разрабатывать приложение пока бакенд не готов
  

Если фронтенд строится на стороне сервера, то дополнительно потребуется знать используемый серверный язык программирования (например, Python, Ruby или PHP) и используемый фреймворк (Django, Ruby-on-Rails, Yii). На практике бывало такое, что фронтендер просил в нужной части проекта сделать var_dump от структуры данных, которую надо показать и перечислить серверные методы, которые надо вызвать по нажатию предполагаемых кнопок.

Зачастую фронтенд-разработчик может и сам закодировать эти серверные методы, если не требуется углубляться в серверную логику (отношения в данных, конкретная бизнес-логика, хранение данных, кэширование, очереди, крон-задачи). Я лично таких очень ценю.

И моё личное мнение - фронтенд разработчику не помешают базовые знания про UML. Иногда с ними так тяжело обсуждать обмен данными по AJAX. У них это какой-то непрерывный поток магической энергии, волшебным образом преобразующийся в буковки на экране пользователя, а вот для бакенда это набор отдельных операций, иногда ещё и асинхронный. Диаграммы последовательностей ни читать, ни писать многие не умеют. Таймлайны составлять не умеют.

-----------

Написал дополнение: copist.ru/blog/2015/08/29/layout-designer-vs-front...

Могу посоветовать очень хорошее видео, с FrontTalk –vimeo.com/107580454

Портфолио + небольшой опрос все скажет о кандидате. Тестовое можно, но 4 часа это потолок для него.

Это кидалово, не делать. Макет гавно, а судя по требованиям по ТЗ, это просто попытка получить полноценную работу нахаляву, а не тест.

Редиректы - да, нужны. Посетители должны попадать в точности туда, куда они собирались.
Но всё равно со сменой кода, даже при точных редиректах, произойдёт ресканирование сайта и стресс для рейтинга страниц. Чаще всего такие вещи идут в минус, увы.

начни продавать те навыки которые лучше всего получаются, остальные подтягивай)
тебе зарабатывать реально, хоть и конкуренция большая, рынок тоже большой. Задача научится себя продать, дерьмовую работу сложно продавать, дерьмо не любят, но есть куча вариантов при которых и дерьмо покупают.
Подавляющее большинство фрилансеров говнари, и делают всякую херню (не лучше тебя), поэтому для них единственный вариант продать свой труд, продолжать снижать на него цену.
Это путь в никуда -> но есть варианты не ценовой конкуренции, например найти свой сегмент, свою специализацию, которая у тебя лучше всего получается, и начинать отстраиваться от конкурентов какими-то преимуществами (качеством, подачей, сервисом и доп услугами и тд).
Чем раньше начнешь так делать, тем быстрее начнешь реально зарабатывать.

если вы спрашиваете, то однозначно нет

Совместимы, странно, что вы этого не знаете, вы задавали вопросы по апворку тут еще 2.5 года назад, при желании могли уже найти работы и на 60$ рейт с загруженностью в 50 часов в неделю.

Не факт, что конкретно один клиент будет кормить вас 11 месяцев в году, так вы можете менять проекты, конкуренции то нет.

А про это:

реально ли вообще заниматься кодингом столько часов

У нас в odeskconf есть реальные примеры того, что люди трекают больше чем 40 часов стабильно.
Ну и нужно не забывать, что трекать = не только писать код.

А как отвечать на этот вопрос фрилансерам, чьё рабочее время было ненормировано? Допустим, я работаю разработчиком 3 года, но убеждён, что моя рабочая неделя редко превышала 20 часов непосредственного кодинга - мне делить свой опыт на 2, чтобы получить количество лет стажа?

А если рабочая неделя 80 часов? Умножать на два? Без выходных, отпусков? На три? "Здрасти, мне 25 лет и у меня 15 лет опыта работы с ангуляром 4"? Лол. Кроме того, не забываем, что и в офисе КПД тоже отнюдь не 100% и даже далеко не 70% - чай, кофе, покурить, обсудить что-то с коллегами, помочь коллеге, выйти на время уборки суровой тётей Машей, доложить начальнику, составить отчет еженедельный/ежедневный, и т.п. - делим пополам? На три? Время в опыте работы - всего лишь примерная характеристика и далеко не первоочередная. Опыт он может быть разный: 10 лет веб-разработки на одной должности в одной фирме в корпоративной внутренней CRM и 10 лет клепания веб-сайтов, программ для серверов, десктопов, телефонов, мк, и прочего фриланса/подработок - это очень и очень разные 10 лет. Так что не забываем про контест.

Во первых нужно закладывать время на разбор легаси кода, об этом сразу надо говорить с заказчиком. Зная задачу, всегда понимаешь, ЧТО надо написать, но в случае с легаси надо еще и понять КУДА это написать. Без этого никак и поэтому это время надо учитывать.

Второе. Когда-то меня учили, что код нужно менять только дописывая его, в крайнем случае удаляя, но ни в коем случае не переписывая. Поэтому, если надо изменить поведение - наследуешься, переопределяешь метод и используешь новый класс. Мне сложно судить о php, как этот проект реализован, но ООП для того и придумали, что его легче поддерживать и он легче модифицируется.

Следующий вариант изучить код, начинать писать тесты к нему. Я этим способом пользуюсь редко, в основном пишу на то, в чем я не уверен, что боюсь сломать.

Ну конечно система контроля версий, по чаще комиты, чаще запускай проект, смотри, что ничего не сломалось. Я перестал бояться что-то сломать, потому что в любой момент могу сравнить, что изменилось в коде, между ветками и если сломалось, то сделать реверт или уйти на рабочую ветку.

А вообще чтение легаси, это дело опыта. Я помню первые свои чужие проекты, я думал, что попал в ад. Сейчас копаться в чужом коде, это мое любимое дело) Я могу часами сидеть разбирать чужой код, что начальству приходится меня попускать: "я понимаю, я тоже это люблю, но надо дело делать")) Люблю просто на гитхабе полазить по чужим проектам, посмотреть как люди думают.