FabiBoom

Фотошоп
Если слой и/или его стили не растрированы, то кликаем два раза по слою, открывается окно стиля слоя. Переходим на вкладку «Тени» и смотрим значения

Например
box-shadow: inset 0 3px 5px 0 rgba(0,0,0, 0.21);



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

Я делаю систему контроля яркости.
Я хочу настраивать яркость всего (гирлянды, люстры, фонарика, экрана телефона).
В коде выглядит примерно так

class BrightControl
   public void setDefaultBright(Object obj){
         obj.setBright(10);
   }
}

Метод setDefaultBright принимает любой объект. Ведь мне всё равно яркость чего настраивать.
Мой код используют другие разработчики, я не могу контролировать их.
Как мне убедиться, что у объекта, который мне пришел в качестве аргумента, есть метод setBright?
Я пишу интерфейс, и говорю, что метод setDefaultBright принимает только объекты, которые реализуют этот интерфейс.

Если кроме меня самого никто не будет использовать эту систему контроля яркости. То я просто буду держать у себя в голове, что в метод setDefaultBright можно отправлять только объекты, у которых есть метод setBright, но поддержка кода усложняется, через год и не вспомнишь...

1. Создаю каталог для проекта
   
2. Инициализирую Bower
   
3. Устанавливаю нужные пакеты, например, Twitter Bootstrap, Angular, jQuery и т.д.
   
4. Ставлю Grunt, плагины для него и т.д.
   
5. Запускаю EMACS и создаю index.html
   
6. С помощью Emmet создаю шаблон, который уже начинаю заполнять.
   
7. В каталоге src создаю папки less, js и т.д.
   
8. Попутно пишу задачи для Grunt
   
9. Если в выбранном фреймворке не хватает какого-либо класса для стилизации элемента, сначала описываю стили прямо в шаблоне, в свойстве style. Затем при необходимости выношу их оттуда в LESS в виде одного или нескольких классов.
   
10. ??????????
    
11. PROFIT!!!
    

Распределить работу покомпонентно.
Любые макеты можно разобрать на следующие компоненты и этапы.

0. Создается общий репозиторий для проекта.
Все работы ведутся сразу в нем. Чем чаще делаются коммиты, тем раньше вылезут и будут исправлены проблемы. У каждого компонента есть свой css/less/sass файл, чтобы легче управлять кодом и избегать merge-конфликтов.

1. Основные строительные блоки:
- Типографика и стили для контента (таблицы, цитаты)
- Элементы форм + стили валидации
- Декоративная графика (иконки, плашки)
- Модульная сетка (сразу респонсив)

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

2. Повторяющиеся компоненты:
- Навигация
- Ленты новостей, событий, блогпостов, результатов поиска, чего угодно
- Типовые формы (логин, регистрация, поиск)
- Табы
- Слайдеры
- и так далее

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

После этих двух этапов у команды готов UI-kit проекта.

3. Предварительная сборка всех шаблонов страниц с реальным контентом

Работа распределяется постранично. Каждый верстальщик копипастит блоки из UI-кита и наполняет реальным контентом. В конце команда оценивает, где что еще нужно доделать.

4. Редкие кастомные компоненты и модификации

На основе проблем, которые вылезли на третьем этапе, каждый верстальщик допиливает блоки, за которые он отвечает.

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

Обо всем этом говорят Atomic Design, ITCSS и многие другие методологии.

А я думаю, что настоящее развитие может быть только по плану. Однако, ваша самая главная задача сейчас - это хорошо учиться в школе. Выучите веб, но ценой завала школы - глупость неимоверная, преступная. Не надо так спешить, детство даётся один раз в жизни. Не вебом единым жив человек. Не следует думать в отношении некоторых школьных предметов, что "это мне не понадобится". Понадобится всё. Начать с веб можно и с 18 лет - вполне достаточно. Если уж так неймётся - то забросьте пока до 18 лет к чёрту всю эту веб-разработку и основной упор сделайте на изучение английского языка. Станьте асом в английском языке и тогда ваши (российские) конкуренты (со временем) останутся далеко позади - потому что подавляющее большинство российских разработчиков позорно плохо (до смешного плохо) знают английский. Хороший английский - это секретный ключ к успеху в программировании. Не имея навыка смотреть американский фильм с оригинальной дорожкой и понимать (на слух) хотя бы половину - хорошим программистом не стать. Во-первых, бОльшая часть веб-документации - только на английском. Во-вторых - никогда не читайте англоязычную документацию в русском переводе (книги, статьи) - ничего не поймёте правильно - только в оригинале. Потому что перевести такое невозможно - можно только заново написать на другом языке. В-третьих - будете в Турции/Египте летом - сможете больше пообщаться при необходимости.

Изучение английского - это очень временеёмкая задача. Именно в юном возрасте и следует этим заниматься. Потом, после 18, жизнь уже не даст такого шанса, и будете потом постоянно себе говорить - какой же я был дурак, что не изучал его ранее. Можно даже прямо сейчас найти какие-то курсы английского - для детей-подростков это по карману, для взрослых же будут драть втридрога. Не пожалейте никаких усилий ради английского.

Когда вам исполнится 17-18 - вообще забудьте про веб и все силы бросьте на поступление в ВУЗ. И лишь после поступления можно начинать с вебом. Да, и забудьте про компьютерные игры. Прямо начиная с сегодня. Совсем. Навсегда.

Все предыдущие советы даны без учета возраста задающего вопрос. Эти ответы рассчитаны на человека от 18 лет возрастом. Мой же ответ - именно для 14-летнего.

Кэш убивать
Меняешь версию == юзеру гарантированно уйдёт новый, а не закэшированный файл

Грокаем алгоритмы

Да, это нормально. Сам так делал, БЭМ допускает подобный микс.
Вы создаете новый, независимый блок, который можно встроить в article__author, то есть вы сможете встроить этот блок и в другие места, где нужен будет "автор". Единственное, что не понравилось, путаница с названием, как сказал sim3x. Я бы сделал универсальный блок .author, который в зависимости от своего местоположения менял бы какие-то аспекты своего оформления.

стоит ли оно того

Если блок получается большим и состоит из нескольких блоков поменьше, то да. Вы же, надеюсь, не будете делать по десять специфичных классов .{block-name}__btn для каждого блока? Нет, вы сделаете сперва блок .btn, а затем будете миксовать его с .{block-name}__btn, чтобы 90% стилей были из блока .btn, а оставшиеся 10% определялись бы в зависимости от контекста.

киньте ссылку где в документации про это есть

https://ru.bem.info/methodology/quick-start/#Микс

Нет никаких правил как обычно.
Просто должна быть какая-то активность так или иначе связанная с вашими навыками.

В моём круге есть специальный блок для этого: https://moikrug.ru/aksentev-aleksandr

Лучше в отдельной папке, многие верстальщики в конторах делают именно так, потому что пользуются Sass и Gulp. и они имеют привычку создавать для каждой секции на лендинге свой файл со стилями. Даже если Вы так не делаете, то учтите, что потом будет отдельный файл с медиа-запросами, а если сайт многостраничный и страницы сильно отличаются, то для каждой страницы тоже отдельный файл со стилями. Если Вы будете все писать в одном файле, то скоро Вы сами там запутаетесь. а если возвратитесь к нему через некоторое время то тем более, Вы дооолго будете искать что и где подправить. Так что лучше все стили складывать в отдельную папку.))) Для скриптов тоже отдельная папка, как и для картинок, и для шрифтов тоже. Если все будет рядом с index.html, то будет винегрет)))