Мишко Хевери, главный разработчик Ангуляра, как-то упомянул, что приложение гарантированно работает без тормозов, если в нем не более 100 активных областей видимости. Такой подход, в общем, применим к любым приложениям. В играх давно не рендерят то, чего игрок не видит и только в вебе пока еще считается нормой отобразить целиком список из нескольких тысяч элементов. С приходом js-фреймворков ситуация должна измениться и лучшим решением станет удаление из DOM того чего нет на экране, нежели отказ от промежуточных тегов, биндингов и других вещей, облегчающих разработку. Поэтому провел небольшой анализ решений для отображения больших списков. Наткнулся на пару статей:

1. The Infinite Path of Scrolling

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

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

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

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

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

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

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

Довольно подробное и интересное изложение материала, касающегося кэша и его использования. Часть 2.

Автор, Mark Nottingham, — признанный эксперт в области HTTP-протокола и веб-кэширования. Является председателем IETF HTTPbis Working Group. Принимал участие в редактировании HTTP/1.1, part. 6: Caching. В настоящий момент участвует в разработке HTTP/2.0.

Текст распространяется под лицензией Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 Unported License.

От переводчика: об опечатках и неточностях просьба сообщать в личку. Спасибо.

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

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

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

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

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

Жил да был у меня роутер одной хорошей фирмы на букву «Dead». Ну, это с ним, собственно, и случилось.
Посмотрел я на цены новых, на кучу компьютерного хлама в углу, на список подключений на домашнем компе… И понял, что не нужен мне роутер. Соберу свой, с нормальной маршрутизацией, DNS, WINS, i2p, блекджеком и так далее.

Обновляю 4-летний список бесплатных сервисов для управления доменами

Primary + Secondary

Сервис	Кол-во NS	Кол-во доменов	Типы записей	TTL	Доп. фичи
pdd.yandex.ru	2	50	AAAA и SRV	+	Есть API
cloudflare.com	2	неограниченное	AAAA, SRV, SPF, LOC	+
2ns.info	4	неограниченное	AAAA и SRV	+	Есть экспорт. Показывает регистратора, дату регистрации домена, дату окончания регистрации, тИЦ. By leonid239
dns.he.net	5	50	все	+	NS доступны по IPv6. Свой DDNS-сервис
www.netbreeze.net/dns	3	1	AAAA и SRV	+	Есть API
entrydns.net	3	неограниченное	AAAA и SRV	+	Есть свой DDNS-сервис, REST-api

К моему удивлению на целом хабрахабре нет ни одного поста где бы было понятно написано про 3 вида git reset. Например, во второй по релевантности статье по запросу «git reset» автор пишет что «данное действие может быть двух видов: мягкого(soft reset) и жесткого(hard reset)». Режим --mixed, используемый по умолчанию, почему-то не удостоился упоминания.

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

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

Это первая статья. Всего их будет 3.

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

1. Что такое IEMs?

Внутриканальные наушники (англ. In-Ear-Canalphone), еще именуемые как затычки, реже ухо-мониторы или (правильное) IEMs (в дальнейшем в статье будет именно это название, т.к. оно очень лаконичное и нравится автору) — это наушники, внешне очень похожие на вкладыши, но разработанные для максимальной звукоизоляции ушного канала слушателя. Ее (звукоизоляцию) еще называют, звуковая «герметизация», — она имеет две функции: блокировка лишних шумов и формирование звуковой площади (камеры) для достижения полноты звучания. Создает такую герметизацию насадка, надетая на сопло наушника и вложенная в переднюю часть ушного канала. Существуют также наушники, где насадка создана по слепкам ушей владельца, — они называются (у русскоговорящей аудитории) кастомами (англ. Custom molded earplugs), — подобные вещи служат для достижения максимального качества звука и комфорта от прослушивания.

Почему выбирают IEMs? Из-за высокой портативности, качественного звука и способности к блокировке лишних шумов. Некоторые модели уже давно используют аудио-инженеры; музыканты, выступая на сцене. Затычки (в России это название прижилось больше), являются разновидностью IEMs. Когда производители внутриканальных наушников начали клепать их для общего потребителя (поколение iPod), аббревиатура IEMs стала более популярна (не в России), заменив выражение «затычек».  Техническим языком правильно «затычки» называть — IEMs. Реже аббревиатура IEMs используется для обозначения внутриканальных наушников высокого качества.

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

• необходимость A/B-тестирования разных версий одной и той же игры
• возможность по максимуму переиспользовать функциональность от одной игры в другой
• высокую вероятность географической удаленности от разработчиков занимающихся клиентской частью игры

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

Цель данной статьи – рассказать о проделанных шагах, принятых решениях и описать полученный результат.

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

Существует мнение, что nginx — отличный инструмент для отдачи статики.
Есть статьи, где описываются настройки sendfile или aio для «улучшения» отдачи.
На Хабре есть чего почитать о настройке proxy_store с proxy_cache для минимизации проблем со стороны мозгов сайта.
Еще в QA иногда возникают вопросы про кеширование картинок, например.

Зачем заниматься этой ерундой! — говорят опытные пользователи — OS лучше вас знает как кешировать файлы! С кешем и префетчем в современных OS, точнее FS, проблем нет! Зачем плодить свои кеши и списки популярных материалов и все такое?...

Есть только одно вредное «но» — в среде исполнения nginx (в общем случае Linux) понятие "файл" и вообще «файловая система» — просто понятие.
И однажды, когда я, подмонтировав сервер по sshfs, обновил один скриптик, случилось волшебное:
1. На каждой страничке стало на 4 картинки больше.
2. Сервера сдохли.
Что поделать — картинки хранились на glusterFS. Наступил полный FUSE.

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



Кстати, если вам понравится этот рассказ, приходите на Тестовую среду в нашем питерском офисе 30 ноября (зарегистрироваться), – там я расскажу больше об игровых механиках в тестировании и с удовольствием вживую с вами поговорю. Итак.

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

Посмотрев недавно статью, был сильно удивлен, что кто-то еще задается вопросом автоматического прописывания ДНС доменов на вторичном сервере. Хочу поделится своим вариантом «Automate slave DNS support», которым пользуюсь уже много лет. Возможно он подойдет не всем, но он довольно прост.

Мобильные приложения, это не будущее разработки, это уже настоящее. В настоящее время пользователей мобильных приложений уже 1.2 млрд. человек, и это количество постоянно растет (Wikipedia). Вскоре количество мобильных устройств превзойдет количество людей на планете. Если скорость роста количества мобильных устройств останется неизменной, то к 2017 году ими будут пользоваться 5.1 млрд. человек.
Для нас, как для разработчиков приложений, важно разрабатывать свои приложение с учетом мобильных пользователей, если мы хотим чтобы они были востребованы. В AngularJS реализована поддержка мобильных устройств, написанная как командой AngularJS, так и сообществом.
В этой статье мы будем работать с двумя различными способами, чтобы дать читателям опыт в разработке мобильных приложений.

Angular — зрелый и мощный JavaScript-фреймворк. Он довольно большой и основан на множестве новых концепций, которые необходимо освоить, чтобы работать с ним эффективно. Большинство разработчиков, знакомясь с Angular, сталкиваются с одними и теми же трудностями. Что конкретно делает функция digest? Какие существуют способы создания директив? Чем отличается сервис от провайдера?

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

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

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

Федеральная власть

• Определение открытых данных на сайте Правительства России
• Совет по открытым данным при комиссии по открытому правительству
• Открытые данные на сайте Административной реформы (Минэкономразвития России)
• Веб-сервисы Банка России
• API Государственной Думы

Регионы и муниципалитеты

• Каталог на сайте Административной реформы
• Портал открытых данных Москвы
• Томская область
• Тульская область
• Амурская область
• Ульяновская область
• город Краснодар

Общественные проекты и блоги

• ГИС Лаборатория — сообщество по открытым геоданным
• Проект по Semantic Web и Linked Data
• Хаб открытых данных (НП «Информационная культура»)
• Раздел открытых данных на ХабраХабре
• Блог Ивана Бегтина (дисклеймер: автор этого поста)
• Блог Ирины Радченко
• Блог Екатерины Аксеновой

Журналистика данных

PassportJS — это middleware для авторизации под node.js. Passport поддерживает авторизацию с помощью огромного количества сервисов, включая «ВКонтакте» и прочие твиттеры. Список сервисов можно просмотреть здесь. Я хочу немного рассказать о том, как работает этот middleware на примере самой обычной авторизации с помощью логина и пароля.

Для самых нетерпеливых — готовый проект можно посмотреть здесь.