Здравствуйте, Хабр!

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

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

CSS Refresher

Это большая коллекция практических советов и заметок по вёрстке. Своеобразная памятка для тех, кто каждодневно использует CSS. Освещаются самые разные темы, от деталей поведения плавающих элементов до использования SVG и спрайтов. Проект постоянно обновляется, активное сообщество github также принимает в нем участие, там добавляются интересные замечания, о которых, возможно, вы и не слышали.

От переводчика

Приветствую всех, меня зовут Максим Иванов, и сегодня я подготовил для вас перевод заметок разработчика из Сан-Франциско Васанта Кришнамурти (Vasanth Krishnamoorthy) «CSS Refresher». Web-программирование одна из самых быстро развивающихся отраслей в наше время. Казалось бы, возьми какой-нибудь видеокурс на tuts+ и освой html-верстку, однако, как говорил разработчик Opera Software Вадим Макеев, выступая на конференции CodeFest, они все равно это делают плохо. Но давайте посмотрим, может мы итак все это знаем.

Содержание

1. Позиционирование (position)
2. Отображение элемента в документе (display)
3. Плавающие элементы (float)
4. CSS селекторы
5. Эффективные селекторы
6. Переотрисовка и перерасчет
7. CSS3 свойства
8. CSS3 медиа-запросы
9. Адаптивный web-дизайн
10. CSS3 переходы
11. CSS3 анимации
12. Масштабируемая векторная графика (SVG)
13. CSS спрайты
14. Вертикальное выравнивание
15. Известные проблемы

Картинка кликабельна

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

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

К релизу нового корпоративного решения ONLYOFFICE Enterprise Edition мы переписали код серверной части наших онлайн-редакторов на Node.JS и теперь, собственно, хотим поделиться опытом освобождения от ASP.Net, в ловушке которого мы оказались еще пять лет назад.

Переход на Node.JS стал логичным продолжением развития облачного офиса на Linux. Первая версия для него появилась почти год назад — тогда мы приняли решение использовать проект Mono. О проблемах, возникших при портировании на Mono системы для совместной работы, мы уже рассказывали. На тот момент работа над редакторами для Linux'а только начиналась. Сначала вышла бета-версия ONLYOFFICE Document Server, также написанная с использованием Mono. Сейчас она доступна в open source версии 3.0.

В новое серверное решение ONLYOFFICE Enterprise Edition мы включили обновленные редакторы ONLYOFFICE Document Editors 3.5, уже на Node.JS. Почему, как и что получилось расскажем далее.

Вы любите то, чем занимаетесь? Ведь так? Вы любите делиться своими знаниями, и ваш энтузиазм заразителен. Так говорят друзья и клиенты. Но знаний и энтузиазма недостаточно, чтобы продавать продукты и сервисы. Мы перевели статью Enchanting marketing о том, как правильно рассказывать о товарах и услугах.

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

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

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

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

В блоге Печкина на Хабре мы много пишем об интересных техниках работы с email-рассылками. Ранее мы рассматривали распространенные ошибки при создании форм в почтовых письмах, а сегодня представляем вашему вниманию адаптированный перевод заметки команды сервиса Sendwithus о том, какие подходы к разработке писем помогают повышать их конверсию. Первую часть материала можно прочитать здесь, вторую — здесь, а третью — здесь.

Жизнь в Avito заставила перейти на Sketch и начать рисовать в mdpi (1x). Чтобы сразу поддержать телефоны и планшеты. Так как я работаю по адаптированному под себя принципу Atomic Design.

Переход на Sketch я начал c переноса шрифтовых гайдов. Взял телефон с mdpi (1x), установил туда своё тестовое приложение с шрифтовой сеткой Avito. Начал обводить. Такое я уже делал для Photoshop. (Знать точные границы у текста мне надо, чтобы составлять точные спецификации дизайна для разработчиков)

Чтобы Яндекс показал Ваш сайт в числе первых, нужно чтобы он максимально полно отвечал на запрос пользователя. И это будет уже половина успеха. Оставшаяся половина это удобство, техническая составляющая сайта и его простота. Ниже я привел чек-лист из 68 пунктов, который был разработан специально для системы управления задачами PTYSH, совместно с компанией DFAKTOR. А теперь я делюсь им с Вами. Кропотливое выполнение каждого пункта из данного чек-листа позволит вывести практически любой сайт на самый верх поисковой выдачи. Но придется как следует поработать. Начнем с самого малого.

Около двух месяцев назад мы анонсировали конкурс по Material Design. Вот и подходит к концу последняя неделя конкурса (напомним, работы принимаются до 15 ноября), поэтому самое время для последнего рывка. Пока не поздно подать заявку. :)


^{Вы думали, обои для Android 6.0 делают в фотошопе? А вот и нет.}

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

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

К окончанию данного руководства вы получите систему из 3 серверов: балансировщик (lb) и 2 сервера приложений (app1 и app2). Балансировщик будет следить за доступностью серверов и распределять между ними траффик. Серверы приложений будут использовать комбинацию systemd и кластеризации node.js для балансировки траффика между несколькими процессами ноды на сервере. Вы сможете выкатывать код с помощью одной команды со своей машины, и при этом не будет перерывов в обслуживании или необработанных запросов.
Все это можно представить в виде схемы:

3 года назад я поверил в будущее nodejs и начал кампанию по имплементации этого языка в самые “проблемные” сервисы нашего проекта. У нас все получалось — нагрузка падала, стабильность повышалась. Но все же были грабли, о которых захотелось рассказать.

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

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

Ребята из Popcorn Metrics – совершили эту ошибку в A/B тестировании. И чтобы помочь другим не попасть впросак, написали об этом статью. А мы её оперативно перевели, чтобы предостеречь вас от этой ошибки!

Давайте представим ситуацию

Вы проводите A/B тестирование сайта. У вас есть две версии – оригинальная и тестовая. В результате тестирования вы получаете такие результаты: конверсия в регистрацию на оригинальной странице – 2.3 %, в тестовом варианте – 3.2 %. Какая из этих страниц победила в эксперименте?

Конечно, тестовая страница более эффективна. С этим нельзя не согласиться на данном этапе. Почему? Потому что цифры не врут. 3.2 % больше, чем 2.3 %.

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

В сентябре 2015 года Федеральный закон о персональных данных претерпел серьезные изменения. Мы с вами сейчас внимательно их рассмотрим, чтобы понимать, как это все будет работать в реалиях Рунета. Юристы наши много раз говорили о ПДн и до вступления изменений в силу. И вот час настал, и все, что раньше только размусоливалось в теории, теперь введено в работу. Увы, мы пока не прорвались с докладом на главные каналы страны и все, что нам остается, писать сюда. Итак, приступим.

Слишком большое количество предположений опасно.



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

Я называю их Рабочими Историями.

Немного предыстории

Являясь активным пользователем Linux и любителем Open source было замечено, что не все программы регулярно обновляются. Не везде фиксятся баги. И часто не хватает какой-то мелочной утилиты. При беглом гуглении оказывается, что с такой проблемой столкнулся не ты один. Возникает вопрос где же взять этот софт? Заказать у фрилансиров? Можно, но вероятно не рентабельно.

А что если?

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

Эти правила впервые появились в твитах автора сценариев из Pixar, Эммы Коатс [Emma Coats]. Кстати, правило №9,– если вы застряли, сделайте список того, что не может произойти,- подойдёт для писателей, работающих в любых жанрах.