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 к примеру на ГитХаб обновится автоматически

Можно пойти двумя путями, использовать файлы, удобнее всего json или .plist или использовать целые БД, такие как SQL или Realm например.
Для первого сюжета файлы обычно полностью загружаются в оперативную память (полностью считываются) и ковертируются в стандартную структуру типа словаря или массива. В таком случае ты сам методами языка достаешь случайное значение.
Как читать файлы можно найти здесь stackoverflow.com
Но со вторым вариантом, на мой взгляд, удобнее работать, но сложнее интегрировать, там ты уже запихиваешь все данные в базу, а в приложении подключаешься к базе и средствами базы достаешь случайные значения. Если у тебя большие данные, то лучше использовать второй вариант, но для простоты лучше использовать первый вариант.