Привет, Хаброжители!
У нас вновь вышла книга Дж. Рейнвотера.

«Как пасти котов» — это книга о лидерстве и руководстве, о том, как первое совмещать со вторым. Это, если хотите, словарь трудных случаев управления IT-проектами. Программист подобен кошке, которая гуляет сама по себе. Так уж исторически сложилось. Именно поэтому так непросто быть руководителем команды программистов. Даже если вы еще месяц назад были блестящим и дисциплини-рованным программистом и вдруг оказались в роли менеджера, вряд ли вы знаете, с чего надо начать, какой выбрать стиль руко-водства, как нанимать и увольнять сотрудников, проводить совещания, добиваться своевременного выполнения задач. В таком случае без этой книги вам не обойтись. А может быть, вы — опытный менеджер, желающий пересмотреть свои принципы лидерства? Тогда, опять же, эта книга для вас. Вне зависимости от возраста, пола и социального статуса она поможет вам укрепить свои позиции в роли лидера программистов. Материал изложен довольно компактно и легко укладывается в голове. Стоя в книжном магазине и раздумывая, что же купить, задайте себе один простой вопрос: «Нужно ли мне совершенствовать свои лидерские навыки?» Полагаю, вы ответите: «Да», — а значит, данная книга окажется для вас небесполезной.

Часть 1

Процесс оптимизации

Установить в организации хорошо прописанный и формальный процесс оптимизации – это очень полезная практика, поскольку она:

1. организует рабочий процесс и задаёт реальные сроки окончания
2. устанавливает стандарты контроля качества и уменьшает количество ошибок
3. добавляет веса всей операции – логику процесса можно объяснить владельцам компании

На общем уровне планирования я бы рекомендовал устраивать совещания по планированию оптимизации 1-2 раза в неделю, на которых необходимо:

1. Просмотреть текущие тесты, чтобы понять, нужно ли их остановить или признать «завершёнными» (см. ниже). Для законченных тестов есть две возможности:
   
   1. есть явный победитель. В этом случае необходимо разработать его вывод в продакшн
   2. нет явного победителя в текущей контрольной группе. В этом случае нужно определить, требуется ли дополнительное изучение вопроса, или же нужно просто прекращать эксперимент.
   
   
2. Рассмотреть источники данных и подумать над новыми идеями для тестов
3. Обсудить и назначить приоритет любым новым идеям.

Как же понять, когда тест завершён?

Критерии завершённости – вещь сложная и даже являются коммерческими секретами. Определю минимальные необходимые условия для объявления теста «завершённым». Общепринятых стандартов не существует, и критерии зависят в основном от представлений вашей команды. Мы для себя выработали следующие критерии:

Оптимизация веб-сайтов, известная под именем А/Б тестирование набрала популярность в качестве рабочей техники для многих команд, создающих сайты. Но до сих пор по ней слишком мало всеобъемлющих книг, статей или обучающих материалов, направленных на одиночных разработчиков, стремящихся ввести эту технику у себя в организации.

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

Основы: что такое оптимизация веб-сайтов?

Это метод экспериментов, проверяющих, какой дизайн лучше подходит для вашего сайта. Идея проста:

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

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

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

Скорость работы веб-приложений условно зависит от трех составляющих: 1) как устроена сетевая инфраструктура, через которую доставляются данные и код, 2) как работает браузер и 3) как, собственно говоря, написан ваш код, который браузер должен исполнять.

Все три компоненты постоянно улучшаются и оптимизируются. Например, в сетевом стеке определенные общие улучшения несет переход на HTTP 2.0. С точки зрения браузеров, все производители постоянно работают над улучшением своих движков. В случае Chakra в Microsoft Edge, помимо общего повышения производительности работы с JavaScript, мы добавляем поддержку специализированных средств вроде Asm.js и SIMD.js, призванных повысить эффективность кода в специфичных сценариях (в Firefox и Google Chrome — аналогично).

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

Наши коллеги Дорис Чен и Джон-Дэвид Далтон подготовили целый курс с практическими советами по улучшению производительности вашего кода на HTML и JavaScript. Вы можете посмотреть его на соответствующей странице в Microsoft Virtual Academy или под катом в виде отдельных роликов.

Хочу опубликовать коротенькую заметку о том как интегрировать, зарелизиный совсем недавно, ActionCable в ваш Ruby on Rails проект на примере Live — чата. Я не стану углубляться в то, как работает сам ActionCable, просто приведу небольшой пример использования.

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

Использование значений отрицательной задержки

Скажем, у вас есть несколько анимаций, которые запускаются одновременно, и вам нужно выстроить их в шахматном порядке. Можно использовать animation-delay, но вы не хотите, чтобы пользователь при посещении страницы ждал, пока запустятся некоторые недвижимые части.

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

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

Последний предлагаемый метод спорный, но судите сами!

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

• распространить файл на 100 серверах
• распространить пакет на 100 серверах
• изменить строку в файле
• обновить систему
• добавить пользователя
• перезапустить сервисы

и т.д., администратор инфраструктуры делает руками, поочерёдно заходя на все сервера и выполняя набор из 1-10 команд. Продолжая так работать, вскоре, системный администратор крупной системы превращается в «эникейщика серверной».
И есть два пути решения данной проблемы: нанять младшего сотрудника и «сгрузить» на него всю грязную работу, либо автоматизировать простые и не очень задачи.

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

Больше года назад я опубликовал 12 малоизвестных фактов о CSS (перевод на хабре), и по сей день это была одна из самых популярных статей на SitePoint. С тех пор я собирал больше интересностей и маленьких советов по CSS для новой публикации. Мы же все знаем, что каждый успешный фильм должен способствовать выходу новомодного сиквела, верно?

^{Автор иллюстрации SitePoint/Natalia Balska.}

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

Предлагаю читателям «Хабрахабра» перевод статьи «12 Little-Known CSS Facts (The Sequel)». Она совсем недавно была упомянута в дайджесте интересных материалов из мира веб-разработки и IT.

Update: немного «шлифанул» перевод напильником. Выражаю благодарность всем неравнодушным читателям.
Внимание! Под катом почти 1.5 Мб картинок и много интересных ссылок.

Итак, начнём-с…

1. В свойстве border-radius можно использовать slash-синтаксис.

Об этом уже писалось 4 года назад, но многие новички и даже некоторые опытные разработчики не знают о существовании этой «фишки».

Верите или нет, но следующий код валиден:

.box {
  border-radius: 35px 25px 30px 20px / 35px 25px 15px 30px;
}

Недавно мы в «Я люблю ИП» закончили курсы по дизайну от trydesignlab.com. И это одна из самых важных статей, которую нам посоветовал ментор в процессе обучения. Именно поэтому мы решили её перевести. Посмотреть все наши работы с курсов можно в ВКонтакте по тэгу #design101@iloveip.

Вступление

Сначала о главном. Это руководство не для всех. Это руководство прежде всего для:

• разработчиков, которые хотят уметь делать хорошие интерфейсы для себя, если вдруг прижмёт;
• UX-дизайнеров, которые знают, что хороший UX-дизайн продаётся лучше в красивой UI-упаковке.

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

А пока давайте я расскажу, что вы найдёте в этой статье.

Привет пользователям Хабра.

Сегодня хочу рассказать про домашний веб-сервер, который одновременно прекрасно выполняет функции домашнего медиа-центра (mp3, ip-tv, video, uPnP и т.д.).

Все началось с того, что я уже некоторое время использовал для внутренних нужд сервер HP MicroServer N36L с RAID5 на 4 терабайта(3x2GB HDD WD Green + 8 Gb ECC RAM), с виртуальными машинами на оракловском vBox, который в принципе и неплох, но его постоянное жужжание беспокоило членов семьи в смысле зря съедаемых киловатт в год (если будут интересующиеся, расскажу о нем в одном из следующих постов).
К тому же хотелось чего-нибудь более современного, с возможностью использования в качестве полноценного медиа-центра с прямым подключением к телевизору.

Известный провайдер heroku поддерживает манифест, который называется «12-факторное приложение» (Twelve-Factor App). Это набор лучших практик для разработки современных веб приложений на любой платформе. Практики описывают приложения, которые готовы:

• к горизонтальному масштабированию;
• к непрерывному развертыванию;
• к современным облачным хостингам.

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

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

От переводчика.
Это перевод статьи Филипа Бернарда с сайта css-tricks.com. Часть статьи, содержащую описание работы с созданным им сервисом, я позволил себе опустить. Если вы найдете ошибки, просьба сообщить о них в личном сообщении.

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

Фавикон был представлен в 1999 году, в Internet Explorer 5 (источник) и стандартизирован W3C несколько месяцев спустя. Это была маленькая иконка, представляющая сайт.



С тех пор большинство настольных браузеров следуют тенденции и используют фавикон тем или иным способом. Это очень просто, не так ли? Создать маленькую картинку и добавить в любой интернет-проект, чтобы сделать его «завершённым». Ничего сложного.

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

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

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

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

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



Однако всегда хочется лучшего. Одна из главных проблем, с которыми мы сталкиваемся при общении с владельцами зараженных сайтов, — это поиск источника заражения на стороне сервера. У Яндекса, который каждые сутки размечает тысячи сайтов как зараженные вирусом и опасные для устройств человека, есть регулярно обновляемая база вирусов. И у нашей команды появилась идея, выросшая в большой проект, – антивирус для сайтов. Так мы создали Manul, который решили выложить в open source. Это утилита, которая поможет вебмастеру понять, что произошло с сайтом и вылечить его. Под катом я расскажу подробнее о том, как он устроен и какие проблемы решает.

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

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

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

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

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

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

Зачем нужно адаптировать письма для мобильных устройств

Значительная часть аудитории различных компаний, занимающихся email-маркетингом, просматривают письма на мобильных устройствах. Во время исследования Campaign Monitor от 2011 года выяснилось, что почти 20% открытий писем происходили на смартфонах и планшетах — в 2009 году эта цифра находилась на уровне всего в 4%. Почти 90% от этих открытий осуществлялись на устройствах под iOS. Сейчас цифры еще выше.

В этом руководстве мы рассмотрим несколько способов улучшения отображения почтовых рассылок на мобильных устройствах (от использования media queries при вёрстке адаптивных шаблонов до более продвинутых техник). Кроме того, мы рассмотрим различные вопросы дизайна, которые возникают еще на этапе планирования рассылки, а также поговорим о том, каким образом стоит размещать формы подписки для получения писем на смартфонах и планшетов.