Даниил Постнов

var lastnumb = '', timeout = 0;

$('[id*=fruit]').on({
	mouseenter: function() {
		timeout = setTimeout(function() {
			lastnumb = $(this).prop('id').replace(/[^\d;]/g, '');
			$('#num_words' + lastnumb).animate({
				height: 'show'
			}, 250);
		}.bind(this), 1000);
	},
	mouseleave: function() {
		clearTimeout(timeout);
		$('#num_words' + lastnumb).animate({
			height: 'hide'
		}, 250);
	}
});

Определитесь сначала что вам интереснее делать, а то ощущение что вы где-то услышали слово «веб-дизайнер», подумали что-то неправильно и захотели им стать. Вы хотите только рисовать макеты в Фш или еще и верстать их? Или, может, сразу делать сайты «под ключ»? Для полного цикла разработки вам потребуется знать гораздо больше озвученного в вопросе. Если же только макеты, то всякие нюансы фреймворков и CMS по ходу работы будут пояснять верстальщики, с которыми придется сотрудничать.

Что нужно знать для того чтобы быть хорошим веб-дизайнером?
Каждый из пунктов подойдёт для отдельного вопроса или целой статьи, но попробую вкратце.

• В первую очередь надо иметь вкус. Прививают хороший вкус, например, в художественных школах или просвещенные родители. Самостоятельно читать книги и полезные статьи, смотреть на работы других, сравнивать и понимать что хорошо, а что плохо и почему(!). Приходит со временем и опытом. Если понимание что хорошо, а что плохо не придёт, то лучше менять занятие во избежание траты времени.
  
• Нужно знать основы графического дизайна. Композиция (очень важно), визуальная иерархия, влияние пустого пространства, теория цвета. Виды графики (растр, вектор) и форматы изображений.
  
• Нужно знать типографику хотя бы на базовом уровне. Виды шрифтов, области применения, параметры шрифтов и т.п. Для этого читаем книги и статьи. Сначала может показаться, что это вообще не имеет отношения к дизайну, но везде, где есть текст она нужна очень сильно. Одной типографикой можно сделать прекрасный дизайн. А многие считают дизайном лишь наличие рюшечек и картиночек.
  
• Надо знать инструменты. Можно орудовать и одним, но существует много других, которые облегчают работу над определенными вещами. Не забываем, что помимо общего макета сайта еще потребуется подбирать материал для работы (фото и другую графику), создавать баннеры и иллюстрации, а также наборы иконок (не всегда прокатит скачивание из интернета старых и некрасивых клипартов), создавать коллажи и иную графику, присутствующую на сайте и т.п. Однозначно потребуется Фотошоп для растровой графики, Иллюстратор для векторной (Скетч, если работать на МАКе или КорелДРО, если он больше нравится). Причем, знать не просто на базовом уровне, а знать все инструменты, что они делают и как их можно применять. Это не сразу, с опытом, но не умея обращаться с рабочим инструментом вы не сможете работать быстро и качественно.
  Два редактора нужно обязательно вектор+растр. Причем, уже давно многие современные интерфейсы делаются в векторе из-за большего удобства, просто не все верстальщики хотят учиться верстать из него, плагинов-то под Фш гораздо больше.
  
• Нужно уметь проектировать сайт. Для этого помогут основы взаимодействия пользователя с интерфейсом, умение продумать логику работы, архитектуру. Изучить модульные сетки и их работу (типографика передает привет), определять цели проекта, аудиторию. Уметь прототипировать и знать инструменты для этого.
  
• Понимать что такое адаптивный и отзывчивый дизайн. Принципы построения и работы сетки при адаптивной верстке. Уметь подготовить макеты под неё. Знать особенности применения разных типов графики (растр, вектор).
  
• Нужно знать основы html и css. Важно понимать как все формируется в браузере и как те или иные визуальные элементы задаются в коде сайта. При желании можно совершенствоваться в плане полноценной верстки. Но одному человеку «под ключ» дают лишь малобюджетные сайты и сама верстка это лишь дополнение для несложных сайтов, не требующих использования CMS. Мое мнение, могу ошибаться.
  
• Нужно знать и понимать свою роль в процессе создания сайта. Уметь задать клиенту (или руководителю) правильные вопросы, ответы на которые помогут решить поставленную задачу. Уметь взаимодествовать с командой, уметь читать и помогать составлять ТЗ. Понимать как те или иные требования к сайту должны быть соблюдены. Уметь грамотно презентовать свои макеты (часто дизайнерские «фишки» не всем понятны на статичной картинке и нужно суметь объяснить задумку) и аргументированно объяснить свою позицию — почему сделано именно так, а не иначе.
  

И пара субъективных требований от меня.
1. Нужно знать и уметь пользоваться своим родным языком, знать разницу между типами кавычек, тире и дефисов. Уметь писать грамотно адреса и телефоны (для страниц контактных данных, например).
2. Никогда не использовать текст «рыбу» типа lorem ipsum или не подходящую по тематике. Делаете для строительства — погуглите про строительство, делаете для автомастерской — используйте текст на эту тему. Наличие правильного текста значительно упрощает восприятие макета. Идеальный вариант — работать по готовому контенту от клиента.

PS Главное помнить: чтобы стать хорошим специалистом в своём деле, надо потратить много времени на оттачивание навыков и наработку опыта. Это не происходит сразу, нужно несколько лет практики с хорошими проектами.
PPS Если нет определённости, то имеет смысл:
а) Пойти работать в офис новичком (или даже стажером) за малую з/п и с возможностью обучения на реальных проектах. Поймете ваше ли это и получите опыт.
б) Пойти на курсы по этой специализации. Сегодня существует ряд организаций и ВУЗов, обучающих этому. Выберите подходящий и там вам ответят на все вопросы и даже научат пользоваться этими знаниями.
В любом случае, путь самоучки-фрилансера это не самый простой и прибыльный путь. Хотя бы наставник, но нужен.
PPS Материалы для чтения можно легко погуглить. Даже здесь, на Тостере, много раз поднимались вопросы «что почитать» или «что нужно знать» такому-то специалисту. Воспользуйтесь поиском по запросам типа «книги веб дизайн», «что уметь дизайнеру» и т.п. Я серьезно.

Если что-то еще вспомню, то дополню.

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

На собеседовании я обычно прошу выбрать из послужного списка какой-нибудь один проект (на усмотрение самого кандидата - наиболее крутой: в котором было найдено какое-нибудь особенно интересное решение, или использованы какие-нибудь крутые технологии, или решена какая-нибудь нетривиальная задача... короче, которым он сам гордится) и рассказать о нем подробнее, но, опять же, не в смысле, какие именитые были заказчики или как необъятен был бюджет, а в смысле, что он любимый в нем конкретно сделал, чему научился и чего добился. Обычно уже сам выбор достаточно показателен. (Если чел собеседуется, например, на синьера JEE, а в качестве темы выберет написанный в старших классах школы сайт на PHP, на котором была особенно удачная фотография кошки - это уже повод задуматься.)

А дальше, по мере рассказа, начинаю задавать уточняющие вопросики (на вшивость): ага... тесты писали... а какое было покрытие? А как определяли? А в каком порядке выполнятся тесты из одного класса?.. Так, так... JBoss... а какая версия использовалась? Дескрипторы или аннотации? А что нового появилось в следующих версиях? А сервлеты вручную писали? ...ага, SOAP. А из каких трех частей состоит WSDL? А моки в SOAPUI делали? Ну, и далее - вглубь или вширь, по мере объема знаний кандидата.

У такого подхода есть две стороны. Первая: если человеку есть чем гордиться, он начинает с горящими глазами грузить меня техническими подробностями, снимается ситуация стресса. Из режима "теста" мы плавно переходим в режим беседы на профессиональные темы. Если же начинает мямлить что-то про невероятную важность проекта и свою ключевую роль в нем, но на вопросы не может ответить, т.к. "этим он лично не занимался", а "эти решения принимали другие", то с ним очень быстро все становится понятно и беседу на этом можно заканчивать.

И вторая: из резюме зачастую сложно даже предположить уровень "погружения" в отдельные технологии. В беседе удается точно выяснить предположительные сильные стороны кандидата и тогда уже задавать конкретные вопросы, позволяя ему раскрыть глубину познаний.

Еще по поводу отдельных технологий, о которых заходит речь, прошу кандидата оценить свои познания в ней по пятибальной шкале "1 - первый раз слышу, 5 - эксперт". Для экспертов у меня заготовлены конкретные вопросы из жизни, как правило, примеры кода, иллюстрирующие какую-нибудь нетривиальную хреновину, которые я тут же достаю из папочки и предлагаю совместно разобрать. Эксперт в Яве - хорошо! Давай побеседуем о медели памяти, сборщиках мусора или кеше процессора. Эксперт в SQL - замечательно! Давай попробуем оптимизировать запрос. Эксперт в сетях - чудесно! Давай разберемся, почему падает вот этот долбаный сокет. Опять же, цель этого подхода - отнюдь не завалить самоуверенного кандидата, а именно понять, как человек мыслит, как ищет решения проблем, достаточно ли у него для этого знаний и опыта. Не беда, если кандидат погорячился с самооценкой... тут важно не знание ответа, а именно подход к решению проблемы (т.к. от синьера именно таки ожидается решение проблемы, а не констатация ее сложности).

google -> javascript code highlight
например, prismjs.com

Все слои которые находятся внутри Фрейма, автоматически к нему привязываются. Внутри Фрейма, для каждого объекта можно задать позицию, в которой он будет находится при изменении масштаба. Чтобы при деформации Фрейма, объекты внутри не меняли свои размеры, нужно задать слою или группе слоев позицию.



На картинке задана позицию Left - Top, это означает что объект всегда будет привязан к верхнему левому углу.

чтобы не учитывались привязки при изменении размера фрейма зажимайте Сmd (мак) или Ctrl (винда)

https://codepen.io/rishabhp/pen/aNXVbQ
Суть в отслеживании активной section, ну а стили можно повесить любые.

это мульти бэкграуднд.

.container {
   background-image: linear-gradient(rgba(0,200,255,.5), rgba(200,0,255,.5)), url(pic.jpg);
}

https://stackoverflow.com/a/38056246/8288421

WP + ACF = Изи вей)

Если правильно понял:

function download(content, fileName, contentType) {
    var a = document.createElement("a");
    var file = new Blob([content], {type: contentType});
    a.href = URL.createObjectURL(file);
    a.download = fileName;
    a.click();
}

В репозитории есть папка /example с простым примером.
Параметры конфигурации передаются объектом при инициализации.
Cсылка c развернутыми ответами на все вопросы.

Мне кажется, самый простой пример замыкания - это счетчик.

var counter = (function () {
	var current = 0;
	return function () {
		current++;
		return current;
	}
})();

console.log(counter()); // 1
console.log(counter()); // 2

В данном случае мы не имеем доступ к переменной current и функция гарантированно возвращает каждый раз уникальное значение.
Если бы это была простая функция, то переменная, содержащая состояние (current), должна была бы находиться вне функции.

var current = 0;
var counter = function () {
	current++;
	return current;
}

console.log(counter()); // 1
current = 5;
console.log(counter()); // 6

А это уже нарушает принцип "черного ящика", т.к. переменной можно присвоить другое значение в любом месте.

1) учим javascript на нормальном уровне (с осознанием что такое контекст, скоупы, замыкания, прототипное наследование и как вообще ООП в js устроено)
2) разбираемся с MVC и прочими штуками
3) далее читаем документацию к ангуляру и паралельно гуглим статьи отдельные и все такое
4) далее читаем angular styleguide (можно паралельно с документацией)

Все пункты подкреплять практикой.

Конечно можно выложить, только так и назовите репу - учебные проекты.
Как минимум по ним потенциальный работодатель посмотрит на то, как вы оформляете код, насколько читабельно вы все там пишете. Будет видно умеете ли вы организовывать репозиторий и документацию к нему и т.п.