iMaximus

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

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

Из того, что можно точно выделить:

1. Советы Горбунова. Школа у них чудовищная, но вот в советах очень много полезной информации. И, по-моему, они эти советы перенесли в формат электронных книг. Там и по интерфейсам темы и по академическому дизайну и много ответов на разные вопросы по копирайтингу/менеджменту/развитию. В общем, довольно ценный ресурс.

2. Школа Тильды. Это набор последовательных статей. Там описан в некоторой степени утопичный дизайн-процесс, но именно к такому процессу и нужно стремиться при работе в команде дизайна. Они рассказывают о дизайн-мышлении, о картах, персонажах и прочих ментальных инструментах. Это материал не для новичка, а для мидла скорее. Сейчас большинство крупных западных команд работает в +- подобном ключе.

3. Книга "Психбольница в руках пациентов". Классика. Читается как роман, ставит мозги на место сразу. Ты начинаешь решать задачи, а не рисовать пиксели.

Многие скажут, что нужно обязательно прочитать Тафти. Лично я читал его, но это невероятное занудство — более скучных книг нет на всей планете, наверное. Если ты хочешь быть прям как Бирман какой-нибудь — дотошным любителем схем, инфографики и вот этого всего, тогда это маст рид. Есть еще Раскин, который решил описать работу над интерфейсом в академическом стиле. Тоже считается некоей библией. По занудству находится примерно рядом с Тафти. Но мне кажется, что это примерно как учить английский язык по словарю.

Если же ты работаешь над массовыми продуктами — веб, прилки — лучше потратить время на что-то продуктовое. Лучшая книга для этого — биография Джобса от Айзексона. После прочтения мир как будто проясняется, а до этого ты все время, оказывается, ходил в тумане.

И самое главное — научись верстать. Не просто понять базовые теги html, а по-настоящему. Чтобы твой код был почти готов уйти в продакшен. Ты откроешь для себя сторону дизайна, которая всегда оставалась в тени — то, как твой продукт реально работает, а не то, как ты себе это представляешь, глядя на картинку. Например, ребята из Apple всегда делают сотнями пенопластовые и пластиковые макеты для новых Айфонов, крутят их в руках, ходят с ними в карманах и т.д. Только так можно прочувствовать форму, понять изъяны и улучшить продукт. Картинка ничего не говорит о проекте, нужно уметь ее материализовать. В вебе с этим помогает верстка.

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

брать ли сейчас MacBook 2018 и не превратиться ли он в тыкву

Не бери.

Жди еще 100 лет, пока Apple еще чего нового придумает. И еще придумает. И еще придумает. А там и дилемма твоя сама собой решится: или ты умрешь или Apple разорится.

Покупка компьютерного железа - никакая не инвестиция. Оно дешеветь начинает сразу после покупки и дешевеет постоянно с течением времени. Что бы ты не купил.

Подскажите новичку, как смержить второстепенную (допустим slave) ветку в master, чтобы она заменила все содержимое master своим, а данные из master удалились.

Чтобы был честный мёрж и непрерывная история:

git checkout slave
git merge -s ours master # смёржить master в slave, оставив только содержимое slave
git checkout master
git merge slave

exfat

Конфликт будет, но он должен быть во время pull. Допустим, мы в ветке master:

git commit -m "Мои изменения"
git pull
/// резолвим конфликты
git commit -m "Конфликты зарезолвены"
git push

Резовлит тот, кто делает pull, но он может позвать для консультации всех, кого необходимо. В случае git-flow разработчик работает в ветке feature-branch

git commit -m "Мои изменения"
git pull
/// резолвим конфликты с другими разработчиками, которые разрабатывают feature
git commit -m "Конфликты зарезолвены"
git merge develop
/// резолвим конфликты с мастером
git commit -m "Конфликты с основной веткой зарезолвены"
git push

После этого можно делать pull-request в develop-ветку. Если ветка меняется и снова появляются конфликты - опять делаем merge в feature-branch и push, Pull Request к примеру на ГитХаб обновится автоматически