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



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

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



Посмотрим, что можно обнаружить в коде ядра Linux, браузера Chromium и ещё в некоторых проектах.

Привет, Хабр! Этой статьёй я открываю цикл материалов, посвящённых работе с большими данными. Зачем? Хочется сохранить накопленный опыт, свой и команды, так скажем, в энциклопедическом формате – наверняка кому-то он будет полезен.

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

Начинать надо от простого к сложному, поэтому первая статья – о принципах работы с большими данными и парадигме MapReduce.

В этой статье мы расскажем, как включить HTTP/2 для сайта в NGINX, размещенного на VPS от Infobox и какие преимущества это даст вашему сайту. Поддержка HTTP/2 была добавлена в релиз NGINX 1.9.5.

Зачем нужен HTTP/2

HTTP/2 – новая версия протокола HTTP, стандартизированная в начале 2015 года. Использование HTTP/1.1 из-за некоторых особенностей вносит негативный эффект на производительность веб-приложений.

В частности HTTP/1.0 позволяет выполнять только один запрос одновременно в TCP–соединении. В HTTP/1.1 были добавлены конвейерные запросы, но они только частично помогают параллельному исполнению запросов и по-прежнему приводят к блокировкам. Клиенты HTTP/1.0 и HTTP/1.1, которым необходимо делать много запросов сейчас используют множество соединений к серверу.

Кроме этого, поля заголовка HTTP многословны и часто повторяются, производя ненужный сетевой трафик. Также время тратится на заторы TCP. Это может привести к повышенным задержкам при множестве запросов сделанных с помощью новых TCP–соединений.

HTTP/2 решает эти проблемы, определяя оптимизированную семантику протокола HTTP. В частности это позволяет выполнять чередование запросов и ответов через то же подключение и предоставляет эффективное кодирование полей HTTP-заголовка. Также HTTP/2 позволяет приоритизировать запросы, позволяя более важным запросам выполняться быстрее.

В результате протокол становится более дружественным к сети, требуя установки меньшего количества TCP–соединений в сравнении с HTTP/1.x, что приводит к более эффективному использованию сети. Также HTTP/2 дает возможность эффективнее обрабатывать сообщения с помощью бинарного формата.

HTTP/2 тесно связан с SSL. Несмотря на то, что спецификация не требует обязательного использования SSL, все веб-браузеры выпущенные на текущий момент будут работать с HTTP/2 только если веб-сайт использует SSL.

От переводчика: Совсем недавно узнал про эту довольно интересную базу данных и как раз наткнулся на свежую статью. На Хабре нет почти ни слова о RethinkDB, в связи с чем было решено сделать этот перевод. Добро пожаловать под кат!



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

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

Если вы последний год пользовались мобильными приложениями от ВКонтакте (пусть даже не официальными), то этот материал раскроет немного данных по тому, как у нас это время работают пуш уведомления. Пушилка реализована на языке Go, и рассылает до 9 миллиардов пушей в сутки на четыре целевых платформы: GCM, APNS, MPNS, WNS.

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

Не так давно к нам обратился клиент, который занимается видео-трансляциями аукционов и лошадиных скачек в прямом эфире. Сами мероприятия проходят в Австралии, а вот ставки на них делаются игроками в Макао — игровой столице Юго-Восточной Азии. Разумеется, он столкнулся с задержкой сигнала — как без неё. Задержка — это время между взятием кадра и его появлением на экране конечного устройства. И если обычному зрителю задержка в 5 или даже 10 секунд не критична, то тем, кто ставит на тотализаторе, подобная разница может стоить огромных денег. Отсюда возникла задача — свести к минимуму время прохождения видео от источника к зрителю.

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

Мы подумали, что некоторые техники, которые мы применили, будут интересны не только нам.

Итак, цепочку доставки видео схематично можно разделить на 6 этапов: съёмку, сжатие, передачу по локальной сети от энкодера к медиа-серверу, передача через интернет, декодирование и отображение на устройстве пользователя.



Посмотрим, чем определяются издержки на каждом из этапов и как их можно сократить.

В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «14 стандартов» — чего только тут ни напридумано: древние DCOM и Corba, странные SOAP и .NET Remoting, современные REST и AMQP (да, я знаю, что кое-что из этого формально не RPC, для того чтобы обсудить терминологию даже вот специальный топик недавно создали, тем ни менее всё это используется как RPC, а если что-то выглядит, как утка и плавает, как утка — ну, вы в курсе).

И конечно же, в полном соответствии со сценарием комикса, на рынок пришел Google и заявил что вот теперь наконец он создал ещё один, последний и самый правильный стандарт RPC. Google можно понять — продолжать в 21-ом веке гонять петабайты данных по старому и неэффективному HTTP+REST, теряя на каждом байте деньги — просто глупо. В то же время взять чужой стандарт и сказать «мы не смогли придумать ничего лучше» — совершенно не в их стиле.

Поэтому, встречайте, gRPC, что расшифровывается как «gRPC Remote Procedure Calls» — новый фреймворк для удалённого вызова процедур от Google. В этой статье мы поговорим о том, почему же он, в отличии от предыдущих «14 стандартов» всё-таки захватит мир (ну или хотя бы его часть), попробуем собрать билд gRPC под Windows + Visual Studio (и даже не говорите мне, что инструкция не нужна — в официальной документации упущено штук 5 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.

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

Итак, Fresco — многофункциональная библиотека для асинхронной загрузки и отображения изображений с тремя уровнями кеширования (2 в памяти, 1 в internal storage). Поддерживает форматы: JPEG, PNG, GIF и WebP. Так же с помощью Fresco можно поставить ProgressBar непосредственно на View, что очень удобно.

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

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

Работа из учетной записи администратора, root оставьте для расчетов и проверки состояния счета, последнее рекомендую делать почаще, так как оплата производится за количество использованных ресурсов. Услуги Amazon, задействованые в данном хауту — в рамках бесплатного аккаунта, если вы самостоятельно не нажмете еще на какую-нибудь кнопочку в панели управления Amazon.

Ингредиенты

• Основные:
  
  1. Учетная запись Amazon Web Services с правами AdministratorAccess (не root).
  2. LAMP.
  3. Postfix + Policyd + Amavisd + SpamAssassin + ClamAV.
  4. Dovecot + Roundcude (плагины: filesystem_attachments, jqueryui, managesieve, password).
  5. iRedAdmin.
• Сопутствующие:
  
  1. Домен.
  2. Учетная запись ClouDNS.

Инструменты

1. PuTTY.
2. PuTTYgen.
3. FileZilla Client.
4. Mozilla Thunderbird.

Я рад бы написать что “эта статья предназначена для новичков”, но это не так. Большинство php-разработчиков, имея опыт 3, 5 и даже 7 лет, абсолютно не понимают как правильно использовать эксепшены. Нет, они прекрасно знают о их существовании, о том что их можно создавать, обрабатывать, и т.п., но они не осознают их удобность, логичность, и не воспринимают их как абсолютно нормальный элемент разработки.

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

Введение

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

Одним из наиболее распространенных методов естественных вычислений являются генетические алгоритмы. Чтобы лучше разобраться, как эти алгоритмы устроены и как работают, было решно воспроизвести один из таких алгоритмов — генетический. Для того, чтобы применять какой-либо метод для решения конкретных задач этот метод необходимо освоить. Поэтому генетический алгоритм, рассмотренный в данной работе, не решает никакой конкретной задачи. Главными являются одновременно процесс и результат работы по созданию программы по моделированию и визуализации работы генетического алгоритма. Важен полученный программистский опыт.
Программа моделирует поведение популяции самых примитивных живых организмов. Эта программа вряд ли будет иметь какое-либо практическое применение, но она наглядно иллюстрирует принцип работы генетических алгоритмов.

Моделирование работы генетического алгоритма, в котором естественный отбор определяется условиями среды

Моделирование – метод научного познания объективного мира через построение и изучение моделей.

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

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

Для работы выбран язык программирования C++, так как этот язык является мощным, проверенным временем языком программирования. C++ получил широкое распространение среди программистов. Для визуализации использована открытая графическая библиотека OpenGL.

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

На фоне общей увлеченности созданием ботов для Telegram я бы хотел рассказать об API не очень широко известного мессенджера Tox и показать на примере простого echo-бота, как можно так же легко и быстро создавать собственных.

Айти — необъятная отрасль знаний. Бывает, что пятнадцать лет делаешь разный софт, под разные операционки, на разных языках программирования. Вроде много всего знаешь. А потом шаг в сторону — а там Нарния SIP, RTP, SDP и PBX. Последние несколько месяцев я плотно занимаюсь голосовой телефонией и периодически ловлю себя на мысли, что для новичков эта область документирована не особо хорошо. Ну а если по какой-то теме еще не написано десять статей “xxx с нуля”, то это прекрасный повод написать Хабрапост для широкого круга читателей. Сегодня я расскажу небольшую, но интересную часть теорикрафта: как облачные системы телефонии взаимодействуют друг с другом и с телекомами. На примере VoxImplant, конечно же.

Несколько недель назад проект Zadarma опубликовал собственный API. Он позволяет интегрировать основные функции IP-телефонии и бесплатной облачной АТС.
Каждый может за считанные минуты создать бесплатную облачную АТС и подключить к ней интерфейс API, а через него уже интегрировать АТС со своими приложениями.
В статье публикуем список и описание методов, ссылки на классы и примеры, которые уже есть для работы (опубликованы PHP-классы). Нам крайне интересны ваши отзывы: для дальнейшего развития интерфейса API, интеграции с CRM и другими системами.

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

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

Одна из неприятных особенностей Sphinx'а — очень скудная информация на русском языке. Удивишись тем, что тема распределения нагрузки не была затронута, решил поделиться данным решением на Хабре.

Цель: повысить производительность Sphinx путём разделения нагрузки на несколько потоков.