Недавно наткнулся в сети на баннер с рекламой конкурса по дизайну блога юкоза. Приз – iMac 27”. Честно хотел пройти мимо, но заманило то, что оценивать работы будет профессиональное жюри без влияния социальных лайков. Как же я был наивен.

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

Мы рады сообщить, что тестировать производительность сайтов стало проще, благодаря новым инструментам F12, предназначенным для поиска и исправления связанных с ней проблем. В этом кейсе мы использовали сканер Modern.ie и профилировщик UI из нового набора F12 в IE11. Мы показали эти инструменты разработчикам из команды swish.com, чтобы узнать, как популярный сайт может их использовать для оптимизации работы типичных сценариев его использования. Результат – загрузка сайта стала на 2 секунды быстрее: рост производительности на 40% благодаря нескольким простым изменениям в коде.



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

Привет Хабр! Примерно год назад я представил вашему вниманию первую версию open-source библиотеки FileAPI, предназначенную для работы с файлами на клиенте и последующей загрузки на сервер.

За это время был пройден долгий путь. Библиотека заработала 670+ звезд и 90+ форков. С помощью github-сообщества удалось исправить множество «детских» проблем и внести ряд улучшений. Было закрыто более 100 тасков, и благодаря Илье Лебедеву сделана загрузка файлов по частям. Сегодня я с гордостью хочу представить вам FileAPI 2.0.

I-Tier: Расщепление монолита

Недавно мы завершили годовой проект миграции веб-трафика компании Групон в США от монолитного Ruby on Rails приложения к новому стеку Node.js и получили существенные результаты.

С самого начала весь веб-фронтенд американского Групона был единым исходным кодом Ruby. Код фронтенда быстро развивался, что затрудняло его поддержку и усложняло процесс добавления новых фич. В качестве решения проблемы с этом гигантским монолитом мы решили реструктурировать фронтенд посредством его разделения на меньшие, независимые и более простые в управлении части. Основой этого проекта стало разделение монолитного вебсайта на несколько независимых Node.js приложений. Мы также переделали инфраструктуру, чтобы обеспечить совместную работу всех приложений. Результатом стал Interaction Tier (I-Tier).

Вот некоторые из важных моментов этой глобальной архитектурной миграции:

• Страницы на сайте загружаются значительно быстрее

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

• Мы можем избежать повторной разработки одних и тех же фич в разных странах, где доступен Групон.

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

Читая публикации о верстке для вэба, вы не раз натыкались на рекомендацию не использовать пикселы в media queries. Например, вот цитата из совсем недавней статьи на Хабре:

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

Что, если я скажу вам, что использование пикселов в media queries не только не причиняет никакого вреда верстке, но и имеет преимущества над использованием em'ов?

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



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

1. не обязательно управлять свободным пространством;
2. не надо тратиться на журналирование;
3. можно не заботиться о фрагментации и хранить файлы непрерывно;
4. возможно собрать всю мета-информацию в одном месте и эффективно ее кэшировать;
5. грех не сжимать мета-информацию, раз уж она оказалась в одной куче.

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

Немножко пятничного настроения в субботу. Я думаю, все видели этот код:



Но Aras Pranckevičius пошел еще дальше. Как написать код, который не так просто обнаружить?
И если вначале идут простые примеры, то дальше начинается…

Я работаю над визуализацией парапланерных соревнований — пишу плеер просмотра гонки для Airtribune.com. В процессе работы мне попадаются интересные и нестандартные задачи. Одна из них — задача быстрой отрисовки маркеров и треков на карте google maps.

Масштабы такие: есть ~200 трекеров в довольно ограниченной области (50x50км), каждый передает данные о своем положении раз в 10 секунд. Нужно их все отрисовать на карте и плавно перемещать при изменении координат. За каждым маркером должен отрисовываться трек. Картинка примерно следующая:



Скоро обнаружилось, что встроенные объекты — google.maps.Marker и google.maps.Polyline — для данной задачи работают слишком медленно. Была куча идей по оптимизации, и в результате получилось решение на canvas-е, которое работает со скоростью 40fps даже на тысяче маркеров. Впрочем, fps вы можете померить сами — я собрал тестовое приложение для сравнения 4-х движков, в котором на лету можно подключать разные фишки и смотреть на скорость работы.

После поста о derby.js и перевода сравнения meteor.js и derby.js, главный вопрос, который был в комментариях, звучал примерно так: «Что всё таки лучше derby.js или meteor.js? И зачем вообще всё это нужно, когда можно писать на angular.js + express.js?». Конечно не совсем корректно сравнивать эти фреймворки, так как derby.js и meteor.js — это так называемые full-stack, а angular.js — mvc на клиенте.

В рамках программы по унификации установленных серверных систем встала задача по переделке почтового сервера. Вдумчивое изучение мануалов и руководств показало довольно любопытный факт – нигде не было найдено однозначно достоверного руководства или подобия Best Practice по развёртыванию почтовика.

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

Предисловие

Печально видеть, что статьи о предупреждении или предотвращении вторжений на хабре столь непопулярны.
Курс молодого бойца: защищаемся маршрутизатором. Продолжение: IPS — 5 плюсов.
SNORT как сервисная IPS — 25 плюсов.
OSSEC: Большой Брат наблюдает за тобой — 13 плюсов.
Однако, огромной популярностью пользуются статьи по разбору последствий проникновения. Попробую вбросить очередную популяризацию информационной безопасности.

Описание Suricata

Система предотвращения вторжений (англ. Intrusion Prevention System) — программная или аппаратная система сетевой и компьютерной безопасности, обнаруживающая вторжения или нарушения безопасности и автоматически защищающая от них.
Системы IPS можно рассматривать как расширение Систем обнаружения вторжений (IDS), так как задача отслеживания атак остается одинаковой. Однако, они отличаются в том, что IPS должна отслеживать активность в реальном времени и быстро реализовывать действия по предотвращению атак. Возможные меры — блокировка потоков трафика в сети, сброс соединений, выдача сигналов оператору. Также IPS могут выполнять дефрагментацию пакетов, переупорядочивание пакетов TCP для защиты от пакетов с измененными SEQ и ACK номерами.
wiki

Suricata — open source IPS/IDS система. Основана разработчиками, которые трудились над IPS версией Snort. Основное отличие Suricata от Snort — возможность использования GPU в режиме IDS, более продвинутая система IPS, многозадачность, как следствие высокая производительность, позволяющая обрабатывать трафик до 10Gbit на обычном оборудовании, и многое другое, в том числе полная поддержка формата правил Snort. Лучше почитать обо всём на официальном сайте. Cегодня погорим об IPS.

Портал SecurityLab.ru анонсирует запуск функционала подписки на уязвимости.

Теперь все желающие могут подписаться на рассылку и оперативно получать уведомления об уязвимостях по интересующим их продуктам. Cервис является абсолютно бесплатным, в отличие от других аналогичных услуг, предоставляемых различными компаниями.

Выбрать ПО из списка можно на странице по ссылке: http://www.securitylab.ru/subscribe/vulnerability/

Разработка

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.

dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны.

Удачная возможность для веб-разработчиков выучить язык программирования Си — HTML5-парсер Gumbo, реализованный в виде небольшой библиотеки C99 без внешних зависимостей. Парсер создан как строительный блок для создания других инструментов и библиотек, таких как валидаторы, языки шаблонов, инструменты рефакторинга и анализа кода.

Особенности:

• Полная совместимость со спецификациями HTML5.
• Устойчивость к некачественным входным данным.
• Простые API, которые могут быть легко обработаны программами на других ЯП.
• Поддержка исходных позиций и указателей в оригинальном коде, при навигации по дереву зависимостей.
• Проходит все тесты html5lib-0.95.
• Проверен на более чем 2,5 млрд страниц в индексе Google.

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

Использование контейнера для каждого изображения

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

<div class="img_wrapper">
    <img src="comicbookguy.jpg" alt=""/>
</div>

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

Тема анонимности в Интернете является сейчас достаточно модной и интересной, и особенно теперь, когда новостные порталы пугают наc всякими там PRISM, правительственными инициативами и прочим. Большинство людей озабочены тем, как сохранить тайну своей личности в сети и поэтому все темы так или иначе посвящены ЗАЩИТЕ. Но иногда, раскрытие анонимности это не такое уж и плохое дело. Да-да, эта заметка — мой опыт борьбы с анонимностью своими силами, без помощи спец-служб…

Хочу поделиться своими наработками по настройке nginx, которые, возможно, помогут кому-то при старте нового проекта или избавят от необходимости копипастить очередной vhost.

Я отметил две проблемы подавляющего числа конфигов nginx'а, попадавших мне на глаза:

• «Всё в одном файле»
• Дублирование настроек

С помощью моего подхода, надеюсь, эти и многие другие проблемы будут устранены.

На сегодняшний день в Google Play насчитывается более 800 тысяч приложений. Многие из них реализованы на основе клиент-серверного общения. При разработке таких приложений нужно учесть три основных момента, о которых пойдет речь в этой статье.

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

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

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

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

При этом эти три примера связаны с тремя разными факторами: хакер Вася специально охотился за вашим мусором; хомяк Билл показал нам отказ оборудования; а администратор Пупкин просто клинический раздолбай. За последний год только 37% проблем с данными были результатом действий запланированных атак. 29% случаев пришлось на сбои систем. И оставшиеся примерно 34% – на человеческий фактор, то есть халатность персонала.

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