47 Постов

В этом посте я расскажу как я искал работу в Европе (в т.ч. Германии) и что из этого вышло.

Предыстория

В течение некоторого времени я искал работу напрямую, а затем на AngelList.

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

AngelList

На AngelList я отправил довольно много заявок, затем общался с компаниями, которые также заинтересовались мной.

Было интересно посмотреть на все эти стартапы. Кто-то запустил стартап в сфере фитнеса, кто-то в сфере образования, финансов или социальных сетей.

Это были компании из Норвегии, Швеции, Швейцарии, Италии, Великобритании, Германии и других стран. Обычно они располагались в столицах.

Также пара стартапов заинтересовалась во мне самостоятельно.

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

Inkitt

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

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

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

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

Первым вопросом был «есть ли у меня любимая книга или автор», на который я развернуто ответил.

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

Далее от общих вопросов мы перешли к более конкретным, к примеру на какую зарплату я рассчитываю, какой опыт имею, почему я предпочитаю Ruby on Rails и т.д.

Ну и ближе к концу я сам задал несколько вопросов об их компании и команде.

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

Ruby on Rails vs AngularJS vs React

Вначале я подавал заявку на должность под названием «Full Stack Developer (Ruby & JavaScript)», которая предполагала знание Ruby on Rails + AngularJS/React.

Но меня спросили что я предпочитаю больше, бэкенд или фронтенд, и есть ли у меня опыт с React.

Я ответил, что я fullstack-разработчик, но чуть больше предпочитаю бэкенд. А с React особо не работал, хотя и наслышан; предпочитаю AngularJS.

В итоге, дальше я собеседовался на должность бэкенд Ruby on Rails разработчика, что вполне меня устраивало.

Дело в том, что вакансия fullstack-разработчика у них слегка устарела, и они искали одного на RoR и двоих на React.

Кстати, Николас говорил, что сейчас в команде у них 12 человек и сейчас они активно ее расширяют. Как я видел по их вакансиям, они также ищут аналитика данных (Data Scientist) и многих людей связанных с менеджментом и издательским бизнесом.

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

Будущее издательского бизнеса

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

С помощью своих алгоритмов, они хотят заранее определять будущие бестселлеры.

Немецкая рабочая виза

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

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

Он ответил, что это вообще не проблема.

Я процитирую его слова насчет этого и рабочей визы (синей карты).

In general, the blue card you speaking of is issued to skilled IT professionals with a certain amount of salary. That is right.
The easiest way is to match the salary and to show the visa office that you have a degree from a university that the german system accepts. Super easy, takes 4 weeks, sometimes even faster.

If you do not have this and especially in development self-teaching and learning by doing is the best, the visa office understands it but image this crazy example. you are a bus driver and want to come over and say you do development. Of course the government needs to check if you can code and a university degree is the safest way.

But as I said they know self teaching is the most common way in development. So they have a department called Berlin Partner and we would have to send your resume plus the coursera / John Hopkins univeristy certificate to them, so they see you worked in development for years etc., and then they write a recommendation letter for us that you are classified and that they say you should get the visa.

Then it should also be fairly easy to get the visa. Just takes maybe a bit more time and we have to prepare more papers.

All in all that all should not be a problem at all.

Вольный перевод:

В общем, синяя карта, о которой ты говоришь, выдается квалифицированным IT-профессионалам с определенным уровнем зарплаты. Это правильно.
Самый простой способ — это соответствовать зарплате и показать визовому офису диплом университета, который немецкая система принимает.
Супер легко, занимает 4 недели, иногда даже быстрее.

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

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

Но, как я сказал, самообразование это самый частый путь в разработке. Так что, у них есть департамент под названием Berlin Partner, и нам нужно будет прислать им твое резюме + твой сертификат от Coursera/JHU, так что они смогут увидеть, что ты работал в сфере разработки и т.д., и затем они пишут рекомендательное письмо для нас, что ты подходишь и они считают что ты должен получить визу.

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

В общем, это не должно быть проблемой вообще.


Кстати, как можно догадаться, эти ребята спонсируют визу.

У них есть сотрудники из разных стран и они рады находить новых талантливых работников.

После интервью

Через пару дней после интервью, Николас прислал мне тестовое задание, которое, видимо, составил их CTO.

Нужно было сделать небольшое приложение-опросник с заданными характеристиками.

Еще через некоторое время я прислал им готовый результат.

Это приложение, конечно же, было сделано на Ruby on Rails, также там было немного JS на фронтенде. Ну и немного мелочи, например Bootstrap, куда же без него.

Также мне было предложено написать тесты на Ruby-фреймворке по выбору. Недолго думая, я выбрал RSpec.

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

Dear Kirill,

The Inkitt team wants to thank you for taking the time to participate in our hiring process, we highly appreciate your interest in Inkitt. We interviewed many candidates, and it was a tough decision, but taking all the applications and coding challenges into consideration, we decided not to pursue your application at this time.

You were a great candidate for our job though and we hope that you are not discouraged by our feedback and that you will apply for openings at Inkitt for which you qualify in the future.

Again, thank you for taking the time to talk to me. I enjoyed meeting you and our discussions indicated that you’re really passionate about what you’re doing. I’d like to keep you in our database and I will reach out to you in the case of any future vacancy if that is fine with you.

I wish you personal and professional success and all the best for your future.

Best,
Nicholas

Ну что ж, Inkitt показался мне вполне неплохой компанией, условия и зарплата меня также полностью устраивали.

Но будем надеяться, отказ означает, что где-то для меня есть работа получше.

А пока что вернусь к фрилансу.

Нужно ли высшее образование в IT?

Я бы так не сказал.

Большинство работодателей относится к этому всего лишь как к формальности, если им вообще есть до этого дело.

Я смотрел множество вакансий от европейских IT-компаний и стартапов, в большинстве вакансий либо вообще нет этого требования, либо оно не является обязательным.

Иногда можно встретить «желательна степень бакалавра или магистра, но ее отсутствие может не быть недостатком, если вы изучали всё в реальном мире, а не в стенах университета».

Адекватные работодатели (а таких большинство, по крайней мере в ЕС) понимают, что лучший способ научиться программированию или схожим вещам — это самообразование и практика.

Исключение могут составить известные университеты. Если вы учились в университете, который имеет широкое признание и авторитет, это стоит указать.

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

Как можно показать квалификацию без ВО

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

В резюме можно указать свои навыки, опыт работы в других компаниях, сертификаты курсов и прочее. Можно показать ссылки на свои проекты и исходный код (кстати, ссылку на Github в вакансиях спрашивают раз в 10+ чаще, чем спрашивают наличие ВО).

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

Даже в Google можно устроиться без «корочки». Они на это даже не будут смотреть, если вы покажете им соответствующий опыт и рекомендации, и хорошо проявите себя на собеседовании.

Примерно в конце 2014 я зарегистрировался на Github. Тогда у меня было не так много опыта в программировании, но был опыт в создании сайтов, чем я и занимался.

Мои первые 20 репозиториев содержали статичные сайты, которые я пытался вывести в топ поисковых систем и монетизировать. Это были довольно качественные мини-сайты с подробным текстом и ссылками на скачивание.

Для них я использовал стандартные шаблоны Github Pages, которые должным образом переделывал и улучшал.

Но это история.

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

Но вы не можете размещать там исполняемый код, можно использовать только HTML-страницы.

Github Pages

Github Pages предоставляют вам возможность размещать свои сайты и сайты своих проектов прямо в Github-репозиториях.

На gh-pages свои сайты размещают многие известные проекты. К примеру, там хостится сайт Bootstrap, сайт Ruby и т.д.

Важно также отметить, что хотя Github Pages хостит только статичные сайты, они поощрают использование таких генераторов как jekyll.

Jekyll, кстати, написан на Ruby.

Как разместить сайт

Если вы уже зарегистрированы на Github, достаточно просто создать репозиторий и зайти в его настройки.

Это супер просто.

Сейчас можно хостить свой сайт в master-бранче, но раньше для этого нужно было обязательно создать бранч gh-pages.

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

В общем, сегодня достаточно просто нажать «выбрать тему» для старта:

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

После коммита изменений, вы можете выбрать дополнительные настройки:

К примеру, можно добавить собственный домен.

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

Снова немного истории: раньше домен можно было добавить только созданием файла CNAME в корневой папке.

Управление сайтом

Управлять своим сайтом можно как обычным репозиторием.

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

В этом посте я расскажу как стать успешным программистом и зарабатывать в долларах или евро.

1. Учишь Ruby, учишь Rails. Самый первый и важный пункт.

2. Изучаешь HTML/CSS/JS. Это должно быть легче.

3. Изучаешь AngularJS. Пригодится для разработки фронтенда.

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

5. Затем еще раз зубришь Ruby on Rails от корки до корки.

Теперь программировать ты умеешь, это уже хорошо, но ты еще не зарабатываешь.

Большинство твоих клиентов, скорее всего, будут англоязычными.

6. Учишь английский. Если ты этого всё ещё этого не сделал, учи английский.

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

7(а). Отправляешь своё резюме в IT-компании. Можно искать напрямую или на сайтах типа AngelList.

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

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

Приведу диаграмму самых ценных технологий в резюме программиста.

Самые оплачиваемые языки программирования

Первое место занимает Ruby on Rails.

Так что, самый оплачиваемый язык это Ruby.

Также в этом списке я бы отметил JavaScript. JS отстает от Ruby почти на $20,000 годовой зарплаты, но тем не менее он в топе наиболее ценных веб-технологий.

JS в комбинации с Ruby дает отличный эффект.


Диаграмма приведена для США.

Когда я только начал изучать AngularJS, у меня была мысль «зачем всё усложнять, почему ты не держать всё в простом виде?» и «зачем учить ещё одну технологию?».

Под «держать все в простом виде» я имею в виду стандартный фронтенд-набор: HTML, CSS, JavaScript.

Дело в том, что когда ваше веб-приложение становится сложнее само по себе, размер вашего кода растет. Если даже не растет его размер, растет его сложность.

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

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

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

Кроме того, вам не нужно использовать какой-либо код дважды, а многие стандартные действия в AngularJS упрощены и это серьезно повышает продуктивность.

Да и с тестированием в AngularJS все намного проще, чем с тестированием «чистого» JS-кода.


AngularJS отлично интегрируется с Ruby on Rails и другими бэкенд-фреймворками.

Это проект с открытым исходным кодом, разработанный сотрудниками Google.

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

В этом посте мы поговорим о Bootstrap, который является CSS-фреймворком.

Это один из наиболее популярных CSS-фреймворков, его разработали инженеры из Twitter.

Что такое Bootstrap

Bootstrap это самый популярный HTML/CSS/JavaScript фреймворк для разработки отзывчивых, «mobile first» проектов в вебе.

Давайте разберем эти утверждения.

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

Bootstrap состоит по большей части из CSS. Он предопределяет множество CSS-классов для вас.

Часто Bootstrap требует иметь определенную HTML-структуру на вашей странице.

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

Он также имеет крутой JavaScript-фреймворк, основанный на jQuery API, который помогает добавлять плагины реально улучшающие ваш сайт.

Кроме того, Bootstrap называют «mobile first» фреймворком.

В общем-то, это означает, что вы имеете дело в первую очередь с мобильными девайсами.

В реальности, такой подход может иметь два варианта.

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

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

Я бы сказал, что оба эти варианта полностью валидны.

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

Также этот подход означает, что CSS-фреймворк должен подходить для мобильных.

Кстати, довольно интересно, что Bootstrap не всегда был «mobile-first». До версии 2.0 или около того, Bootstrap имел отдельный CSS-файл и отдельный набор классов для них.

Но сегодня он mobile-first.

Недостатки Bootstrap

Какие недостатки у этого фреймворка по сравнению, к примеру, с написанием собственного?

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

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

Так что, хотя Bootstrap и слегка раздут, это не очень плохо.

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

Официальный сайт и документация

Официальный сайт — getbootstrap.com.

На официальном сайте можно найти документацию, примеры, темы и прочее.

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

Я нашел этот довольно популярный график в интернете, источником указывается Morgan Stanley Research. Не знаю насколько точны эти цифры, но общая суть давно ясна: мобильные браузеры догнали и перегнали по популярности десктопные.

Судя по графику, это произошло примерно в 2013-2014 году, и с этого момента уже прошло немного времени.

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

Мобильных девайсов много. Какие из них поддерживать?

Все из них. Иначе вы можете потерять часть своих пользователей.

Что такое отзывчивый сайт?

Это сайт, который адаптируется к среде просмотра.

Часто в рунете используют термины адаптивный дизайн или адаптивный сайт, но технически это не совсем одно и то же, так что в этой статье для точности я использую термин «отзывчивый дизайн».

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

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

Вы помещаете воду в чашку и она становится чашкой. Вы помещаете воду в бутылку и она становится бутылкой. Вы помещаете ее в чайник, и она становится чайником.

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

Контент остается тем же, меняется только его форма.

Чаще всего (но не всегда) это означает, что сайт будет адаптироваться по ширине девайса.

Альтернативы отзывчивому дизайну

Есть ли альтернативы принципам отзывчивого дизайна? Вообще, они есть.

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

К примеру, может иметься обычная версия сайта по адресу example.com, а мобильная по адресу m.example.com.

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

Но такой подход может иметь некоторые недостатки.

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

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

Медиа-запросы позволяют группировать стили вместе и задавать их для разных девайсов на основе определенных критериев.

К примеру, вы можете определить устройство по его ширине, высоте или ориентации (горизонтальной, портретной).

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

Не забывайте, что CSS имеет силу создавать очень разные макеты веб-страниц на основе одного и того же HTML. Помните csszengarden.com?

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

Вот почему очень важно изучить, по крайней мере, основы использования медиа-запросов.

Без них адаптивный дизайн, о котором мы скоро поговорим, не был бы возможным.

Поэтому давайте рассмотрим основной синтаксис медиа-запросов.


@media (max-width: 767px) {
  p {
    color: blue;
  }
}

Медиа-запрос начинается с @media, затем идет медиа-свойство и фигурные скобки.

Внутри фигурных скобок находятся стили. Это как таблица стилей внутри таблицы стилей.

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

Когда пишете медиа-запрос, не забудьте закрыть скобку для самого запроса и для каждого стиля.

Основные медиа-свойства


@media (max-width: 800px) {...}


@media (min-width: 800px) {...}


@media (orientation: portrait) {...}


@media (screen) {...}


@media (print) {...}

Вы можете определять устройства по ширине, высоте, по ориентации, типу экрана и т.д.

Но наиболее частым применением является таргетирование по ширине.

Основные логические операторы медиа-запросов

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

Одним из наиболее популярных логических операторов является and.

В качестве примера, код ниже определяет диапазон ширины.


@media (min-width: 768px) and (max-width: 991px) {...}

Другим способом комбинации медиа-запросов является разделение их запятой. Это, по сути, эквивалент оператора OR.


@media (max-width: 767px) , (min-width: 992px) {...}

На практике, при создании адаптивного дизайна или адаптивного макета самым частым оператором будет and.

Структура таблицы стилей с медиа-запросами

Я хотел бы показать вам как структурировать таблицу стилей с медиа-запросами в ней.

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


p { color: blue; } /* базовые стили */

...

@media (min-width: 1200px) {
...
}

@media (min-width: 992px) and (max-width: 1199px) {
...
}

...

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

Затем вы пишете стили для определенных размеров экрана, например изменяя для них некоторые базовые стили или добавляя новые.

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

В примере выше первый медиа-запрос имеет минимальную ширину в 1200 пикселей, а во втором медиа-запросе максимальная ширина указана в 1199 px.

Если бы во втором запросе было включено 1200, то применялись бы оба из них, и скорее всего это было бы не очень хорошо.

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

Примеры

Давайте взглянем на пример.

Здесь у нас снова простая структура HTML: заголовок два параграфа.

Параграфы имеют свои id. Один из них будет большим, а другой маленьким.

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


<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Медиа-запросы</title>
<style>
/********** Базовые стили **********/
h1 {
  margin-bottom: 15px;
}
p {
  border: 1px solid black;
  margin-bottom: 15px;
}
#p1 {
  background-color: #A52A2A;
  width: 300px;
  height: 300px;
}
#p2 {
  background-color: #DEB887;
  width: 50px;
  height: 50px;
}

/********** Только большие девайсы **********/

/********** Только средние девайсы **********/

</style>
</head>
<body>
<h1>Медиа-запросы</h1>

<p id="p1"></p>
<p id="p2"></p>

</body>
</html>

Давайте посмотрим на это в браузере.

При изменении ширины браузера ничего не меняется. Если мы делаем его уже, наши параграфы остаются того же размера.

А теперь давайте посмотрим что мы можем сделать с помощью медиа-запросов.


<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Медиа-запросы</title>
<style>
/********** Базовые стили **********/
h1 {
  margin-bottom: 15px;
}
p {
  border: 1px solid black;
  margin-bottom: 15px;
}
#p1 {
  background-color: #A52A2A;
  width: 300px;
  height: 300px;
}
#p2 {
  background-color: #DEB887;
  width: 50px;
  height: 50px;
}

/********** Только большие девайсы **********/
@media (min-width: 1200px) {
  #p1 {
    width: 80%;
  }
  #p2 {
    width: 150px;
    height: 150px;
  }
}

/********** Только средние девайсы **********/
@media (min-width: 992px) and (max-width: 1199px) {
  #p1 {
    width: 50%;
  }
  #p2 {
    width: 100px;
    height: 100px;
  }
  body {
    background-color: blue;
  }
}
</style>
</head>
<body>
<h1>Медиа-запросы</h1>

<p id="p1"></p>
<p id="p2"></p>

</body>
</html>

Откроем в браузере.

Так как мой браузер шире 1200 px, применяются стили указанные для больших девайсов. Ширина первого параграфа равняется 80% от ширины окна, а второй параграф занимает размер 150×150 пикселей.

Теперь попробуем сделать окно браузера немного уже.

Теперь в диапазоне 992‒1199 px применяются новые стили: синий фон, первый параграф шириной 50%, второй параграф 100×100 пикселей.

И, наконец, попробуем сделать его уже 992 px.

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

Кстати, чтобы узнать точную ширину браузера, вы можете открыть инструменты разработчика (Ctrl + Shift + I). Очень полезная вещь, кстати.

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

Кроме того, там есть иконка с телефоном.

Если вы кликнете на нее, вы можете просмотреть сайт с разными размерами экрана. Можно выбрать какой-то девайс типа Galaxy S5 или iPhone 6, либо выбирать любой размер самостоятельно.

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

Вкратце

Мы поговорили о базовом синтаксисе медиа-запроса:

  • @media (медиа-свойство)
  • @media (медиа-свойство) логический оператор (медиа-свойство)

Не забывайте не перекрывать граничные точки других запросов, даже на один пиксель.

Обычно вы предоставляете базовые стили. Затем вы меняете или добавляете к ним стили для каждого медиа-запроса.

CSS работает, ассоциируя правила с HTML-элементами. Эти правила определяют то как должно отображаться содержимое указанных элементов.

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


p {
  color: blue;
}

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

За селектором следуют открывающая и закрывающая фигурная скобка, внутри которых содержится CSS-декларация. Она состоит из двух частей: свойства и значения.

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

Каждое свойство со значением разделяется двоеточием и заканчивается точкой с запятой.

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

Конечно, CSS-правило может содержать несколько деклараций:


p {
  color: blue;
  font-size: 20px;
  width: 250px;
}

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

Набор CSS-правил будет называться таблицей стилей.


p {
  color: blue;
  font-size: 20px;
  width: 250px;
}

h1 {
  color: green;
  font-size: 34px;
  text-align: center;
}

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

Но обычно у вас будет гораздо больше одного.

Далее, давайте посмотрим на CSS внутри HTML-документа.


<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Анатомия CSS-правила</title>
<style>
p {
  color: blue;
  font-size: 20px;
  width: 250px;
}
h1 {
  color: green;
  font-size: 34px;
  text-align: center;
}
</style>
</head>
<body>
<h1>Анатомия CSS-правила</h1>
<h2>Первый подзаголовок</h2>
<p>CSS работает, ассоциируя правила с HTML-элементами. Эти правила определяют то как должно отображаться содержимое указанных элементов.</p>
<h2>Второй подзаголовок</h2>
<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed aliquet semper erat. Donec mi risus, efficitur malesuada purus at, egestas placerat libero. Vestibulum in mattis lorem.</p>
</body>
</html>

В этом примере у нас есть заголовок, два подзаголовка и два параграфа. И мы назначаем этим элементам немного кастомных стилей.

Мы добавляем наши стили внутри <head>, внутри тега <style>.

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

Давайте взглянем на это в браузере.

Заголовок имеет определенный размер и расположен по центру. Параграфы тоже имеют свой размер и цвет, и занимают отведенные им 250 px.

Если вы обратите внимание на подзаголовки <h2>, вы заметите что они имеют больший размер шрифта и более жирное начертание чем обычный текст. Но этого мы не указывали.

Эти неуказанные стили исходят из самого браузера.

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

Вкратце

В этом посте мы поговорили о синтаксисе CSS-правила:

  • Селектор
  • Декларация
  • Пара свойство/значение

Также мы поговорили о комбинировании CSS-правил в одну таблицу стилей.