Можно ли объединить несколько интернет-каналов в один? Вокруг этой темы куча заблуждений и мифов, даже сетевые инженеры с опытом часто не знают о том, что это возможно. В большинстве случаев, объединением каналов ошибочно называют балансировку на уровне NAT или failover. Но настоящее суммирование позволяет пустить одно единственное TCP-подключение одновременно по всем интернет-каналам, например видеотрансляцию так, чтобы при обрыве любого из интернет-каналов вещание не прерывалось.

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

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

Фотография пользователя Wonderlane, Flickr

NGINX великолепен! Вот только его документация по ограничению скорости обработки запросов показалась мне, как бы это сказать, несколько ограниченной. Поэтому я решил написать это руководство по ограничению скорости обработки запросов (rate-liming) и шейпингу трафика (traffic shaping) в NGINX.

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

Работая над статьей «Глубокое обучение на R...», я несколько раз встречал упоминание t-SNE — загадочной техники нелинейного снижения размерности и визуализации многомерных переменных (например, здесь), был заинтригован и решил разобраться во всем в деталях. t-SNE это t-distributed stochastic neighbor embedding. Русский вариант с «внедрением соседей» в некоторой мере звучит нелепо, поэтому дальше буду использовать английский акроним.

Опубликовано 4 июня 2018 года в корпоративном блоге browserless

Рады сообщить, что недавно мы преодолели рубеж в два миллиона обслуженных сессий! Это миллионы сгенерированных скриншотов, напечатанных PDF и протестированных сайтов. Мы сделали почти всё, что вы можете придумать делать с headless-браузером.

Хотя приятно достичь такой вехи, но на пути оказалось явно много накладок и проблем. В связи с огромным объёмом полученного трафика хотелось бы сделать шаг назад и изложить общие рекомендации для запуска headless-браузеров (и puppeteer) в продакшне.

Вот некоторые советы.

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

Итак, все началось в тот день, когда мы решили зарегистрировать торговую марку нашего сервиса в России. На тот момент у нас уже была зарегистрированная ТМ в США, поэтому мы не ожидали никаких проблем с регистрацией в РФ. Однако, реальность внесла свои коррективы. Через неделю после начала стандартной процедуры регистрации, мы получили письмо от патентного поверенного, которое, мягко говоря, выбило нас из колеи:

На сегодняшний день favicon — это не просто значок 16x16 во вкладке браузера. Он является важной составляющей интерфейса, а также играет немаловажную роль в прогрессивных веб-приложениях. Существует немало способов подключения и использования favicon, о которых я расскажу в данной статье.

Дизайн — это фашизм. Фашизму нужна питательная среда. Он начинает раскрываться в полной мере только на крупных масштабах. Идеальная среда для фашизма — это большая компания с огромным количеством продуктов. Например, Google или… Альфа-Банк. Фашизм априори не гибок…

В своей статье "Как написать хороший SLA", я поминал, что в SLA просто просится внести процедуру эскалации. Хочу сказать пару слов за эскалацию.

Эскалацию в IT, по-моему, мало кто понимает. В ITIL она как-то мутно определена. Соответственно и дальше, при попытках её внедрить, градус мутности только возрастает. Ни Гугл, ни Яндекс не помогают найти ничего вразумительного. Вместо того, чтобы объяснить эскалацию просто и понятно (как это сделаю я), авторы начинают вводить какие-то новые термины, указывать в чём различие между функциональной и иерархческой эскалацией (зачем вообще это?), вещать что-то про автоматическую эскалацию, ничего не объясняя и уводя в сторону. И при этом из контекста можно предположить, что эскалация — это то ли синоним передачи запроса другому исполнителю, то ли в другое подразделение, то ли привлечение дополнительных ресурсов, то ли повышение приоритета. А иногда я просто теряюсь понять смысл. Всё это вызывает лично у меня ощущение или "кручу-верчу, обмануть хочу", или банальной некомпетенции.

Особенно мило (не могу удержаться и не привести этот пример) выглядит автоматическая "эскалация" запроса на другой уровень поддержки, если (sic!) текущий исполнитель не успевает в заданный в SLA срок. То есть будучи исполнителем, принимаем запрос и держимся изо всех сил, ничего по нему не делаем, пока он не будет вот-вот уже почти просроченным, и… бац! — срабатывает автоматическая "эскалация", которая переназначает запрос на кого-то другого. Профит!.. Главное держать себя в руках и ничего не делать. Можно было бы от души посмеяться, но кое-где именно такую схему "эскалаций" и применяют, выдавая за лучшие практики IT!

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

Прослушав вебинар «How Google Tests Software» я был так вдохновлен, что решил записать некоторые тезисы. Эта статья и есть мой конспект. Прежде всего, я должен внести ясность относительно ее содержания. Это не дословный перевод. Здесь описаны только те вещи, которые показались мне важными. Проще говоря, здесь описано не все, что прозвучало в вебинаре. Так же существует вероятность, что я понял что-то не до конца или даже понял неправильно. Поэтому горячо рекомендую прослушать вебинар самостоятельно.
Его ведет Джэймс Витакер, который в данный момент занимает пост технического директора по тестированию ПО в Google. Джэймс совместно с коллегами готовится выпустить одноименную книгу. В ней можно будет получить исчерпывающую информацию о том, как проводят тестирование GoogleMaps, Google+, ChromeOS, Android и т.д…

Источник фотографии

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

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

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

Мы проанализируем решения для каждой конкретной ситуации, а также сравним их скорость и потребление ресурсов. Разобрав ситуацию с централизованной БД, мы воспользуемся Citus, чтобы продемонстрировать параллельное выполнение count в распределенной базе данных.

‘Login’ или ‘log in’? Одно слово или два? Это достаточно распространенный вопрос среди тех, кто пишет на английском языке. Давайте разберемся, как же правильно.

Привет, Хабр! В связи со своей реальной задачей проанализировать возможности Qt и .NET для реализации так называемых «Назад» (Undo) и «Вперёд» (Redo), цель которых отменить действие и отменить отмену соответственно, я решил все свои мысли, идеи и задумки развернуть в этой статье, даже если они будут частично или совсем неверными (поэтому по возможности и интересу пишите в комментарии свои замечания). Хоть и на просторах Интернета спокойно можно найти хорошие (и не очень) библиотеки и примеры реализаций, более общего представления на эти вещи я нашёл не так скоро, да и то, только в ответе на StackOverflow, а этого было мне не достаточно. Во всём найденном есть моменты, которые меня порадовали, есть и которые огорчили. Пожалуй, стоит отменить все печали и радости… чтобы к ним снова вернуться… «Назад… в будущее»!


Интересно? Добро пожаловать!

Инфографика TeleGeography

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

Крупнейшие хабы

На физическом уровне интернет представляет сеть хабов (точек обмена трафиком), связанных магистральными каналами. В точках обмена трафиком концентрируется не только трафик, но и сетевая инфраструктура (дата-центры, хостинг и т.д). Крупнейшие точки обмена находятся во Франкфурте, Амстердаме, Лондоне и Париже. В каком-то смысле эти города можно считать столицами мирового интернета. По крайней мере, точно крупнейшими сетевыми узлами, вместе с Нью-Йорком, который тоже входит в пятёрку основных хабов.

В списке крупнейших точек обмена трафиком в мире лидируют DE-CIX (пиковая пропускная способность 5178 Гбит/с), AMS-IX (4270 Гбит/с). Российская MSK-IX находится на 5-м месте (2135 Гбит/с).

Раньше, когда надо было распределить нагрузку на несколько серверов, мы прописывали несколько A-записей с одним именем в DNS-зоне, и все работало. Запросы клиентов распределялись примерно поровну. Особенно актуален такой способ балансировки был для раздачи статитического контента.

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

Если взглянуть на эволюцию компьютерных интерфейсов, наблюдаются 3 конкретные вехи: командная строка, десктоп с мышкой и «трогательные» интерфейсы. С анонсом Siri и прочих голосовых ассистентвов породилось мнение, что появилась новая веха в этой истории. Я же убежден, что Siri и аналоги пока это только проба пера.

На сегодняшний день голосовой интерфейс сильно ограничен в возможностях. Новой же революцией в UX, как в свое время стали тач устройства, являются боты и conversation UX (о котором сейчас так много пишут на западе). Это не просто тренд или банальная альтернатива для решения существующих задач. Это новый способ взаимодействия с интерфейсом, расширяющий горизонты.

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

Добрый день!

Меня зовут Евгений, я руководитель тестирования облачных решений Acronis, и я хочу рассказать вам о том, как у нас всё это устроено.

Вообще, QA — это почти как КГБ: нас не всегда видно, но мы есть везде. Мы участвуем в процессах, начиная с самых ранних этапов, когда ещё идёт обсуждение техтребований, их доработка, черновое прототипирование фич. QA не имеет права голоса, но обязательно объясняет девлиду и программ-менеджеру багоопасные места на основе своего опыта. И, как правило, это объяснение влияет на требования к фиче.

Эта статья – о рисках смены руководства в больших компаниях и характерных явлениях при попытках игнорировать закон эффективного управления собственностью:

Эффективно управлять можно только той собственностью, которую мог бы создать сам.
Кто не может создать, – будет только разрушать!
И.А. Дедюхова, Кодекс Хамурапи

Картинка для привлечения внимания читателей из поколений Y и Z:

Краткое содержание

Новый директор себе в подчиненные и советники пригласит своих «проверенных людей». Увеличение штата топ-менеджеров в условиях фиксированного ФОТ повлечет за собой сокращение рядовых сотрудников на значительный процент.
Новый директор в первую очередь будет сокращать те подразделения, работу которых он не понимает. Под прессом психологического давления руководители этих подразделений возмут на себя обязательства самостоятельно разработать планы по сокращению и принять на себя все риски их реализации.
Сокращения пройдут под флагом повышения эффективности, но для «непонятных директору» подразделений не смогут сформулировать критерии этой эффективности, кроме «минимизации затрат». Цель по минимизации затрат без дополнительных обоснованных ограничений – это цель по уничтожению, и не имеет отношения к настоящей оптимизации.
Отсекая непонятные ему части компании (выводя в аутсорс и т.п.), директор попытается превратить компанию в ту, работу которой он полностью способен понять, которой он в полной мере способен управлять.
Проблему нехватки знаний в технической области новый директор и его команда компенсируют «помощью» от западных консалтинговых компаний. Это приведет к ситуации внешнего управления, причем без всякой ответственности за диктуемые извне решения.
Внешняя и внутренняя отчетность о работе компании до самого конца не будет показывать никаких признаков проблем, т.к. тому, кто принес плохие вести не выдают премию, а рубят голову.

---

Я уже довольно долгое время хочу формализовать все свои мысли, опыт, ежедневно применяемый на практике, и многое другое в одном месте и предоставить их общественности. Уверен, многим этот материал будет полезен. Он посвящен различным моментам в конфигурации серверного ПО Linux и безопасным подходам к созданию сайтов/приложений на php (все же это до сих пор одна из самых популярных связок, хоть её успешно и подвигают другие технологии. Но советы так же легко применимы и к веб-ресурсам на других технологиях).

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