БЭМ набирает популярность и становится актуальнее — например, недавно Google выпустил новую библиотеку блоков под названием Material Design Lite, реализованную по БЭМ-методологии. Команда БЭМ тоже не сидела без дела — мы выпустили новую версию библиотеки bem-components, на базе которой построены сайты и проекты не только Яндекса, но и других разработчиков.

Эти события натолкнули нас на мысль ещё раз вспомнить и рассказать вам, как сформировались принципы разработки библиотек в БЭМ-методологии. Надеемся, что многим это будет интересно и полезно. Итак, поехали.



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

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

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

Я, как и многие из хабровчан, люблю новинки. Релиз нового софта — это как праздник. Новые фичи, новые возможности… Новые способы забивать гвозди и кататься на велосипедах. Новые велосипеды… В общем можно придумать кучу аллегорий и метафор. А про что это я? Ах да, про Nginx, HTTP2 и JavaScript. Чем они связаны, спросите вы? А тем, что в последней версии Nginx (1.9.5) добавили много интересных плюшек, а именно:

• добавили протокол HTTP2 и удалили модуль SPDY (нафиг старое барахло)
• интегрировали прямо в nginx модуль ngx_http_js_module и создали свой диалект JavaScript

Го под кат, расскажу детали.

Все, кто следил за мной или моей работой на протяжении какого-либо времени, бесспорно знают, что я огромный фанат соглашения о наименованиях БЭМ. То, о чем я расскажу в этой статье, является не альтернативным или другим соглашением о наименованиях БЭМ, а дополнением к нему: небольшими добавками, которые поднимут БЭМ на ступеньку выше. Этот расширенный синтаксис БЭМ окрестили BEMIT, так как он включает некоторые парадигмы и шаблоны из (еще неопубликованной) архитектуры CSS в виде перевернутого треугольника (ITCSS). BEM + ITCSS = BEMIT.

Вспомним, что такое БЭМ – он работает за счет разбивки всех классов в базе кода на три группы:

На прошлой неделе BBC рассказала, что для новой версии главной страницы использовала методологию БЭМ, созданную в Яндексе. По такому случаю мы решили поднять материалы мастер-класса «Разрабатываем сайт с нуля на полном стеке БЭМ-технологий» и рассказать вам, как начать использовать полный стек БЭМ-технологий в своих проектах.

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



В статье мы расскажем, в чём преимущество вёрстки независимыми блоками и что такое уровни переопределения, познакомимся с готовыми библиотеками блоков и инструментами для автоматизации сборки. Покажем, как разные инструменты — например, autoprefixer, css-препроцессор Stylus или модульная система YModules — упрощают жизнь разработчика и создают по-настоящему удобную платформу, если встроить их в процесс разработки по БЭМ.

На живом примере мы объясним, в чём польза декларативного подхода, когда одни и те же идеи можно использовать как для CSS, так и для JavaScript. Отдельно остановимся на декларативных шаблонах BEMHTML и BEMTREE, которые позволяют преобразовывать данные в БЭМ-дерево, описанное в формате BEMJSON и, затем в HTML. Рассмотрим в деталях, как написать серверную часть приложения по БЭМ-методологии.

Здравствуйте уважаемые Айтишники и Эмбеддеры. На Ваш суд и мнение выношу выше озаглавленный пост.



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

Внимание! Под катом трафик!

Доброго всем времени суток. Недавно столкнулся с проблемой, с которой в свое время сталкиваются все обладатели того или иного компьютера (в данной случае ноутбука), а именно — медленной работой и нехваткой ресурсов для нормальной работы вашего девайса.

MacBook MB467

До:
Процессор: Intel Core Duo 2.4 GHz
Шина: 1066 MHz
Кеш 3 MB
Память (RAM) 4096 MB
HDD 250 GB

После:
Процессор: Intel Core Duo 2.4 GHz
Шина: 1066 MHz
Кеш 3 MB
Память (RAM) 8 GB
SSD 60GB + HDD 250 GB

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

Активные пользователи Mac OS X наверняка помнят анонсированную 23 октября функцию Fusion Drive. Напомню, что она представляет из себя логическое объединение установленных в ваш Mac SSD и HDD. Объем единого диска будет равен сумме объемов SSD и HDD, но главные плюс — часто используемые файлы (например, ядро системы) Mac OS автоматически и прозрачно для пользователя размещает на более быстром SSD, а все прочие файлы на HDD.

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

Скорее всего, вы уже знаете об одной из таких методологий, разработанной Яндексом, — БЭМ. БЭМ утверждает, что трёх сущностей (блоков, элементов и модификаторов) достаточно для написания HTML и CSS, задания структуры кода и компонентной структуры с последующим масштабированием проекта до самого высокого уровня.

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

Могут ли маленькие команды получить от БЭМ то же самое? Я совершенно не был в этом уверен. Всё же БЭМ — абстракция, которая поставляется вместе с инструментами и технологиями. Для маленькой компании польза от переключения на «полный стек» этих технологий — сомнительна, многие из инструментов изначально приспособлены под крупные и сложные задачи. Быть может, тогда полезной окажется сама идея, сама методология?

Изначально эта моя статья была опубликована в известном многим журнале Smashing Magazine. Но я решил, что и на Хабре она может быть интересна, ведь многие здесь занимаются собственными небольшими проектами.

Некоторое время назад мы довольно подробно начали рассказывать об одной из базовых облачных технологий Яндекса — Elliptics. Сегодня настала очередь поговорить о другой — той самой, под которой работают «эльфы» и которая делает мечту о своем облаке чуть ближе к реальности. Речь пойдет о Cocaine.

Cocaine (Configurable Omnipotent Custom Applications Integrated Network Engine) — это PaaS-система (Platform-as-a-Service) с открытым исходным кодом, являющаяся по сути app engine и позволяющая создавать собственные облачные хостинги приложений — такие, как Google AppEngine, OpenShift, CloudFoundry или Heroku.



Всем известно, что облака могут решить все инфраструктурные проблемы, превратить издержки в прибыль и насытить вашу жизнь бесконечной радостью и счастьем на веки веков. Единственным препятствием на пути к этим целям являются, собственно, облака. IaaS, PaaS, SaaS? Whatever-as-a-Service? Какой именно загадочный набор букв нужно выбрать, чтобы всё наконец стало хорошо?

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

В конце сентября компания APPLE выпустила iOS 7, одной из особенностей этой версии стала улучшенная многозадачность и возможность обновления данных, когда приложение не активно.
Есть два варианта запуска приложения для обновления данных — периодические обновления и запуск при получении специального push-уведомления. В каждом из вариантов приложение будет запущено в фоновом режиме (background mode), и будет принудительно закрыто через 30 секунд, так что времени для обновления будет совсем мало.

Вроде закончилась неделя 30 строк кода и взамен ей видимо пришла неделя "БЭМ". Причем прослеживается достаточно забавная очередность топиков:

• Верстаем веб-страничку за 15 мин.
• На БЭМ'е было бы лучше!
• Сами вы ешьте свой бем, у меня препроцессоры!

И самое интересное, как всегда, в комментариях — чистой воды холивар. Но из-за чего? Почему одни свято верят в методологию БЭМ'а, другие презирают её как узурпатора семантичности? Я попробую изложить свою точку зрения на суть всего холивара и прояснить в первую очередь для себя положение БЭМ'а в собственном мироздании.

^{Вот так люди видят вашу страницу}

Привет!
Проблема вот в чём. Если зайти на практически любой сайт интернет-магазина или компании с услугами, вы встретите контент. Точнее — отвратительные тексты, которые писали, кажется, маркетологи, воспитанные сеошниками.

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

По моим примерным подсчётам (усреднение с ряда позиций), конверсии для нас выглядят так:

• Только название и картинка — около 1,5%.
• С описанием от производителя — чуть более 2%.
• С описанием человека, который держал это в руках и знает правила — около 6%.

Ниже — рассказ про то, как мы доводили время на сайте от 3 минут сначала до 6:40, а потом до 20:48. Да-да, двадцати минут сорока восьми секунд для среднего посетителя. Честного среднего, с учётом отказов и по полной выборке.

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

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

Третья часть статьи из цикла «Продающий дизайн интернет-магазина». Для тех, кто пропустил первую и вторую, их можно прочитать тут: «Продающий дизайн интернет-магазина. Часть 1. Аналитика» и «Продающий дизайн интернет-магазина. Часть 2. Элементы интерфейса».

Страница товара

Попав на страницу товара, человек должен получить максимум информации о нем. Здесь не работает правило «краткость – сестра таланта». Так как мы имеем дело с онлайн магазином, то наш покупатель лишён возможности увидеть товар вживую, поэтому мы и должны предоставить ему максимум имеющейся у нас информации: детальное описание, технические характеристики, качественные фотографии, отзывы, видео или 3D-обзор. Отзывы для товаров, кстати, изобрел Амазон, внес социальность на сайт, сильно увеличив тем самым конверсию и продажи.

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

Всем привет!
Хочу начать вольный перевод книги «ZeroMQ.Use ZeroMQ and learn how to apply different message patterns». Уверен, что многие захотят разобраться с этой интересной библиотекой.

Содержание

• Глава 1: Приступая к работе
• Глава 2: Знакомство с сокетами
• Глава 3: Использование топологии сокетов
• Глава 4: Дополнительные паттерны

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

• Обзор того, что представляет собой очередь сообщений
• Зачем использовать ZeroMQ и что отличает ее от других технологий работы с очередями сообщений
• Основы клиент/серверной архитектуры
• Рассмотрим первый паттерн: запрос-ответ
• Как мы можем обрабатывать строки в C
• Проверка установленных версий ZeroMQ

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



У меня все работает!

Существует расхожее мнение, что проблемы решают исполнители, а управленцы только ходят и мешают. Однако что происходит, если на проекте нет менеджера? Представим ситуацию: в саппорт приходит гневное письмо: «Я нажал на кнопку, а там 500-я ошибка!». Причем письмо приходит не одно, то есть проблема массовая.

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

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

Итак, введение.

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

От переводчика: Это пятая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Как написать приложение Node.js, которое будет продолжать работать даже под невозможной нагрузкой? В этой статье показана методика и библиотека node-toobusy, её воплощающая, суть которой наиболее кратко может быть передана этим фрагментом кода:

var toobusy = require('toobusy');
 
app.use(function(req, res, next) {
  if (toobusy()) res.send(503, "I'm busy right now, sorry.");
  else next();
});

В чём заключается проблема?

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

Это может быть и злонамеренный всплеск трафика, например от DoS-атаки. Первый шаг к борьбе с такими атаками — написание сервера, который не падает.

Всем привет!
Продолжаю перевод книги John Torjo «Boost.Asio C++ Network Programming».

Содержание:

• Глава 1: Приступая к работе с Boost.Asio
• Глава 2: Основы Boost.Asio
  
  • Часть 1: Основы Boost.Asio
  • Часть 2: Асинхронное программирование
• Глава 3: Echo Сервер/Клиент
• Глава 4: Клиент и Сервер
• Глава 5: Синхронное против асинхронного
• Глава 6: Boost.Asio – другие особенности
• Глава 7: Boost.Asio – дополнительные темы

В этой главе мы рассмотрим некоторые из не очень известных особенностей Boost.Asio. Объекты std streams и streambuf иногда немного сложнее в использовании, но, как вы сами убедитесь, у них есть свои преимущества. Наконец, вы увидите довольно позднее добавление в Boost.Asio — co-routines, которое позволит вам иметь асинхронный код, но легко читаемый (как буд-то бы он синхронный). Это довольно удивительная особенность.