Пишу про разработку вообще и в частности про: JavaScript, HTML5, CSS3, AngularJS, ReactJS, Agile.

Схлопывание внешних отступов у элементов

Отличная статья с визуальными примерами о том как работает схлопывание внешних отступов у элементов – What’s the Deal with Margin Collapse?. Как-то так получилось, что не все фронтенд разработчики знают об этом поведении внешних отступов.

Когда схлопывание происходит

У двух соседних элементов.

margin-collapse-siblings-1024x490

У дочернего элемента.

margin-collapse-child-top-1024x455

margin-collapse-child-bottom-1024x455

В том случае, если высота элемента равна нулю, то схлопнуться верхний и нижний отступы.

margin-collapse-self-1024x299

Когда схлопывания не будет

margin-collapse-exception-1-1024x569

margin-collapse-exception-2-1024x525

margin-collapse-exception-3-1024x525

margin-collapse-exception-4-1024x526

margin-collapse-exception-5-1024x478

Поделиться:

Вынести папку из репозитория с сохранением git истории

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

Теперь в проекте остались только файлы из папки. Причем файлы будут лежать в корне основной директории <git repository A directory>

Давайте посмотрим как это делается на конкретном примере – выделим папку “doc” из репозитория underscore:

Вот и все, теперь в папка “underscore” только файлы документации.

Ссылки по теме:

Поделиться:

Библиотека компонентов

В жизненном цикле любой разработки наступает момент, когда хочется вынести часть кода в отдельный репозиторий. Потому что уже надоело копировать его из приложения в приложение. А вместо этого хочется просто взять и установить через npm например. Про то как установить через npm поговорим потом, а сегодня – о том как сделать библиотеку компонентов.

В нашем примере есть три компонента, которые мы хотим использовать везде:

  • Button.jsx
  • Checkbox.jsx
  • Form.jsx

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

  • Button.jsx        →   “./Button/Button”
  • Checkbox.jsx   →   “./Checkbox/Checkbox”
  • Form.jsx          →   “./Form/Form”

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

components.js

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

components.d.ts

И самое главное – пишем конфиг для вебпака. Тут есть несколько моментов.

  • Указываем путь до файла components.js
  • Выбираем как библиотека будет собрана через libraryTarget (в моем случае это umd)
  • В externals указываем какие библиотеки не должны быть частью собранной библиотеки. То есть эти библиотеки должны будут быть включены в проекте, который использует эти компоненты. Исключительно экономия размера.

webpack.config.js

Вот и все – можно запускать и использовать.

Поделиться:

Chrome будет блокировать рекламу не отвечающую стандартам

Начиная с 15 февраля этого года Chrome будет блокировать рекламу, которая не отвечает стандартам описанным в Better Ads Standards. Разумеется, что у хрома нет цели убить рекламу в интернете и можете быть спокойны, что реклама в результатах поиска гугла никуда не денется 🙂 Вместе с тем разработчики самого популярно браузера хотят сделать интернет лучше и, как ни странно, помочь росту рынка рекламы.

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

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

  • Попапы внутри страницы, которые закрывают контент.
  • Видео реклама, которая начинает авто-проигрываться как только пользователь зашел на страницу.
  • Широкие прикрепленные баннеры.

На мобильных устройствах:

  • Все те же попапы, закрывающие контент, авто-проигрывающееся видео, прикрепленные баннеры.
  • Мигающая анимация.
  • Плотность рекламы превышающая 30% от экрана.
  • Рекламные баннеры, которые вынуждают пользователя прокручивать страницу через весь их контент и по-факту занимающие все пространство экрана.

better-ads-standards

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

Поделиться:

Как не надо писать статьи об оптимизации

На днях в рассылке пришла ссылка на статью “How I Cut My React Javascript Bundle Size In Half With Three Lines of Code” (“Как я тремя строчками код в два раза уменьшил бандл React приложения”). Огонь название, не находите? Сразу хочется пойти и уточнить как же это сделать, ведь проблема-то насущная – размер кода редко когда уменьшается, он все норовит вырасти. Однако, каким же фейком оказалась эта статья.

В чем основной совет статьи? Заменить react на preact, вот и все! Взять и заменить один фреймворк на другой, ничего же плохого не может случиться! Какие проблемы? Действительно, если автор в основном пишет приложения вроде ведения списка дел, то все будет в шоколаде, без сомнений. А что делать, если в приложении 20 страниц контента со сложной логикой? Все же сломается, потому что эти фрейморки не на 100% взаимозаменяем. Я уже молчу про баги в работе preact’а.

Поделиться:

Так ли нужны “хлебные крошки” (breadcrumbs)

Для начала несколько слов о том что такое “хлебные крошки” (breadcrumbs), чтобы мы все могли говорить на одном языке. “Хлебные крошки” – это элемент навигации веб-страницы, который позволяет дать информацию пользователю о том, в каком контексте он находится. Например:

breadcrumbs-navigation-example

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

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

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

google-analytics

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

Я уже не говорю о том, что сам подход – использовать “хлебные крошки” – уже морально устарел. Он был хорош в начале развития интернета, когда сайты были статичные и нужно было решать проблемы статичными же методами. Сегодня мы можем изменить подход и, немного подумав, сделать-таки интерфейс удобным и не обремененным ненужным функционалом.

Поделиться:

Дизайн админки – сумбур графиков

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

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

dashboard-activity-feed

У меня сразу вопрос – неужели никто не захочет менять временные рамки?

Внимательный читатель может заметить, что под графиком справа есть “Timeline: 2014”. Однако, это выглядит как выбор из списка вариантов – например, разные года, или, хотя бы, разные месяцы. А если мне нужен другой промежуток времени, то никак? Если, например, мне нужно пол года, то это тоже будет в списке? Длинный список получится.

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

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

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

Поделиться:

Новый функционал следующей версии JS – ES2018

Как вы знаете, новую версия экмаскрипта (спецификации JS) планируют выпускать каждый год, так что каждый раз будем смотреть, что новенького нам пришло. Прямо подарки от деда Мороза 🙂

  • Асинхронные итераторы
    Раньше нельзя было использовать синтаксис цикла для прохода по итератору. Все решалось в основном через Promise. Теперь можно писать код с асинхронныим циклами:

  • Свойства Rest/Spread для объектов
    Синтаксис “трех точек” уже давно вовсю используется для массивов. С того же времени все говорили о том, что хорошо бы такое же сделть и для объектов. И вот пришло время:

  • RegExp именные группы выборки
    Результат поиска регулярными выражениями всегда был массив. Теперь можно дать имена группам и использовать более очевидный синтаксис:

  • Promise.prototype.finally()
    Метод вызывается, когда Promise вернулось с любым результатом, и после того как отработали основные методы (then(), catch())

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

Ссылки по теме:

Поделиться:

Вордпресс в докере

Во-первых, почему в докере? А как же иначе создать изолированную среду разработки, которая будет максимально подходить под сервер? Разворачивать lamp на домашнем компьютере очень не хочется. Оставим даже то, что по характеристикам все равно не будет соответствовать тому что на сервере. Самая большая для меня проблема в том, что при таком подходе не понятно как мне потом на том же компе развернуть еще среду для питончика, со всеми его плагинами или для go и т.д. В общем вы меня поняли – разработка должна быть изолированной и возможность перехода между языками должна быть максимально быстрой. Поэтому докер – это наш путь.

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

james-bond-martini

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

docker-compose.yml

Это файл конфигурации, который говорит докеру какие контейнеры и с чем запустить. В моем случае их будет два: wordpress и mysql. У каждого указываем какую версию взять. Для вордпресса так же говорим какую папку заменить на локальную – “wp-content”, собственно, это единственная папка, которая имеет значение в разработке. Разумеется еще указываем пароли для базы данных, и все, больше ничего не нужно. Дальше только запускаем:

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

Теперь можно открывать http://localhost:8080 – все должно работать. После того как закончите, то убрать контейнеры можно вот этой командой:

Поделиться:

Docker для бложика

docker-love

Наконец-то перенастроил docker для бложика. Теперь все должно запускаться относительно просто и почти авто-магически. Пол дня с этим возился и ничего больше не успел. Завтра напишу подробный пост. Всем мира и 7 футов под килем.

Поделиться: