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

• влияние задержки и пропускной способности на веб-производительность;
• ограничения, которые протокол TCP накладывает на HTTP;
• особенности и недостатки самого протокола HTTP;
• тенденции развития веб-приложений и требования к производительности;
• ограничения браузеров и возможность оптимизации.

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


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

«Детали — это не детали. Они создают дизайн.» — Чарльз Имз.

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

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

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

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

Что Вы найдете под катом:

• Описание функциональной типологии
• Объяснение механизмов работы нескольких известных практик
• Примеры из моего собственного опыта

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

Есть некоторое множество объектов, и некоторое множество тегов. Каждый объект может содержать несколько тегов. Какие-то теги очень редкие, а какие-то встречаются часто. Одному объекту один тег может быть сопоставлен несколько раз.
Новые объекты, теги и связи между ними непрерывно добавляются.
Задача — очень быстро отвечать на вопросы вида: «сколько есть объектов, у которых есть тег А или B, но нету тега С» и похожие. На такие запросы хотелось бы отвечать за десятые доли секунды, при этом не останавливая загрузку данных.

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

SELECT 
    COUNT(*) 
FROM (
    SELECT 
        object_id, 
        (MAX(tag == A) OR MAX(tag == B)) AND MIN(tag != C) AS good
    FROM tags
    WHERE tag IN (A, B, C)
    GROUP BY object_id
) WHERE good == 1;

Чтобы такой запрос выполнялся быстро, мы разбили данные между серверами кластера по object_id, а внутри каждого сервера отсортировали их по тегам. Таким образом сервер, выполняющий запрос, может отправить запрос без изменений на все сервера с данными, а затем просто сложить их результаты. На каждом сервере с данными для выполнения запроса достаточно найти строки для тегов A, B и C (а так как данные по тегу отсортированы, это быстрая операция), после чего выполнить запрос за один проход по этим строкам. Худший тег имеет несколько десятков миллионов объектов, несколько десятков миллионов строк обработать за десятые доли секунды видится возможным.
Стоит отметить, что подзапрос содержит GROUP BY object_id. GROUP BY в данной ситуации можно выполнить несколькими способами, например, если данные после тега отсортированы по object_id, то можно выполнить что-то похожее на merge sort. В данной ситуации, однако, мы данные по object_id не отсортировали, и оптимизатор разумно решил, что для выполнения GROUP BY надо построить хеш-таблицу.

Мы загрузили все данные в кластер, и запустили запрос. Запрос занял 25 секунд.

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

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

Но рано или поздно к антресоли, где хранится бесполезное железо, приходит уборка. Большая часть устаревшего, сломанного и просто бесполезного железа отправляется в еще одну коробку, на которой значится гордое «НА УТИЛИЗАЦИЮ». Однако сохраненная матрица ноутбука заставила меня вспомнить давнюю идею — превратить её в полностью рабочий монитор.

Так получилось, что тесть и теща у меня доктора педагогических наук. Что приводит к тому, что волей-неволей начинаешь постигать различные полезные методики :)

Однажды, после какого-то ученого совета за виски чаем на кухне тесть говорит: Саш, а вот как ты считаешь, почему люди чего-то не делают?

Честно сказать, вопрос поставил меня в тупик. Я начал фантазировать: ну, обстоятельства мешают, черты характера, недостаток опыта…

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

• Почему менеджеров проектов надо пересаживать в отдельное здание
• Что делать, когда ваш заказчик не пользуется вашей системой отчетов
• Как раскачать low-performer’а

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

Четвертый пост об открытом терминальном клиенте ОТК-110, он же ультратонкий клиент.

Ссылки на первый пост, второй пост, третий пост.

Инструкция по настройке открытого ультратонкого клиента
Наш сайт — opensourceclient.org/
Описание разработанной нами платы платы DS-110.
форум — opensourceclient.org/forum/

Теперь работает перенаправление подключенного к ОТК-110 принтера в терминальную сессию RDP.
Как обычно использовались только пакеты доступные для debian для armhf из стандартных репозиториев debian.

Около года назад мы представили в блоге мини-компьютер MinnowBoard на базе процессора Intel Atom, адресованный, прежде всего, любителям создавать интеллектуальные и роботизированные устройства своими руками. В комментариях к тому и последующим постам о MinnowBoard заинтересованные пользователи не преминули отметить недостатки этого мини-ПК: высокую стоимость, устаревший процессор и избыточный размер. Тем приятней нам сегодня сообщить, что теперь у нас есть MinnowBoard, в котором все эти проблемы решены – новый MinnowBoard MAX.

Начало года ознаменовалось для нашей команды множеством нововведений, обещанных еще в конце 2013 года. Самым громким, безусловно, стал релиз бесплатного пакета офисных приложений Teamlab Personal, который даже удостоился публикации на TechCrunch.

На прошлой неделе мы анонсировали интеграцию редакторов Teamlab с Google Drive через приложение в Chrome Store. Если вкратце, то вы теперь сможете работать с документами из Google Диска в редакторах Teamlab.
Под катом мы расскажем об этапах реализации, технических сложностях, с которыми мы столкнулись, и конечно же, результатах. Будет несколько абзацев для разработчиков и один для маркетологов. Если читать не хочется, можно сразу установить приложение из Chrome Store и разобраться во всем самостоятельно.

Компания AMI (American Megatrends Inc.) знакомая всем в далеком прошлом и может настоящем времени логотипом в левом верхнем углу монитора при включении компьютера или ноутбука.



Объявила о выпуске утилиты StorTrends IDATA (Intelligent Data Analysis Tracking Application) для интеллектуального анализа узких мест в ИТ инфраструктуре, это бесплатный софтверный инструмент разработанный для определения точной оценки производительности ИТ инфраструктуры, потенциала и требований к пропускной способности. Этот полезный инструмент поможет предупредить болевые точки инфраструктуры, прежде чем они станут головной болью, обеспечив детальные отчеты для принятия необходимых и обоснованных решений из расчета на будущее.

Некоторое время назад я искал описание операций, процессов, происходящих в библиотеке численного моделирования OpenFOAM. Нашел много абстрактных описаний работы метода конечных объёмов, классических разностных схем, различных физических уравнений. Мне же хотелось узнать более детально — откуда в таком-то выходном файле на такой-то итерации получились эти значения, какие выражения стоят за теми или иными параметрами в файлах настроек fvSchemes, fvSolution?
Для тех, кому это тоже интересно — эта статья. Те, кто хорошо знаком с OpenFOAM или с методами в нём реализованными — пишите о найденных ошибках и неточностях в личку.

На хабре уже была пара статей про OpenFOAM:
OpenFOAM на практике
OpenFOAM с точки зрения программиста-физика

Поэтому не буду останавливаться на том, что это «открытая (GPL) платформа для численнного моделирования, предназначенная для моделирования, связанного с решением уравнений в частных производных методом конечных объёмов, и широко используемая для решения задач механики сплошных сред».

Сегодня я на простом примере опишу операции, которые происходят в ходе расчёта в OpenFOAM.

Итак, дана геометрия — куб со стороной 1 метр:

Нет, названием я вовсе не хотел сказать, что это плохая технология, она наоборот прекрасна, но вот её реализации очень различаются. В интернете куча ресурсов, посвященных этой теме, и каждый считает своим долгом сделать сравнение, да еще с кучей графиков и официальных рекламаций. Чтож, значит это и мой долг. Вся разница в том, что мое сравнение будет включать в себя те аспекты, которые были значимы для меня (например проброс USB устройств в гостевые системы и удобство реализации программного роутера), а еще мне будет лень приводить официальные таблицы и значит мое сравнение будет короче, привязано к одной из практических задач. И самое главное — поскольку предприятие, в котором я работаю очень скупо на развитие IT инфраструктуры, то обсуждение будет вестись вокруг бесплатных продуктов. Итак, в ходе домашней и профессиональной деятельности пришлось столкнуться с такими системами, как VMWare vSphere, Microsoft Hyper-V и KVM. Рассмотрим их в порядке моего знакомства:

Идея такой подсветки у меня возникла в связи с законопроектом о приравнивании компьютерных языков иностранным 416D65726963612043616E20436F646520, рассмотренным конгрессом США в декабре 2013. Использование подсветки синтаксиса при создании программ уже давно принятая практика, но вопрос подсветки естественных языков на момент написания этого материала ограничивался парой коротких обсуждений на англоязычных форумах. Тем не менее, если можно облегчить визуальное восприятие текста путём автоматического выделения некоторых слов почему бы не попробовать.

Некоторое время назад к нам обратился один потенциальный заказчик со своей идеей проекта «умного дома». Мы заказчикам всегда рады, особенно если у них есть более-менее внятная идея и достаточно денег для ее воплощения (сразу скажу — этот заказчик пока что является идеалом сферического заказчика в вакууме, повезло нам с ним). Так что после пары встреч родилось общее описание проекта, и мы приступили к поиску вариантов технической реализации. Нужен был недорогой контроллер с поддержкой WiFi и USB, небольшим энергопотреблением и, главное, с достаточно открытой архитектурой, чтобы мы могли сделать на его базе собственное кастомизированное решение.

И тут очень удачно попалась нам на глаза статья. Ух ты, какие штуки бывают, оказывается! У меня самого в качестве передвижной точки доступа для поездок по Китаю (где до сих пор RJ-45 розетка в номере при отсутствии WiFi — довольно частое явление) давно уже используется мини-роутер TP-LINK TL-WR702N, купленный рублей за 700, но тот факт, что внутри живет вполне приличный одноплатный компьютер с кучей дополнительных возможностей, стал для меня приятным сюрпризом. А поскольку мы по своему основному бизнесу плотно завязаны с Китаем (и китайскими производителями электроники в частности), стало нам интересно — во сколько же нам обойдется собственная плата на базе SoC AR9331, если целое законченное решение в корпусе, в коробке, с проводами и блоком питания, стоит в России 700р (на то время — $22) в рознице?

Аннотация

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

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

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

DISCLAIMER

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

Благодарности

Респект Андрею Александровичу Бахметьеву, инженеру и изобретателю. Я горд, что Андрей Александрович преподавал для меня в институте! Желаю ему всяческих успехов в его проектах!

Задача

Итак, есть малый бизнес-стартап, генерирующий порядка 50Гб файлов в неделю, с необходимостью их архивного хранения в течение нескольких лет. Файлы крупные (порядка 10-20 Мб каждый), обычными алгоритмами не сжимаемые. Начальный объем данных порядка 2Тб. Совсем старые данные можно хранить в оффлайне, подключая по требованию.
Нужно уложиться в весьма скромный начальный бюджет решения 500 евро (в ценах лета 2013) и двухнедельный срок на сборку и тестирование.

За эти деньги нужно построить систему, которая позволит работать с файлами небольшой группе в одной локальной сети с разных платформ (Windows, Mac OS). Требуется длительная работа без сисадмина на площадке, защита от отказов и базовые функции управления правами доступа.

Традиционные пути

Безусловно, можно купить сетевое хранилище: их делают NetApp, QNAP, Synology и другие игроки, и притом делают неплохо даже для малого бизнеса. Но наши 500 евро – это только начало разговора для пустой коробки, без самих дисков. Если у вас есть 1000-2000 евро, лучше купите готовое изделие, а мы попробуем максимально заплатить знаниями и минимально — временем и деньгами.

UPD (спойлер ред. 2 от 2014-03-08):


А как же облачное хранение, спросите вы? На момент написания этой статьи популярные облачные хранилища для наших объемов выглядят дороже, чем хотелось бы. Например, стоимость хранения неограниченного объема данных 36 месяцев на известном сервисе Брось Бокс обойдется в пару тысяч долларов с лишним, хотя и выплачивать их можно постепенно. Конечно, есть сервисы вроде Amazon Glacier (благодарю А.М. за подсказку) или Ажурных Окон, но, во-первых, они тарифицируют не только хранение, но и обращение (как его априорно подсчитать?), а во-вторых не будем забывать, что бизнес сидит на Интернет-аплинке 10Мбит, и маневры терабайтами потребуют не только определенных усилий по управлению процессами, но и будут весьма утомительными для пользователей.

Обычно в таких случаях берут старый компьютер, докупают большие диски, ставят Linux (не обязательно, кто-то ухитряется и Windows 7), делают массив RAID5. Отлично. Всё работает хорошо примерно полгода-год, но одним солнечным утром сервер вдруг пропадает из сети без всякого предупреждения. Конечно, сисадмин уже давно работает в другой фирме (текучка кадров), резервной копии нет (объемы слишком велики), а новый сисадмин починить систему не может (при этом на чем свет стоит ругает старого сисадмина и диалект Linux YYY, ведь надо было использовать Linux ZZZ, тогда проблем бы точно не было). Все эти истории повторяются давно и одинаково, меняются только версии ОС и растут объемы данных.

Отраслевые мифы

Миф о RAID5

Самый распространенный миф, в который я и сам верил до недавнего времени – это то, что второго подряд отказа в массиве на практике не может быть по теории вероятности. А вот и может, да еще как! Смоделируем реальную ситуацию: сервер проработал пару лет, после чего в массиве отказывает диск. Пока ничего страшного, ставим новый диск, и что происходит? Ага, реконструкция массива, т.е. длительная максимальная нагрузка на уже порядком изношенные диски. В такой ситуации отказы очень даже возможны и происходят.
Но это не все. Есть еще заложенная производителем методическая вероятность ошибки чтения, которая при определенных обстоятельствах сейчас уже практически гарантирует, что RAID5 после отказа диска обратно не соберется.

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

Эта статья также назрела ввиду того, что многие крупные интернет-проекты рунета в 2014 году получили письма счастья от Google Analytics с предложением заплатить $150 000 за возможность использовать их продукт. Я лично считаю, что ничего плохого в том, чтобы оплатить труд программистов и администраторов нет. Но при этом это довольно серьезные инвестиции, и, может, вложения в собственную инфраструктуру и специалистов, даст большую гибкость в дальнейшем.

Аналитика в ElasticSearch основана на полнотекстовом поиске и фасетах. Фасеты в поиске — это некая агрегация по определенному признаку. Вы часто сталкивались с фасетами-фильтрами в интернет-магазинах: в левой или правой колонке есть уточняющие галочки. Ниже пример тестового фасетного поиска у нас на главной странице http://indexisto.com/.



Буквально неделю назад вышла стабильная версия поискового сервера ElasticSearch 1.0, в которой разработчики настолько серьезно поработали над фасетами, что даже назвали их Aggregation.

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

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

AutoCAD начала 80-х

Зум появился очень давно, на заре эры графических интефейсов, с первыми векторными редакторами.
Но с тех пор он не был использован почти нигде, кроме САПР и программ для работы с графикой. Про него вспомнили только когда появились мобильные устройства — на маленьком экране не умещались большие фотки и веб-страницы.
В мобильных интерфейсах зум стал вполне привычным и естественным и продолжает эволюционировать. Но на десктопе зум заброшен и, на мой взгляд, совершенно напрасно. Zoomable user interface (ZUI) даёт ряд преимуществ, позволяющих лучше решить актуальные задачи. Я решил описать эти преимущества по типам зума, с примерами.