Страницы

воскресенье, 6 октября 2013 г.

Colors


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

Итак, начнем с самого начала: теория цвета (eng). Вдохновились? Хочется поиграться с цветами и создать что-то неповторимо свое? Пожалуйста! Сервис для поиска подходящих цветов, укладывающиеся в выбранные схемы, и аналог от Эдоба kuler.adobe.com/create/color-wheel, и еще альтернатива paletton.com. Или воспользуйтесь готовыми палитрами: pltts.me.

Хотите еще больше задротства контроля над цветом? Colors for data scientists - ищите новые цвета и цветовые схемы.

Не нужны такие подробности? Если вы далеки от всего этого, но у вас есть картинка, можно "выделить" из нее 5 основных цветов с помощью одного отличного сервиса. Или же 10 цветов из другого.

Для заболевших тематикой цветов есть даже свое сообщество: COLOURlovers, где вы можете делиться палитрами, обсуждать, исследовать новые цветовые схемы.

Надоели RGB и CMYK? Есть приятная для воприятия и понятная цветовая модель HSL, которую лучше смотреть на примере, да и поиграться можно в HSL Color Picker

И моя любимая статья о том, как лучше всего научиться подбирать цвет: Теория подбора цвета в черепашках от AquaSixio (original)

И напоследок: маленький, но очень любопытный гайд как с помощью черно-белого градиента и нескольких цветов раскрасить героев из Доты: Dota2 Character Art Guide (pdf)

суббота, 28 сентября 2013 г.

Почему я люблю Twitter Bootstrap

Или хороший инструмент для ленивого дизайнера


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

Ответ: ДА. И в первую очередь (!) его должен использовать дизайнер. Потому как он, как правило, ленив и непредсказуем. Сегодня одна кнопень у него выглядит так, а завтра совсем по-другому.

Основные преимущества использования дизайнером бутстрапа:


1. Responsive web-design
Ваш дизайнер рисует только статические странички фиксированной ширины? Твиттер бутстрап позволит использовать его дизайн в большинстве случаев в качестве основы для растягиваемого сайта. Придется продумать расширяемость элементов, дописать стили для разных разрешений экранов, но основа уже будет, а это уже значительно облегчит разработку.

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

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

4. Сокращение времени разработки
Это один из самых важных пунктов, потому что позволяет сократить не только время разработки, но и нервы разработчикам, и код!

5. Сетка и колонки
Если вам не повезло иметь макет без сетки, но с условными колонками. Их всегда можно вписать в уже существующие в бутстрапе колонки. Это структурирует контент.

6. Common stylesheet
Если дизайнер будет полагаться на бутстрап в своих макетах, то нет нужды в создании отдельных страниц с перечнем элементов, потому что на сайте бутстрапа можно посмотреть как выглядит тот или иной элемент. Это также подразумевает предсказуемость поведения элементов. Мы знаем что будет при наведении, фокусе, нажатии и т.п. Как правило, дизайнеры не заморачиваются анимацией элементов и сайт выглядит "плоским" в худшем смысле этого слова.

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

P.S. Хотя я не очень люблю его в силу того, что при большой кастомизации приходится переписывать чуть ли не все стили, так что от самого фреймворка остается только куча неиспользуемых и перезаписываемых файлов. Но для быстрого старта и для работы дизайнера сложно переоценить этот фреймворк.

четверг, 25 июля 2013 г.

Hack-week-2, random color.

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

var stringToColour = function(str) {
    var hash = 0;
    for (var i = 0; i < str.length; i++) {
        hash = str.charCodeAt(i) + ((hash << 5) - hash);
    }
    var colour = '#';
    for (var i = 0; i < 3; i++) {
        var value = (hash >> (i * 8)) & 0xFF;
        colour += ('00' + value.toString(16)).substr(-2);
    }
    return colour;
}

$('body').css('background-color', stringToColour("my string"));

Казалось бы, просто прикольный код. Но гораздо интереснее когда и как его можно было бы применить. Поскольку цвет задается рандомно, но в то же время он постоянен для определенной строки, его можно было бы использовать для:
  • раскрашивания карты, например, у нас есть карта Европы в виде символьного шрифта;
  • раскрашивания графиков, где название секции/столбика так же уникально;
  • в чате выделение имени пользователя;
  • задание фона на месте аватарки у пользователя без аватарки, как это сделано в Google mail на Андроиде;
  • пользовательские теги в различных приложениях (почте, соц.сетях и проч.);
  • и проч.

вторник, 11 июня 2013 г.

Верстаем иконки под планшеты/мобильные устройства

Сложность верстки под планшеты и мобильные устройства не только в том, чтобы сделать responsive веб-дизайн, что само по себе большой труд и дизайнера, и верстальщика. Суть также в том, что кроме огромного набора размеров экрана мы еще получаем и разное количество пикселей на дюйм, именуемое как device-pixel ratio (тут можно подробнее почитать на англ.). Беда в том, что это соотношение не стандартизировано и в итоге у нас получается что-то вроде:

-webkit-min-device-pixel-ratio Устройство
1.0 All non-Retina Macs
All non-Retina iOS devices
Acer Iconia A500
Samsung Galaxy Tab 10.1
Samsung Galaxy S
1.3 Google Nexus 7
1.5 Google Nexus S
Samsung Galaxy S II
HTC Desire
HTC Desire HD
HTC Incredible S
HTC Velocity
HTC Sensation
2.0 iPhone 4
iPhone 4S
iPhone 5
iPad (3rd generation)
iPad 4
All Macs with Retina displays
Google Galaxy Nexus
Google Nexus 4
Google Nexus 10
Samsung Galaxy S III
Samsung Galaxy Note II
Sony Xperia S
HTC One X
3.0 HTC ButterflySony Xperia S

А это чревато тем, что картинки, рассчитанные на стандартное разрешение, будут смотреться "размытыми" и пиксельными.

1. Одна большая картинка

Самое простое решение состоит в том, чтобы сделать картинку самого большего размера, то есть с device-pixel ratio = 3 и масштабировать при отображении в заданную область. Но в этом случае при просмотре на мониторе (device-pixel ratio = 1) мы также будем грузить картинку в 3 раза большую, чем нам необходимо.

2. Картинки разных размеров

Другой способ позволяет загружать картинку в соответствии с разрешением экрана. Для этого мы добавляем картинки соответствующего размера (т.о. к одной logo.png добавляются logo@1.25x.png, logo@1.3x.png, logo@1.5x.png, logo@2x.png и logo@3x.png) и вводим дополнительные css-свойства на проверку -webkit-min-device-pixel-ratio и min-resolution (подробнее об этих свойствах на англ).

В результате получаем:

.logo {
  background-image: url('logo.png');
  background-size: cover;
  height: 30px;
  width: 60px;
}

@media 
(-webkit-min-device-pixel-ratio: 1.25), 
(min-resolution: 120dpi){ 
  .logo {
    background-image: url('logo@1.25x.png');
  }
}

@media 
(-webkit-min-device-pixel-ratio: 1.3), 
(min-resolution: 124.8dpi){ 
  .logo {
    background-image: url('logo@1.3x.png');
  }
}

@media 
(-webkit-min-device-pixel-ratio: 1.5), 
(min-resolution: 144dpi){ 
  .logo {
    background-image: url('logo@1.5x.png');
  }
}

@media 
(-webkit-min-device-pixel-ratio: 2), 
(min-resolution: 192dpi){ 
  .logo {
    background-image: url('logo@2x.png');
  }
}

@media 
(-webkit-min-device-pixel-ratio: 3) { 
  .logo {
    background-image: url('logo@3x.png');
  }
}

Довольно большие конструкции, и как вариант можно было бы ограничиться двумя выборками: с коэффициентов = 1.5 и 3.0, совместив с первым методом растяжения картинки на всю ширину. Это было бы актуально для Kindle Fire HD 8.9, у которого device pixel ratio = 3.75, а значит он не попадал бы в вышеуказанные условия.

3. SVG

Более изящным и современным решением было бы использование SVG (от англ. Scalable Vector Graphics — масштабируемая векторная графика), который на данный момент поддерживается чуть ли не всеми браузерами (мы практически избавлены от геммороя прошлых лет), но если нужна поддержка Всех, то для них необходимо дополнительно хранить картинку в *.png.

Интересный метод предложил Peter Gasston. Он (метод) основан на использовании множественного бэкграунда и идеи, что если браузер не поддерживает это свойство, он не поддерживает и svg формат. Выглядит примерно так:
p {
  background-image:  url('image.png');
  background-image:  none,url('image.svg'), url('image.png');
  background-size: 100% 100%;
}
Но к сожалению в основном такая неподдержка есть в ие8 и ниже, а так же Android 2.3, для для андроида этот способ никак не спасает, потому что он поддерживает множественное фоновое картинкообразование, но не поддерживает svg ((
Поэтому для динозавра ие я предпочитаю добавленный *.png показывать с помощью хака "\9", который распознается ie <= 8. Это можно удобно оформить в отдельный миксин на sass:

@mixin image_svg($url, $options) {
  background: image-url($url + '.svg') $options;
  background: image-url($url + '.png') $options \9;
}

p {
  @include image_svg("logo", 10px 5px no-repeat);
}

А вот с Android 2.3 все-таки будем в пролете =/
Чтобы совсем уже красиво замещать svg на png, можно при загрузке страницы делать проверку и добавлять класс для body:

if (!document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Image", "1.1")) {
  $('body').addClass('no-svg');
}
А в стилях выводить нужные урлы на иконки:

p {
  background-image:  url('image.svg');
}
.no-svg p {
  background-image:  url('image.png');
}

Perfect!

Один момент, в котором svg может проигрывать png - это размер файла. Но и тут легко быть на коне с помощью svgz, который сжимает svg утилитой Gzip до приемлемого  размера.

4. @font-face

Безусловно, на этом можно было бы и остановиться, но что если на сайте есть несколько небольших монохромных иконок, которые можно было бы засунуть в какой-нибудь один удобный спрайт? Что если использовать свой шрифт, в котором будут все необходимые иконки? Суть в том, что каждая иконка представлена определенной буквой шрифта, т.о. она получает свой векторный эквивалент и может масшабироваться как шрифт и иметь те же самые css-свойства, что и у текста.

Делается это за 5 минут:

С помощью шрифтобелки (или любой другой подобной штуки) генерируем из исходного шрифта myfont-webfont.ttf еще несколько форматов:
  • myfont-webfont.eot
  • myfont-webfont.svg
  • myfont-webfont.woff
Далее подключаем их через @font-face и используем:
@font-face {
  font-family: 'myfont-webfont';
  src: url('/font/myfont-webfont.eot');
  src: local('/font/myfont-webfont'),
       url('/font/myfont-webfont.woff') format('woff'),
       url('/font/myfont-webfont.ttf') format('truetype'),
       url('/font/myfont-webfont.svg#webfont') format('svg');
}

body {
  font-family: myfont-webfont, Times New Roman;
}

Вуаля! =)

Если сет определенных иконок используется в нескольких проектах, имеет смысл сделать его гемом.

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

5. custom font

К счастью, есть замечательный генератор Font Custom, который делает за нас всю грязную работу, а именно: одной командной строкой перефигачивает все svg в один большой и могучий шрифт, на лету создавая различные вариации! Т.о. не нужно заботиться о шрифте, нужно просто складывать все svg в одну папку.

Что нужно для этой далеко не уличной магии?
Если вы работаете на Mac OS, необходимо присутствие xcode. (Под Линукс данная магия тоже работает, но мной не опробована). Далее ставим fontforge и сам гем FontCustom v1.0.0:
brew install fontforge eot-utils ttfautohint
gem install fontcustom
После создаем пути к папке, где будут храниться наши svg файлы, и к папке, в которую сгенерируется шрифт. Все. Следующая строчка выполняет преобразования и наш шрифт готов:
fontcustom watch app/assets/images/svg -o app/assets/stylesheets/iconfont -t scss

Теперь при добавлении еще одной svg-иконки нам нужно будет только заново запустить эту строку, которую возможно удобно было бы оформить в rake task.

Для рельсового проекта также добавляем в Gemfile (не забыв про последующий: bundle install):
gem 'fontcustom'
А в css делаем импорт стилей:
@import "_fontcustom";
Использование очень похоже на бутстраповское: для добавления к элементу иконки добавляем нужный класс.
<a class="icon-menu" href="#">item</a>
где в имени класса "icon-" - это префикс, а "menu" - это название svg-файла.

Мне безумно нравится этот вариант, но хотелось бы знать: оправдано ли использование в каком-то конкретном случае, или все же лучше подгружать svg?

Статистика по @font-face:

Немного статистики. Для примера я взяла три небольшие иконки со своими особенностями:

  1. Пиксельная иконка, для которой характерны четкие линии в 1 пиксель.
    1x: ; 1.5x: ; 3x:
    SVG представление:
    <svg enable-background="new 0 0 15 19" height="19px" id="Layer_1" version="1.1"
    viewbox="0 0 15 19" width="15px" x="0px" y="0px" xml:space="preserve"
    xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg">
    <g>
      <rect height="1" width="15" x="0" y="0">
      <rect height="1" width="15" x="0" y="18">
      <rect height="19" width="1" x="0" y="0">
      <rect height="19" width="1" x="14" y="0">
    
      <rect height="4" width="7" x="4" y="3">
    
      <rect height="1" width="7" x="4" y="10">
     <rect height="1" width="7" x="4" y="12">
     <rect height="1" width="7" x="4" y="14">
    </rect></rect></rect></rect></rect></rect></rect></rect></g>
    </svg>
  2. Иконка паучка.
    1x: ; 1.5x: ; 3x:
    Исходный код SVG взят здесь.
  3. Иконка состоит из двух палочек, одна из которых имеет прозрачность 0.6:
    1x: ; 1.5x: ; 3x:
    SVG код:
    <svg enable-background="new 0 0 12 14" height="14px" id="Layer_1" version="1.1"
    viewbox="0 0 12 14" width="12px" x="0px" y="0px" xml:space="preserve" 
    xmlns:xlink="http://www.w3.org/1999/xlink" xmlns="http://www.w3.org/2000/svg">
    <g>
     <rect height="14" width="5">
     <rect height="14" opacity="0.6" width="5" x="7">
    </rect></rect></g>
    </svg>

Посмотрим как они будут рендериться разными браузерами (масштаб 4:1, чтобы не напрягать глаза):


Как видно, полупрозрачность игнорируется в иконко-шрифте, чего и следовало ожидать. Паучок выглядит отлично, несмотря на то, что в Firefox'е смотрится немного жирнее, но в целом на отлично. А вот пиксельная графика абсолютно не подходит для отображения в виде шрифта, потому что только IE10 смог корректно отбразить без лишнего сглаживания.

Т.о. можно сделать выводы какими должны быть иконки для того, чтобы использование иконко-шрифта оправдывало себя. (Здесь идет самостоятельная работа).

Второй вопрос: какой минимальный набор иконок нужно иметь на сайте, чтобы оправдана была генерация шрифта? Думаю, никто не станет спорить, что для двух-трех иконок нет смысла создавать отдельный шрифт. Поэтому думаю, что это нужно рассматривать отдельно для каждого проекта. Вот, к примеру статистика по этим трем иконкам:

svg, bytes ratio = 1, bytes ratio = 1.5, bytes ratio = 3, bytes
(15x19) 755 162 394 184
(15x21) 7,493 379 518 686
(12x14) 476 135 142 149
Общий размер 8,724 822 1,054 1,019

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

имя файла размер
_fontcustom.scss 955 bytes
fontcustom.eot 2,692 bytes
fontcustom.svg 7,164 bytes
fontcustom.ttf 4,996 bytes
fontcustom.woff 1,672 bytes

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

Но прежде чем использовать, хотелось бы подумать еще вот о чем: мы засовываем в иконко-шрифт все svg-картинки, а их может быть и 30 и 50, в то время как на одной странице нам могут понадобиться только три из них, а на другой всего одна, но шрифт уже загружен. И тут важно подумать как часто пользователь будет смотреть на страницу с 1 иконкой, с тремя и с 30-ю.

На мой взгляд, именно из-за уникальности каждого проекта (и отсутствия панацейи), стоит выбирать те методы, которые лучше подходят. Для начала ответить на ряд вопросов:
  • Как много графики в проекте?
  • Требуется ли поддержка ie8 или меньше? или android 3.0 или меньше?
  • Есть ли одноцветные небольшие иконки? Как много?
  • Есть ли пикельно-зависимые иконки?

P.S. И на последок: статья об использовании иконок в стилях, но что если мы хотим применить responsive web-design для картинок, подключаемых непосредственно в html? Тут тоже есть свои методы.

пятница, 19 апреля 2013 г.

OdessaJS


13 апреля прошла еще одна конференция по js: OdessaJS, на которой мне посчастливилось побывать. В отличие от Киевской эта мне понравилась гораздо больше как организацией, так и темами докладов. Неинтересных или скучных просто не было! А так же пиченьки, кофе, чай, конфеты, магнитики, блокнотики и прочее-прочее... Понравился большой зал, в котором проходила конференция. Людей было не так много и всем хватило места, никто не стоял даже в малом зале (доклады проходили в два потока).

А теперь к сути:

Эльдар Джафаров "Your project tested."

Один из самых впечатливших меня докладов, потому что рассказывал о тестировании приложений на js. Меня удивило обилие инструментов для тестирования, ни один из которых я не использовала, но которые представляют определенный интерес. О каждом стоило бы рассказать отдельно хотя бы в двух словах.

Code testing

- Jshint - тоже, что и jslint, но еще и позволяет тестировать код и стиль написанного кода.

Unit testing

- Mocha - фреймворк для тестирования асинхронного кода на node.
- chai - BDD / TDD assertion library for node. Отлично работает в связке с другими библиотеками для тестирования
- Sinon - Standalone test spies, stubs and mocks for JavaScript. No dependencies, works with any unit testing framework.
- rewire - Dependency injection for node.js applications.

Integration testing

- Nock is an HTTP mocking and expectations library for Node.js
- localtunnel - expose yourself to the world

Front-end unit testing

- Testacular-karma - Spectacular Test Runner for JavaScript
- jasmine is a behavior-driven development framework for testing JavaScript code

Functional testing

- PhantomJS (headless WebKit scriptable with a JavaScript API) + require('wd')

Андрей Листочкин "NodeJS - за гранью здравого смысла"

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

Александр Соловьев "FRP & ClojureScript"

Яваскрипт на лиспе... в этом определенно что-то есть )

Егор Львовский "Dart, в яблочко"

Хорошее введение в Dart, с кучей картинок и примеров. Хотя меня больше поразила производительность. Это то, ради чего стоило бы его использовать!

Ксения Редунова "Магия RaphaelJS"

О! про этот доклад можно было бы написать отдельную статью =)
Но если в двух словах, то Raphaёl - это библиотека для работы с векторной графикой. Огромное количество функций для работы с векторными объектами и сетами, задание анимании и прочее. На выходе генерирует svg и vml (для олдскульной ие).

Артем Тритяк "CoffeeScript a-zA-Z"

К сожалению на этот доклад не попала, ибо пошла за Рафаэлем.

Дима Миндра "TypeScript ннада?"

Лично я для себя решила, что не надо. TypeScript по сути добавляет типы в яваскрипт. Весьма сомнительная полезность. Кода больше, а проверка типов остается только проверкой типов и не страхует от других возможных ошибок ((

Вячеслав Потравный "ChaplinJS или чего нам не хватает в Backbone"

Еще один доклад про Chaplin. Понравился объективностью. А то надоели все эти хвастливые "это работает из коробки и все так круто! Давайте писать только на этом". Нет еще такой панацеи, а все эти сверхвосторженные рукоплескания воспринимаю не иначе как пиар. Нет еще такого языка/плагина/библиотеки, которая бы решила все и вся. Этим понравился доклад, что все было достаточно объективно, есть свои плюсы и есть свои минусы. А как иначе?

И немного lightning talks в конце дня:

Artyom Trityak ‏about Backbone Chaplin vs Marionette
Роман Чепляка "To block or not to block" (про веб-апликушечки)
Alexander Solovyov "Интернационализация в браузере" (github)


среда, 27 марта 2013 г.

Прозрачный однородный фон

Есть несколько способов, которыми можно сделать однородный прозрачный фон на сайте.
Рассмотрим на примере:
- нужно получить темно-иссиня-серый фон #3b4044 с прозрачностью слоя 0.75.

1. RGBA(59, 64, 68 .75)


Это первое, что приходит на ум. Отличный вариант для быстрого задания цвета с прозрачностью. Даже разложение 16-ричного определения цвета на три 10-ричных канала не представляет сложности. Но есть одна проблема: не работает в ie8 =(

2. Opacity(.75)


Второе, что приходит на ум. Сделать фон одноцветным и добавить прозрачность. Работает даже в ie5 с помощью дополнительных фильтров:

-ms-filter: "progid:DXImageTransform.Microsoft.Alpha(Opacity=75)"; /* IE 8 */
filter: alpha(opacity=75); /* IE 5-7 */

Уже лучше, но у этого свойства есть один серьезный недостаток: opacity добавляет прозрачность блоку, а соответственно и всему внутреннему контенту, так что нам это тоже не подойдет.

Да еще и сглаживание шрифтов нарушается в ie ((

3. background: url(image)


Старый, добрый, проверенный вариант. Делаем картинку размер 1px на 1px нужного цвета и прозрачности, сохраняем как png и вставляем фоном. Все отлично работает, разве что мы имеем еще один маленький запрос на сервер за картинкой.

Это лечится следующим способом:

4. background: url('data:image/png;base64,...')


Перевод изображения в формат base64, таким образом картинка кодируется и вставляется непосредственно в css.

Вот несколько сайтов для конвертации image to base64:


В итогде получаем:

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAYAAAAfFcSJAAAAGXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAAAAA9JREFUeNpisHZ03Q8QYAAC/QGBtfPbbQAAAABJRU5ErkJggg==

Size increased from 109 to 148 (36%)

вторник, 5 марта 2013 г.

Git

Недавно прошла замечательный курс: http://gitreal.codeschool.com/
Открыла для себя несколько забавных команд, которыми можно было бы поделиться

Начальные установки:

  • git config --global user.name "Admin Adminkovi4"
    установка имени пользователя
  • git config --global user.email "admin@mailinator.com"
    установка емэйла пользователя
  • git init
    инициализация гита

Общие команды:

  • git blame index.html --date short
    просмотр в указанном файле построчно: кто и когда последний менял каждую строчку кода (короткий формат даты)
  • git help config
    показать хэлп указанной команды, в данном случае config
  • git log
    показать логи
  • git status
    показать статус
  • git diff
    показывается изменения между коммитами
  • git diff --staged
    показывается staged изменения между коммитами
  • git diff HEAD~5
    показывается изменения между последними пятью коммитами и текущим состоянием
  • git diff sha1..sha2
    показывается изменения между коммитами от sha1 до sha2
  • git diff master bird
    показывается изменения между коммитами на master и на ветке bird
  • git check­out -- cats.html
    отменяет изменения в указанном файле (восстаналивает файл из индекса)

    При этом команда git check­out cats.html работает так:
    если есть ветка с именем cats.html, то произойдет переключение на эту ветку. Для того, чтобы этого не произошло можно сделать git checkout -- cats.html, тогда гит будет точно знать, что нужно восстановить файл, а не переключиться на ветку.

    Кроме того файл можно восстанавливать не только с текущего индекса, а, например, так:
    git checkout master~2 cats.html
    тогда cats.html будет взят из версии мастера на 2 коммита раньше

Работа с коммитами:

  • git add --all
    аналог git add .
    (добавить все измененные файлы в коммит)
  • git commit -a -m "Comment"
    заменяет две команды:
    git add .
    git commit -m "Comment"

  • git commit --amend -m "Comment"
    добавляет изменения к прошлому комиту и меняет сообщение на новое
    (хак, который нужно аккуратно использовать)
  • git reset --soft HEAD^
    удаляет последний коммит, а изменения остаются незакоммиченные
  • git reset --hard HEAD^
    удаляет последний коммит и все изменения в нем
    аналогично:
    git reset --hard HEAD^^ - удаляет два последних коммита и все изменения
    git reset --hard HEAD~5 удаляет два последние 5 коммитов и все изменения
  • git push -u origin master
    -u пишется в первый раз, чтобы потом запомнить позицию и можно было писать просто git push

Работа с удаленным сервером и удаленными ветками:

  • git remote add origin http://githunb.com/blabla.git
    создание нового удаленого сервера с именем origin
  • git remote -v
    просмотр списка удаленных серверов
  • git remote rm origin
    удалить удаленный сервер (масло масляное? ^_^)
  • git remote show origin
    показывается информацию об удаленном сервере
  • git remote prune origin
    удаляет локальные ветки, которых больше нет на удаленном сервере
  • git branch -r
    показывает список всех удаленных веток
  • git push origin :name_branch
    удаляет удаленную ветку name_branch

Теги:

  • git tag -a v0.0.3 -m "version 0.0.3"
    добавляет новй тег с именем v0.0.3
  • git push --tags
    пушит новый тег

Конфигурация и логирование:

  • git config --global color.ui true
    раскрашивает логи =)
  • git config --pretty=oneline
    выводит логи в сокращенно одну строчку
  • git log --pretty=format:"%h %ad- %s [%an]"
    вывод логов в указанном формате, где
    %ad - author date
    %an - author name
    %h - SHA hash
    %s - subject
    %d - ref names
  • git log --oneline -p
    вывод логов с выводом измененных строчек
  • git log --oneline --stat
    вывод логов с выводом статистики изменений
  • git log --oneline --graph
    вывод логов в виде графического дерева коммитов
  • git log --until=1.minute.ago
    вывод всех логов до указанной даты
  • git log --since-1.day.ago
    вывод логов начиная с указанной даты
  • git log --since=2012.01.01 --until=2013.12.31
    вывод логов во временном промежутке
  • git rm --cached development.log
    гит перестает следить за указанным файлом и удаляет его из гита, но не локально
  • git config --list
    посмотреть список конфигураций
  • git config --global core.editor emacs
    исползовать emacs в качестве интерактивных команд
  • git config --global merge.tool opendiff
    использовать opendiff для мержа конфликтов (работает только в OS X)

Алиасы:

  • git config --global alias.mylog \
    "log --pretty=format:'%h %s [%an]' --graph"

    задание алиаса для лог формата
  • git config --global alias.st status
    создание сокращения, отныне git st аналогичен команде git status

среда, 27 февраля 2013 г.

Background images in print css

При создании стилей для печатной версии сайта нужно помнить о том, что не всегда у пользователя будет стоять галочка "Print Background Images". Но что если нам нужно распечатать фоновое изображение, которое несет некий важный смысл, не привязываясь к настройкам пользователя? Неплохим решением было бы сделать его картинкой и вывести в псевдоэлементе :before

  .arrow {
    background: none;

    &:before {
        content: url('arrow.png');
    }
  }

Но данный метод плохо работает в firefox и ie, потому как при первой загрузке (печати) данная картинка не успевает загрузится и на ее месте мы ничего не увидим. При повторной попытке печати, все будет ок, но будет ли пользователь второй раз печатать?

Решение - заменить фоновую картинку дефолтной картинкой списка:

  .arrow {
    background: none;
    display: list-item;
    list-style: url("arrow.png");
    margin-left: 20px;
    width: 0;
  }

При этом важно, чтобы данная картинка была уже загружена в display версии сайта и не заменялась на другую.

CSS3 tooltips

Toolips (подсказки) можно организовать несколькими способами:

1. используя атрибут title


<a href="#" title="usual tooltip">Link</a>

Самый простой способ, но тултипы получаются стандартными и поэтому оооочень скуууучни. К тому же их вид зависит от браузера (( Т.е. почти все браузеры отображают их небольшими желтыми лейбочками внизу, но они совершенно не поддаются стилизации.

2. при помощи js (jQuery Tooltip Plugin)


<div id="tooltip">
...
</div>
Как правило, эта конструкция добавляется в низ страницы и абсолютно позиционируется применительно к нужному элементу.

Тултипы красиви, сочни, вкусни. Но для тех, кто не боится нагружать клиента ещё одним ломтиком яваскрипта.

3. css


<a href="#">
  Link
  <span>Tooltip<span>
</a>
Хорошая альтернатива яваскриптовому решению. Присутствуют все нужные плюшки, разве что не очень семантично, отчего ссылка перегружается излишней информацией.

4. css3

<a href="#" data-tooltip="tooltip" >
  Link
</a>

Та-дамм!! Усовершенствованный метод + семантика. Впрочем, достоинства и недостатки обсудим позже, после рассмотрения подробностей реализации =)
Реализуем пример справа:

HTML:

<a href="#" data-tooltip="Beautiful tooltip">Link</a>

CSS:

*[data-tooltip] {
  position: relative;
  text-decoration: none;

  &:after,
  &:before {
    @include opacity(0);

    content: '';
    outline: none;
    z-index: 3;
  }

  &:hover,
  &:focus {
    &:after {
      @include border-radius(2px);
      @include opacity(1);

      background: #464746;
      bottom: 115%;
      color: #fff;
      content: attr(data-tooltip);
      display: block;
      font-size: 12px;
      font-weight: normal;
      left: -50%;
      line-height: 1.3em;
      min-height: 13px;
      outline: none;
      padding: 7px 10px;
      position: absolute;
      text-align: left;
      text-shadow: none;
      max-width: 250px;
    } 
  }
}

Как это работает:

текст тултипа описывается в аттрибуте ссылки data-tooltip, показывается он через псевдоэлемент :after, а добавляется в стилях через свойство content: attr(data-tooltip). Далее просто добавляется позиционирование и стилизуется по макету.

+ Advantage:

  • work in IE8+, Chrome 4+, Safari 4+, Firefox 3.6+ and Opera 10+;
  • quicker than js;
  • more comfortable on iPad

- Imperfection:

  • can't use html tags inside tooltip;
  • not for <img />;
  • title for <a> must be removed.

Arrows:

Подобным образом (с использованием псевдоэлементов :after и :before) можно организовать и простые стрелки, не требующие наличия тени или сложных градиентов.

*[data-tooltip] {
  &:hover,
  &:focus {
    &:before {
      @include opacity(1);

      border-bottom: transparent;
      border-left: 6px solid transparent;
      border-right: 6px solid transparent;
      border-top: 6px solid #464746;
      content: '';
      outline: none;
      display: block;
      font-size: 0;
      height: 0;
      left: 8px;
      line-height: 0;
      position: absolute;
      top: -15%;
      width: 0;
    }
  }
}

+ Advantage:

  • no image

- Imperfection:

  • can't use shadow or gradient, just solid


понедельник, 28 января 2013 г.

Прижимаем футер к низу

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

Отказ от поддержки ie7 позволяет использовать гораздо более элегантное решение для прибития футера, которое основано на использовании свойства display: table/table-row.

Подсмотрено тут:

HTML


<div class="wrapper">
    <div class="content">
        <h2>Content</h2>
        <p>Lorem Ipsum is simply dummy text of the printing and
           typesetting industry. Lorem Ipsum has been the
           industry's standard dummy text ever since the 1500s
           when an unknown printer took a galley of type and
           scrambled it to make a type specimen book. It has
           survived not only five centuries, but also the leap
           into electronic typesetting, remaining essentially
           unchanged. It was popularised in the 1960s with the
           release of Letraset sheets containing Lorem Ipsum
           passages, and more recently with desktop publishing
           software like Aldus PageMaker including versions of
           Lorem Ipsum.</p>
    </div>
    <div class="footer">
        <h3>Sticky footer</h3>
        <p>Footer of variable height</p>
    </div>
</div>

CSS


html, body {
    height: 100%;
    margin: 0;
}
.wrapper {
    display: table;
    height: 100%;
    width: 100%;
}
.content {
    display: table-row;
    height: 100%;
}
.footer {
    display: table-row;
}

вторник, 8 января 2013 г.

Вендорные префиксы

Что такое вендорные префиксы знают все!
Вкратце: вот они родимые (основные):
  • -o- (Opera Software)
  • -moz- (проект Mozilla)
  • -ms- (Microsoft)
  • -webkit- (Apple)
Есть и другие, малоизвестные и не столько популярные, но нам для рассмотрения с головой хватит и этих. Думаю, никто не обидится, если я назову их "костылями"? Итак:

Стоит ли использовать префиксы?

Конечно же стоит!
Вернее даже не так, правильней задать вопрос: можем ли мы НЕ использовать префиксы? Пожалуй, что нет. А отсюда вытекает другой вопрос: была ли это хорошая идея разработчиков браузерных движков добавлять префиксы?

Прежде чем кивать головами как собачки на панелькой доске, предлагаю обсудить несколько моментов. Начнем с истоков:

Спецификации и W3C

Префиксы появились в те далекие времена, когда спецификация CSS 2.1 сказала, мол, вот вам индикаторы, пусть они начинаются с "-" или "_", играйтесь на здоровье, это будут ваши персональные, уникальные свойства! И браузеры подумали: "Ачуметь! Дайте две!" Нет, конечно же браузеры не могут думать, если под словом "думать" не подразумевать искусственный интеллект и все такое. Подумали и обрадовались разработчики браузеров, что они могут извращаться по полной, и привнести это в свои детища!

Идея была отличная! На тот момент. Но крайне недальновидная.

Потихоньку начали появляться реализации новых свойств css3. Они появлялись в то время, как спецификации css3 ещё не было, не было даже кандидатов релизы, но об этом уже все говорили. Все ждали CSS3 спасения нововведений и уже начали внедрять новые свойства как модно нынче писать "на свой страх и риск".

Но, как мы знаем, воз и ныне там? w3c не торопилась: то ли из желания впихнуть максимум в новую 3-ю версию, то ли из желания угодить всем, то ли из-за собственной огромной неповоротливости.

Так вот, браузеры начали обзаводится новыми свойства со своими персональными префиксами. Типа и овцы целы, и волки сыты (и новые свойства есть в браузере, и спецификации не противоречат). Парадоксально, но именно благодаря этому браузеры стали на шаг впереди спецификации. И тут на горизонте появляется еще один вопрос: при такой сумасшедшей популярности новых свойств, стоило ли их писать с префиксами?

Рассмотрим несколько вариантов развития сюжета на примере border-radius.

Исходные данные: это новое свойство и его ни у кого ещё нет.

Вариант 1.
Один браузер решил, что это будут выпуклые уголки и реализовал у себя со своими персональными префиксами.
Будут ли верстальщики его использовать? Нет. Зачем использовать то, что работает только в одном браузере, тем более, что с костылем? Потому что для остальных надо по-прежнему использовать картинки.

Вариант 2.
Один браузер решил, что это будут вогнутые уголки, а не выпуклые. Сказано - сделано!  А потом другие браузеры это внедрили у себя, только с выпуклыми уголками. Первый браузер-бедолага посмотрел на это дело, подумал, как он нехило лоханулся и в следующем своем релизе поменял вогнутость на выпуклость. Всё равно на данном этапе разработчики не использовали бы данное свойство, а если бы использовали и ругались на неадекватность, то, как модно сейчас писать, "на свой страх и риск", да и вообще какие претензии? Самое главное, что браузер (ну вы поняли, что за ним стоят пчелки-программисты) осознал свою ошибку и исправился.

Вариант 3.
Несколько браузеров реализовало это свойство разными методами. Более сложный случай варианта номер 2. Пока что гипотетический, я еще не встречала настолько разную реализацию. Но в этом случае придется договариваться. Сложно, больно, но что делать? Именно для этого есть официальная спецификация, так что такие сложности можно было бы оставить до выхода кандидата в релизы.

Вариант 4.
Идеальный вариант, когда несколько браузеров одинаково реализовали каждый у себя со своим префиксом. Возникает вопрос: почему бы им изначально не использовать новое свойство без префиксов? Вы скажете, что на это нет спецификации. Ну так ее может и не быть ещё очень долго, но в действительности мы получаем следующие конструкции:

.box_rotate {
  -webkit-transform: rotate(7.5deg);  // Safari 3.1+, Chrome 
     -moz-transform: rotate(7.5deg);  // Firefox 3.5-15 
      -ms-transform: rotate(7.5deg);  // IE9+ 
       -o-transform: rotate(7.5deg);  // Opera 10.5-12.00 
          transform: rotate(7.5deg);  // Firefox 16+, Opera 12.50+ 
}

Т.е. по сути все поняли правильно, просто им сложно отказаться от префиксов или они боятся ошибиться, но в этом нет ничего плохого. Как я уже писала, не страшно ошибиться, главное уметь признать ошибку.

Поэтому на этапе разработки считаю префиксы ненужными, если изначально достаточно правильно понять название свойства.

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

Сложности первой реализации

Под первой реализацией будем понимать первую реализацию нового свойства у браузера. И сложность состоит в том, что каждый браузер имеет свое видение. Вспомним пример про вогнутые и выпуклые уголки border-radius. Но это вымышленный пример, лучше посмотрим на реальный: поле даты с выпадающим календариком (прощай datepicker.js!):

<input type="date">

Как это выглядит на данный момент в винде:

Chrome:
Opera:
Safari:

Как мы видим, у каждого своя реализация. Сафари вообще не подумала о выпадающем списке, а две дурацкие "кнопочки" просто листают дни (примечательно, что в <input type="datetime-local" value="2013-01-06 12:01:00"> они листают минуты ^_^). На самом деле это неважно! Это первая, "прикидочная" реализация. И ничто не мешает поменять в следующих версиях, расширить добавить стилизацию через css.

Прелесть html в том, что у них нет "префиксов" и никого это не смущает. Если появится некий стандарт на данную форму, то они просто его внедрят! Всё просто. Css есть чему поучиться ;)

Валидация

Важным аргументов для использования вендорных префиксов является валидация, потому что она игнорирует префиксы. Мне интересно почему? т.е. так ли адекватна и востребована валидация, как мы думаем? Если она позволяет по сути вставлять любые конструкции и игнорировать их при валидации?

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

Лет 10 назад было модно ставить на свой сайт значки w3c css & html validation. Сейчас же этим никто не заморачивается.

Поддержка чужих префиксов

На данный момент возникает ещё одна абсурдность, когда браузеры начинают поддерживать чужие префиксы. Так, например, Opera заявила, что будет поддерживать -webkit-.

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

Даже w3c рассматривают как стандарт поддержку префикса -webkit всеми браузерами!
Это epic fail префиксов. Из некогда прогрессивной идеи они превращаются в довольно грубый артефакт, от которого следовало бы избавиться.

Сложность поддерживать префиксы

Если посмотреть на историю развития браузеров, то она будет пестрить и префиксами (с различными вариантам, вспомним фильтры в ie7 и ie8), и "чистыми" css-свойствами.

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

Хочу отметить, что эта сложность в первую очередь для разработчиков браузеров, а не для верстальщиков. Мы уже привыкли использовать less/sass, что даже не задумываемся о том, нуждается ли данное css-свойство в уточнении префиксом или нет. Мы пишем следующие конструкции и порой перегружаем код парой ненужных свойств:

@mixin experimental($property, $value) {
  -webkit-#{$property}: $value;
     -moz-#{$property}: $value;
      -ms-#{$property}: $value;
       -o-#{$property}: $value;
          #{$property}: $value;
}

@mixin border-radius($radius) {
  @include experimental(border-radius, $radius);
}

@mixin box-shadow($bs) {
  @include experimental(box-shadow, #{$bs});
}

Будущее, в котором нет префиксов

Итак, что мы имеем на данных момент:

Если посмотреть на те css3-свойства, которые мы уже сейчас используем: css3please.com, то станет ясно, что браузеры правильно и одинаково понимают их. А это значит, что мы развиваемся почти по 4-му идеальному варианту.

.box_gradient {
  background-color: #444444;
  background-image: -webkit-gradient(linear, left top, left bottom, from(#444444), to(#999999)); // Safari 4+, Chrome
  background-image: -webkit-linear-gradient(top, #444444, #999999); // Chrome 10+, Safari 5.1+, iOS 5+
  background-image:    -moz-linear-gradient(top, #444444, #999999); // Firefox 3.6-15
  background-image:      -o-linear-gradient(top, #444444, #999999); // Opera 11.10-12.00
  background-image:         linear-gradient(to bottom, #444444, #999999); // Firefox 16+, IE10, Opera 12.50+
}

Отличие составляют только префиксы-костыли. И я задаюсь вполне очевидным вопросом: может быть, стоит прекратить эту "войну" префиксов и начать внедрять очевидные свойства?

Новые свойства с префиксами? Fuuuuu!!!

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

В завершении хотелось бы на примере фильтров и масок познакомить с тем, что скоро будет везде и без префиксов, чтобы вы могли в последний раз насладиться этим "костыльным" сапогом, который работает только в webkit:

1. filters
Позволяют применять простые фильтры как к изображениям, так и блокам (первое изображение - оригинал):

img { -webkit-filter: brightness(-30%); }
img { -webkit-filter: grayscale(100%); }
img { -webkit-filter: sepia(100%);     }
img { -webkit-filter: blur(3px);     }
img { -webkit-filter: invert(100%);     }


2. masking
Маскирование, тут всё понятно из названия и наглядно из примера ниже:

.mask {
-webkit-mask-box-image: url(mask.png);
}


В целом ужасно хотелось бы посмотреть на css лет эдак через 5.
Станет ли он похож на язык программирования? Введут ли переменные? Что из яваскриптовых функций он перетащит в себя?

Пока ясно одно: не нужно бояться экспериментировать и не нужно тащить артефакты прошлого.


HACK-week и pageless

HACK-week

Хак-вик - это неделя свободной разработки в рамках проекта. Очень простая, но замечательная идея, которая состоит в том, чтобы отречься от рутины и заняться тем, чем всегда хотелось, но никогда не доходили руки. Это может быть что угодно:
  • рефакторинг (небольшие улучшения, на которое никогда не хватает времени в режиме надо срочно-срочно)
  • добавление нового функционала с использованием новых библиотек
  • улучшение старого с новыми технологиями, возможно, с другой бд
  • добавление тестов или тотальная переработка существующих
  • увеличение быстродействия проекта
  • и многое-многое другое, что, возможно, хотелось бы пощупать применительно к данному проекту.
Хак-вик - это возможность найти для себя что-то интересное и воплотить в жизнь.
На мой взгляд это отличная практика, это возможность почувствовать себя не только карандашом в руке заказчика, но и архитектором. Появляется более трепетное отношение к проекту, как к своему детёнышу. Появляется соучастие и сопереживание, то, о чем говорил Тим Леберехт ("Как правильно терять контроль над своим брендом").

Ты из кодера превращаешься в Создателя минимум на три недели. Почему три? Потому что минимум неделя, а то и две до хак-вик можно потратить на придумывание Идеи: чем же можно заняться. Идея должна быть привлекательной для заказчика. Она не должна быть слишком сложной, чтобы успеть справиться за неделю, но и не слишком простой; достаточно интересной, чтобы чувствовать энтузиазм и удовлетворение по её завершению.

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

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

Лично для меня это была моя самая продуктивная неделя.

Pageless

На своем первом хак-вик я выбрала несложную задачку: добавить бесконечную прокрутку, т.е. автоматическую подгрузку данных, как это происходит в твиттере.
Я использовала явасриптовый плагин pageless, который отлично интегрируется с рельсами. Хотя пришлось дописать некоторые вещи:
  • добавилась кнопка "Show more results", явно предлагающая пользователю показать остальную часть данных, которые в дальнейшем будут автоматически подгружаться при прокрутке
  • при бесконечной прокрутке для табличных данных хорошо оставлять шапку вверху (здесь отдельные благодарности, симпы и лафки тегу thead)
  • и соответственно добавление кнопки 'To top', которая перенесет пользователя в верх страницы в случае, если он просмотрел уже большое количество данных.

Update:


О результате: http://blog.buyfolio.com/can-you-hack-it/

пятница, 4 января 2013 г.

Лучшее из 2012

IT событие
KyevJS конференция
Событие
Zillow приобрела Buyfolio
Курсы
"Software Engineering for SaaS" on www.coursera.org
Приложение
Reader128k
iPhone приложение
Instagram
Инструмент
Sublime Text 2
Инструкция по эксплуатации
Samsung
Гаджет
iPad mini
Ожидание
Samsung Galaxy Camera EK-GC100
Фильм
"127 Hours" (2010)
Книга
Стивен Хокинг. Краткая история времени от большого взрыва до черных дыр (1988 г.)
Музыка
PSY - GANGNAM STYLE
Ачивки
Получить легендарку "Клыки Отца" и бросить WoW = completed!
Разочарование
Современное искусство: в Изоляции, выставка в Грин-Плазе и галерее «АртДонбасс»
Впечатление
Красная пещера в Крыму
Город
Одесса