Страницы

четверг, 10 марта 2016 г.

CSS Bliss: основные особенности методологии

Среди множества методологий организации стилей (BEM, SMACSS, OOCSS, SUITECSS) хочется отдельно выделить одну: CSS Bliss. Это квинтэссенция удобства использования и читабельности.

Для начала определимся в основных понятиях: модуль, элемент и модификатор. Эти определения наиболее близки БЭМу, за исключением того, что Модулем в CSS Bliss именуется Блок. Далее будет понятно, почему Модуль - более подходящее значение. В целом сама методология очень близка к БЭМу, но имеет свои особенности, о которых стоит поговорить отдельно, потому что именно они позволяют стать CSS Bliss на ступеньку выше остальных.



Основные отличия CSS Bliss:

1. Именование модуля, элементов и модификаторов:

Если в БЭМе основными разделительными частицами выступают "-" и "_":

.my-module__my-element_modifier

то CSS Bliss улучшает читабельность путем использования заглавных букв:

.MyModule-myElement--modifier

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

Возможно, на абстрактном примере это плохо видно, возьмем пример более приближенный к реальному проекту. Сравните:

<li class="custom-user-menu__list-item_size-normal"></li>

<li class="CustomUserMenu-listItem--sizeNormal"></li>

Первый БЭМовский вариант длиннее и сложнее в прочтении. Особенно сливается модификатор с названием элемента. Второй (CSS Bliss) более компактен и визуально разделен на понятные компоненты: модуль, элемент и модификатор. При чем отличие в первой букве моментально дает понимание что перед нами: модуль или элемент (модуль начинается с заглавной, а элемент - со строчной).

Если я вас еще не убедила, вот еще один пример из документации БЭМа для модификаторов "ключ - значение":

.block-name__elem-name_mod-name_mod-val

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

2. Позиционирование компонентов.

Модуль независим и самодостаточен сам по себе. Он должен выглядеть одинаково в любом месте и при любом разрешении, именно поэтому он имеет одно важное ограничение: модуль не должен содержать в себе свойства, которые бы жестко задавали его позиционирование, а именно: размеры (width), внешние отступы (margin) и позиционирование по отношение к другим элементам (position). Эти свойства должны задаваться либо в модификаторе модуля либо этот модуль так же является элементом внешнего блока, который (элемент) и определяет его положение.

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

3. Организация структуры

Несмотря на удобство организации файловой структуры в БЭМе, он предполагает излишне дробное деление: каждый модификатор и элемент выносится в отдельный файл. Пример:

blocks
├─── popup
|    ├──── _target
|    |    ├──── popup_target.css
|    |    ├──── popup_target_anchor.css
|    |    └──── popup_target_position.css
|    └──── _visible
|         ├──── popup_visible.css
|         ├──── popup.css
|         └──── popup.js


Тогда как в CSS Bliss предполагает создавать файлы только для модулей, а его внутренние элементы и модификаторы описывать внутри этого же файла, так как вне его они не имеют смысла:

css
├─── modules
|    ├──── _PopupDialog.scss
|    ├──── _Btn.scss
|    └──── _ElmInfo.scss
├─── _base.scss
├─── _colors.scss
├─── _mixins.scss
├─── _zindex.scss
└─── application.scss


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

4. Состояние элемента: state

Очень часто нам нужно определять состояние элемента или модуля: активный, скрытый, доступный, использованный и проч. Использование для этого модификатора не только загромождает читаемость html, но и загрязняет javascript.

Пример на БЭМе:

<div class="my-module__my-mlement my-module__my-mlement_my-modifier-with-state"></div>

Пример на Bliss CSS:

<div class="MyModule-myElement isState"></div>

В последнем примере мы используем для изменения состояния в js не длиное название модификатора: "my-module__my-mlement_my-modifier-with-state", а привычное и универсальное "isState". Из-за того, что состояние определяется только для конкретного модуля или элемента, оно обладает локальным воздействием на него. А универсальное наименование состояния позволяет при необходимости переиспользовать js-код для различных элементов страницы.

5. Использование @extend

Лично я - противник использования такой возможности sass как расширение классов с помощью @extend. Главные требования к CSS должны быть:
  • простота
  • читабельность
  • легкоизменяемость

С помощью @extend вы расширяете исходные классы дополнительным кодом, при чем из любого другого места. Несмотря на кажущуюся простоту концепции, @extend в корне противоречит отновному принципу каскадности стилей; им сложно управлять и читать. Неудивительно, что Bliss CSS запрещает использование @extend для классов и элементов.

6. Документация

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

Это лучшая прикладная документация, которую я встречала.

Выводы

Несмотря на большую популярность БЭМа в последнее время, CSS Bliss по всем вышеуказанным причинам гораздо практичнее. И как и прочие методологии она вырабатывает привычку думать не в разрезе страницы, а в терминах компонентов: модули, элементы, модификаторы; что делает процесс написания css'a более осознанным, так как от привильного разбиения на компоненты зависит не только красота кода, но и жизнеспособность стилей в будущем.

четверг, 18 февраля 2016 г.

Прогноз погоды в консоли

Замечательный погодный сервис в твоей консоли:

curl http://wttr.in



Можно прописать алиас:

alias weather='function _weather(){ curl http://wttr.in/$1 };_weather'

и после этого набирать в консоли (для текущей локации, города или помощи):

weather
weather London
weather :help

среда, 6 января 2016 г.

Лучшее из 2015


Online курсы
"Astronomy: Exploring Time and Space" by Chris Impey (University of Arizona)
Курсы
Академрисунок к а р а н д а ш е м
Книга
"Гарри Поттер" Джоан Роулинг, "Убить пересмешника" Харпер Ли и "Книжный вор" Маркус Зузак
Игра
Diablo III & World of Draenor
Музыка
Magic! "Rude"
Танцевальный исполнитель:
Koharu Sugawara & Yuki Shibuya
Увлечение
Квест комнаты
Блюдо
Паски, печеночные тортики и яблочные розочки
Activity
Сноуборд, водные лыжи и серфинг.
Город
Санкт-Петербург
Страна
Шри-Ланка и Словения
Курорт
Буковель
Библиотека
React.js
Достижение
Сказка в инстаграмме


Подводя итоги года, каждый раз удивляюсь каким же долгим и разнообразным он был. Мы побывали в трех странах, были на мастер-классах по гончарству и рисованию маслом
Множество вещей попробовали в первый раз: серфинг в Шри-Ланке и жареные каштаны в Словении. Начали свой проект на react.js.
Кто-то впервые летал самолетом и катался верхом на лошади =)

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

пятница, 27 ноября 2015 г.

Стайлгайд и компонентная разработка

"Мы не разрабатываем страницы, мы разрабатываем системы компонентов"
Стивен Хэй (дизайнер)
("We are not designing pages, we are designing systems of components" Stephen Hay)


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

Введение


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

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

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

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

Стайлгайды для разработчиков


Как было сказано ранее, у каждого языка программирования также существует свой стайлгайд, набор правил написания и оформления кода:

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

На примере KSS в прошлой статье я рассказывала о документирования CSS, но покрывает ли этот способ задания стайгайдов весь диапазон компонентов приложения?

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

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

В зависимости от вашего приложения они могут выглядеть совершенно по-разному:

Пример 1:


Пример 2:


Пример 3:


Пример 4:


Пример 5:



Преимущества стайлгайдов


1. Легко тестировать

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

2. Налаженный рабочий процесс

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

3. Общий словарь

Это не только общий словарь наименований компонент, но и внутренних элементов. Понятный. Однозначный.

4. Удобная ссылка

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

Поэтому стайлгайд - это очень живая документация кода с подробной детализацией элементов и модулей и удобной визуализацией. Это средство коммуникации в проекте между отделами проектировщиков, дизайнеров, разработчиков и менеджеров.


Разработка приложения через стайлгайд


Как выглядит процесс разработки приложений:



1. Выделение особенностей приложения

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

2. Разбиение на компоненты

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

3. Реализация и документирование

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

4. Сборка приложения

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

Заключение

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

  1. В функциональном программировании - это чистые функции. В ООП - это просто правильно написанные функции, небольшие, реализующие какой-то кусочек логики, но без сайд-эффекта, не влияющие на работу других функций и методов.
  2. HTML: разбиение на преиспользуемые блоки: паршалы.
  3. CSS: методология веб-разработки БЭМ (Блок-Элемент-Модификатор) или ее улучшенный аналог CSS Bliss. Оба подхода идеально вписываются в структуру компонентов. В Блиссе для каждого компонента создается отдельный файл с описанием стилей для этого компонента и вложенных элементов и модификаторов.
  4. В дизайне компоненты - это элементы дизайна, из которых строится будущий макет. Так, например, как частный случай можно рассмотреть Bootstrap: набор предустановленных компонетов, таких как заголовки, кнопки, тексты, колонки, меню и проч. В более общем случае - это проектирование больших приложений из меньших составляющих, которые в свою очередь тоже состоят из более мелких. Это основная идея Атомарного дизайна, которую можно так же описать эпиграфом к этой статье известного дизайнера Стивена Хэя ("Мы не разрабатываем страницы, мы разрабатываем системы компонентов") и проиллюстрировать картинкой процесса создания дизайна:


Ссылки


понедельник, 9 ноября 2015 г.

KSS styleguide

Что такое KSS?

KSS (Knyle Style Sheets) - это документация к CSS, достаточно понятная для разработчиков и хорошо структурированная для программной обаботки. Для лучшего понимания рекомендую почитать ну очень хорошую статью о концепции KSS.

Как это выглядит в коде? Пример файла buttons.css:

/*
A button suitable for giving stars to someone.

:hover             - Subtle hover highlight.
.stars-given       - A highlight indicating you've already given a star.
.stars-given:hover - Subtle hover highlight on top of stars-given styling.
.disabled          - Dims the button to indicate it cannot be used.

Styleguide 2.1.3.
*/
a.button.star{
  ...
}
a.button.star.stars-given{
  ...
}
a.button.star.disabled{
  ...
}

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

Последней строкой комментария задается расположение описания: 2.1.3 - в данном случае 2 глава с указанием пунктов и подпунктов. Вложенность можно делать любую в зависимости от нужд разработчика. Например:

1. Text styling
2. Buttons
   2.1 Form Buttons
       2.1.1
   2.2 Other buttons
       2.2.1
3. Forms
   3.1 Text fields
   3.2 Radio and checkboxes


По этой документации создается специальная страница styleguide, где можно увидеть задокументированный css c описанием. Пример:



Работая с препроцессорами (sass, less) достаточно удобно описывать миксцины и их параметры:

// Creates a linear gradient background, from top to bottom.
//
// $start - The color hex at the top.
// $end - The color hex at the bottom.
//
// Compatible in IE6+, Firefox 2+, Safari 4+.
@mixin gradient($start, $end){
  ...
}

Зачем это вообще надо?

Стоит ли так заморачиваться если проект маленький и я сижу в нем один? Как показывает практика, даже маленький проект нуждается в минимальной поддержке и доработке: там банер добавить, а тут текст увеличить. Иногда таких мелких правок бывает очень много, что легко испортить самый кристально чистый css.

Преимущества документированного css:

  • Такой css легко поддерживать, он остается чистым и понятным, а это сокращает время на написание нового
  • Структурирование css по файлам, что позволяет быстро находить существующие стили и использовать их, избегая дублирования
  • Написание такого css позволяет выработать хорошую привычку
  • Легко поддерживать консистентность в проекте

На каком этапе стоит использовать в своем проекте?

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

В идеале практическая сторона верстки должна строиться так:

  1. Построение html-структуры
  2. Описание основных css-стилей, кнопок, блоков и проч. элементов в соответствии с kss-документацией
  3. Создание прочих, уникальных css-стилей

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

Какой "фреймворк" выбрать?


Принцип "фреймворков" достаточно простой: в стилях идет описательная часть в комментариях в начале файла. А по заголовкам они автоматически добавляются к списку гайдов.

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

Хороший пример стайлгайда представлен у гитхаба. Естественно, хорошо бы иметь документацию и на html и на js.

Альтернативы


Наряду с KSS существуют и другие инструменты с очень похожим приниципом:


среда, 8 апреля 2015 г.

Верстаем responsive emails

Основные правила для верстки писем:

1. Все стили инлайнятся, так как Gmail автоматически вырезается head, а также обертку body, оставляя только ее внутренности.
Тем ни менее можно указать основные стили на случай если писем много и править их будет кто-то другой, кто забудет заинлайнить, и в большинстве почтовиках письмо будет смотреться неплохо:

<style media="screen" type="text/css">
  * { font-family: Arial, sans-serif; margin:0; padding:0; }
  p { font-size: 15px; margin: 15px 0; }
  a { color: #0080C6; }
</style>

2. margin и padding
Некоторые почтовые клиенты (Outlook 2007, 2010, 2013 - назовем их семейство Outlook серии 2007; Outlook.com) не понимают свойства margin и padding. Поэтому не рекомендуется использовать тег <p>, так как отдельные почтовики (Outlook.com) могут автоматически добавлять свои отступы, нарушая тем самым верстку.
Предпочтительно использовать <div> в связке <br> для отступов.

3. font-family
Указание font-family (дабы избежать многократного дублирования) на максимально верхнем уровне (следующем после body), но для таблиц в минимальной вложенной (то есть если есть таблица в таблице, то для внутренней таблицы в теге table дополнительно указываем font-family).

<table border="0" cellpadding="0" cellspacing="0" width="100%"
       style='font-family:Arial,sans-serif;'>

Это связанно с проблемой в Outlook (семейства 2007), где все неуказанные инлайненые задаются своими по умолчанию (как правило семейством sans).

4. Размер шрифта задается аналогично font-family. При неправильном указании проблемы возникают в Apple mail 7-8, который выставляет по умочанию очень мелкий шрифт.

5. Свойства, которые желательно задавать отдельно в качестве аттрибутов, а не через css:
  • bgcolor
  • valign / align
  • height / width
Важно помнить, что height и width указывается по умолчанию в пикселях и без кавычек. Дополнительно "px" указывать не нужно. В кавычки берутся только проценты. Дело в том, что outlook некоторых версий "не понимает" значений в кавычках.
Пример:

<table bgcolor='#F0F0F0' border="0" cellpadding="0" cellspacing="0" 
      width="100%">

6. Отступы и чем их делать?
Допустимые варианты задания отступов (вместо margin и padding):
  • &nbsp;
  • <img src="space.gif" height="0" width="10" />
    (однопиксельная картинка с заданными шириной или высотой для растяжки)
  • <td height="10" width="20"></td>
    (пустые ячейки таблицы)
  • <div style="font-size:35px;line-height:1;"> </div>
Не следует использовать тег <p>? так как outlook.com добавляет снизу свои большие отступы к нему.

7. Особняком стоят ссылки.
В Gmail по умолчанию все ссылки синего цвета и подчеркнутые, поэтому для каждой из них нужно переопределить эти стили в случае необходимости:
<a href="#" style="color: #0080C6;text-decoration: none;">test</a> 

8. Gmail
Так же стоит отметить, что Gmail автоматически преобразовывает URL и email адреса в ссылки.

Как насчет респонсив дизайна:

1. Резиновость
Резиновость задается через медиа-квери с обязательным добавлением "!important".

<style media="only screen and (max-width: 450px)" type="text/css">
@media only screen and (max-width: 450px) {
  .logo { height: 19px!important; width: 115px!important; }
  .top_space { width: 10px!important; }
}
</style>
Так как Gmail игнорирует стили и теги в head, в нем не будет резиновости, поэтому на него можно не ориентироваться. Как привило, респонсив делаются на ширину в 600px и 320px, но можно указывать и промежуточные варианты.

2. Задача:
скрыть элементы для писем, которые будут показаны только в мобильной версии.
Проблема в Outlook и Gmail. Если для первого достаточно указать в инлайне display: none, то Gmail не поддерживает конструкцию "display: none", зато понимает "display: none !important". Но этом случае (так как стиль заинлайнен) нет возможности перекрыть это свойство для мобильных устройств через медиа квери. Поэтому задача заметно усложняется:

<style media="only screen and (max-width: 600px)" type="text/css">
@media only screen and (max-width: 600px) {
  div[class="show_m"] {
    display: block!important;
    float: none!important;
    max-height: inherit!important;
    overflow:visible !important;
    width: auto!important;
  }
}
</style>

<div class="show_m" style="
  display: none; 
  float: left;
  max-height: 0;
  overflow: hidden;
  width: 0;">
  Текст, видимый для мобильных устройств
</div>


3. Обратная задача:
Для того, чтобы скрыть что-либо для мобильной версии, можно использовать привычное свойство: display: none!important;

<style media="only screen and (max-width: 600px)" type="text/css">
@media only screen and (max-width: 600px) {
  div[class="hide_m"] {
    display: none!important
  }
}
</style>

<div class="hide_m">
  Текст, скрытый для мобильных устройств
</div>

4. Двух- и одноколоночный вариант
Что делать, если нужно из двухколоночного сделать одноколоночный на всю ширину в телефоне?
Существуют два способа, хорошо описанных в статье.

Первый способ очень объемен и не работает в Android 4.2 и iPhone 5-6 (вторая колонка максимально сужается по ширине, но остается в первом ряду, не переходя во второй).

Второй вариант проще, но для семейства 2007 Outlook стоит следить, чтобы колонки не были вплотную, потому что могут перескочить на следующий ряд. Поэтому считаю второй способ более предпочтительным.

5. Еще одна особенность Gmail
Когда письмо достигает размера большего чем 102K, оно автоматически разрезается и добавляется сообщение:

[Message clipped]  View entire message

И несколько полезных ссылок о верстке емэйлов:

1. С чего начать? 6 респонсив темплейтов для емэйлов.

2. Хабр: Верстка email рассылок от А до Я для чайников

3. Гайд по поддерживаемым свойствам css в почтовых клиентах

4. Повторю: 2 способа как двухколоночный сделать одноколоночным.

5. Верстаем под Gmail: Override Gmail’s Mobile Optimized Emails

среда, 4 февраля 2015 г.

Лучшее из 2014


Курсы
Roman Architecture by Diana E.E. Kleiner
Live!: A History of Art for Artists, Animators and Gamers by Jeannene Przyblyski
Лучшая parallax работа
Alice in Videoland: the Interactive Storybook
Книга
"Внутренняя сторона ветра" Милорад Павич
Музыка
Sia
Игра
'Just Dance 2014'
Танцевальный исполнитель:
Мэдди Зиглер, 11 лет.
Увлечение
Квест комнаты
Блюдо
Кофе 'Копи Лувак'
Творчество
Акварель
Начинания
Роспись стены акриловыми красками и декабрьская сказка в Инстаграме
Activity
Современные и бальные танцы
Город
Днепропетровск
Курорт
Буковель
Достижение
Мобильная версия 'Agentfolio'