В самом Скетче Gradient Map нету (но может быть есть плагины). take.ms/h01Jb — можно сделать похоже с помощью режимов наложения, но это не совсем то. Можно поиграть с Luminicity и Color, но тяжело управлять самой темной и самой светлой точкой изображения.
Саша, да --save и --save-dev записывают устанавливаемый пакет в package.json в основные, и в девелоперские зависимости соответственно. Но насколько я знаю, нет способа автоматически перенести зависимости из файловой системы в package.json, так как package.json первичен.
HackOwnB:
Когда внутри блока текст и ширина блока уменьшается, количество строк этого текста увеличивается. Если у блока зафиксирована высота, текст вылезет за пределы блока.
Когда внутри блока картинка и ширина блока уменьшается, картинка подстраивается под ширину контейнера и её высота тоже уменьшается. Если у блока зафиксирована высота, под картинкой появится пустое место.
И наоборот, при увеличении ширины блока, под текстом появится пустота, а картинка перестанет помещаться в блоке, если у блока фиксированная высота.
Фиксировать высоту можно, когда вы уверены, что ваш контент не может менять свою высоту при изменении ширины. Иначе, лучше использовать min-height, max-height, чтобы у контента была хоть какая-то свобода.
Евгений Жученко В гитхабе можно (про битбакет точно не скажу). Гитхаб умеет отображать предпросмотр .psd и показывать diff между ними (только как между плоскими картинками), .sketch пока отображать не умеет.
Насчет размера файлов и их количества, при сохранении бэкапов на гитхаб у меня проблем не было, ничего не ругалось. Проекты были обычные, файлы не жирные. Но у гитхаба есть решение для хранения очень больших файлов https://git-lfs.github.com/
Но хранить дизайн-исходники в одном репозитории с кодом на живом проекте может быть неудобно. Читайте, почему Нормален ли такой подход для работы с git'ом(хранение дизайн+код)?
Я рекомендую лить исходники в гитхаб только для бэкапа, чтобы все в одном месте лежало.
На текущих проектах мы используем для исходников invision — там синхронизация с облаком, история версий и прочие плюшки.
- cover и contain сработают, как ожидается — вы ведь в прямоугольник того же размера вписываете вдвое больший фон, что приведет к удвоенной плотности пикселей.
- для повторяющихся фонов указывайте размер в пикселях, какой должен быть у @1x картинки.
Neoline, ВЫ должны остановить это безумие! Спрячьте свой код и никому не показывайте. И своим примером поведите за собой остальных. А будете устаиваться на работу, отправляйте работодателю только zip-архивы со своим портфолио — они это любят.
@darksladen
Есть три правила хорошего тона при работе с Гитом. (На самом деле правил больше, но для ответа на этот вопрос понадобится только три)
1. «Чем чаще коммитишь, тем лучше»
2. «Коммитить нужно только рабочий код»
3. «В сообщение коммита писать не только что ты сделал, но и зачем ты это сделал»
Рассмотрим по порядку.
1) Почему много мелких коммитов лучше, чем один большой?
Потому что легче дебажить, когда diff маленький и с ним легко разобраться. Потому что легче откатить проблемный коммит, не затронув другие рабочие части.
Получается, на каждую реализованную фичу — отдельный коммит, на каждый пофикшенный баг — отдельный коммит.
2) Но если фича, которую я пилю, большая и длинная и занимает несколько дней разработки? Как коммитить только рабочий код и одновременно делать много мелких коммитов?
Пилите фичу в отдельной ветке. Строго говоря, только в master ветке должен быть рабочий код. В своей ветке можно коммитить, когда вы сделали какой-то законченный кусок работы, даже если код еще не рабочий. Свою ветку можно публиковать на гитхаб и синхронизировать так часто, как хочется. Когда фича готова и код рабочий, нужно добавлять свои изменения в общую ветку через pull-request, а не через merge. При слиянии пул-реквеста есть опция — объединить все коммиты из ветки в один и закоммитить его в master. Тогда нерабочий код не попадет в master. После слияния можно удалить свою ветку. В мастере будет один большой коммит, но в истории пул-реквеста сохранятся все ваши шаги.
3) Пишите внятные комменты в коммиты, чтобы можно было разобраться, зачем вы сделали изменения в этом коде. Если фикс не работает или ломает проект в другом месте, тот человек, который будет это исправлять (может быть и вы), должен знать, что именно вы чинили и какого эффекта хотели добиться. Нет смысла писать, что вы меняли — это видно по диффу. Нужно писать, зачем вы это меняли — это поможет в будущем.
Если вы пишете публичный продукт, думайте о сообщении в каждом коммите как о строчке в changelog.
