map — мощная директива, которая может сделать ваши конфиги простыми и понятными.
Возможно, это самая недооцененная директива, из за того, что не все знают всех её возможностей.
Она в компактной форме помогает обрабатывать переменные, GET параметры, заголовки, куки и наборы бекендов (upstream).
Попробую раскрыть её возможности хабрапользователям.

Здравствуй Хабр!

Периодически возникает необходимость отследить запросы, которые отправляет Ваше приложение к базе данных. К примеру:
— Вам нужно отладить/доработать чужой код;
— Запросы генерируются с помощью сторонней библиотеки (к примеру ActiveRecord), не понятно, какие именно и сколько их;
— Нужно оптимизировать приложение: посмотреть какие запросы и сколько их, посмотреть explain этих запросов.

В этих ситуациях на помощь приходит Beaver mysql logger.

Высокая распространенность баз данных MySQL приводит к её использованию в разнообразных проектах, в том числе, которые требуют безостановочной работы и минимального времени восстановления. Стандартные инструменты, такие как mysqldump неудобен для использования баз данных размер, которых измеряется десятками гигабайт. К сожалению mysqldump вызывает блокировку таблиц, и операция снятия дампа или восстановления базы может занимать далеко не один час, а порой и 5-10 часов.

Благо, к нам на помощь приходит Percona XtraBackup.

Наконец то мы дождались нового релиза Centos сделанного на пакетной базе RHEL 7. Выпуск произошел очень быстро в связи с тем, Redhat купила проект Centos и наняла некоторых мантейнеров дистрибутива на полный рабочий день, теперь обещают задержку максимум в два дня после появления обновлений в RHEL. Ранее мы помним задержки с релизами на полгода, которые вызывали жуткое негодование у поклонников этого серверного дистрибутива.

Из интересного стоит отметить

Чуть больше года назад я опубликовал сравнение российских облачных операторов: статья многим понравилась и была полезна. Примерно через полгода я начал получать много отзывов и просьб о том, что неплохо было бы сделать новый обзор, актуализировав данные по ценам, добавив в запрос дополнительные сервисы и дополнив его новыми компаниями. В этот раз в сравнение вошли уже 34 компании (в прошлом году их было более, чем в 2 раза меньше), включая зарубежные сервисы Amazon и Rackspace, а сбор информации занял более двух месяцев.



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

Это продолжение серии статей о веб-фреймворке для Perl — Mojolicious: первая часть.

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

Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay

Mojo::IOLoop::Delay предоставляет механизм, обеспечивающий для асинхронно выполняющихся callback-ов:

• описание последовательно выполняющихся операций без «лапши» callback-ов
• передачу результатов из callback-а(ов) текущего шага на следующий
• общие данные для callback-ов, объединённых в одну задачу
• синхронизацию групп callback-ов
• перехват и обработку исключений в callback-ах

Используемые термины:

• (асинхронная) операция — обычно это вызов асинхронной функции вроде  таймера или выкачивания url, которой необходимо передать callback
• шаг — callback, который анализирует данные полученные с предыдущего  шага (если это не первый шаг), и запускает одну или несколько новых  операций, либо возвращает финальный результат (если это последний шаг)
• задача — список шагов, которые должны выполняться последовательно  (т.е. следующий шаг вызывается только после того, как все операции  запущенные на предыдущем шаге завершаются)

Альтернатива Promises

Это альтернативный подход к проблеме, обычно решаемой с помощью Promise/Deferred или Future. Вот приблизительное сравнение со спецификацией Promises/A+: 

Maximum transmission unit (MTU) это максимальный объём данных, который может быть передан протоколом за одну итерацию. К примеру, Ethernet MTU равняется 1500, что означает, что максимальный объём данных, переносимый Ethernet фреймом не может превышать 1500 байт (без учёта Ethernet заголовка и FCS — Рис. 1).


Рис. 1

Давайте пробежимся с MTU по уровням OSI:

Апофеоз сотни холиваров и улучшения работы QA — чек-лист по юзабилити интернет-магазинов. В нем частично задействованы прошлые документы — чек-листы по формам и фильтрам. Пользуйтесь.

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

Публичный API — не воробей, опубликуешь — не уберешь. Есть только одна попытка сделать все правильно, поэтому постарайся.

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

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

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.

Практически каждый разработчик, создающий информационные системы, сталкивается с необходимостью формирования различных отчетов и печатных форм. Это характерно и для большинства приложений разработанных на нашей платформе. Например, в системе, над которой я работаю в настоящее время, их 264. Для того чтобы не писать каждый раз логику формирования отчетов с нуля, мы разработали специальную библиотеку (под катом будет объяснено, почему нам не подошли существующие). Называется она YARG — Yet Another Report Generator.
YARG позволяет:

• Генерировать отчет в формате шаблона или конвертировать результат в PDF;
• Создавать шаблоны отчетов в привычных и распространенных форматах: DOC, ODT, XLS, DOCX,XLSX, HTML;
• Создавать сложные XLS и XLSX шаблоны: с вложенными областями данных, графиками, формулами и т.д.;
• Использовать в отчетах изображения и HTML-разметку;
• Хранить структуру отчетов в формате XML;
• Запускать standalone приложение для генерации отчетов, что делает возможным использование библиотеки вне Java-экосистемы (например для генерации отчетов в PHP);
• Интегрироваться с IoC-фреймворками (Spring, Guice).

Эта библиотека используется в платформе CUBA в качестве основы для движка отчетов. Мы развиваем ее с 2010 года, но совсем недавно решили сделать ее открытой, и выложили ее код на GitHub с лицензией Apache 2.0.
Данная статья призвана привлечь к ней внимание сообщества.

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

Сайт Noisli содержит коллекцию фоновых шумов на любой вкус и возможность смешивать их в произвольной пропорции. Здесь есть и звуки природы — шум дождя, плеск воды, пение птиц, шуршание листьев, и звуки техногенного характера — стук колёс поезда, звук работающего вентилятора, и звуки многолюдного кафе. Есть и искусственные белый, розовый и коричневый шум. Коллекция звуков постоянно пополняется.

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

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

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

Некоторое время назад мне пришлось дорабатывать клиент-сайд ресурса, включающего просто невероятное количество анкетных форм. Одной из неприятных особенностей этих форм было жуткое количество разнотипных правил валидации ввода и ещё большее количество взаимосвязей между полями.
Пример: если выбран чекбокс А, то в поле Х можно ввести только цифры, а поле Y должно быть скрыто, но если дополнительно выбрана радиокнопка Z, то поле Y нужно показать, а в поле X можно ввести всё, кроме цифр.
Иными словами — сущий ад, рождённый нездоровым сознанием маркетологов.

jQuery-плагин, который превращает вложенное (древовидное) меню в систему прокручивающихся меню.

Репозиторий: github.com/webasyst/waslidemenu
Попробовать: jsfiddle.net/7LnSY/
Пример: demo-ru.webasyst.com

В данной статье речь пойдёт о высокоуровневом взгляде на компоновку. Где ищутся разделяемые библиотеки на Linux, BSD*, Mac OS X, Windows, от которых зависят приложения? Что делать с обратной совместимостью? Как бороться с адом зависимостей?

Abstract: Изоляция приложения на уровне сети использованием network namespaces Линукса. Организация SSH-туннелей.

Традиционно, большая часть статьи будет посвящена теории, а скучные скрипты — в конце статьи. В качестве субъекта для экспериментов будет использоваться Steam, хотя написанное применимо к любому приложению, включая веб-браузеры.

Вместо вступления. Я просто покажу эту картинку:

147%… Что-то мне это напоминает. Впрочем, хабр не для политики.

Цена на игры в Стиме зависит от региона. Регион — от IP'шника. Есть желание иметь цены в рублях, а не в евро.

Для этого мы используем VPN через SSH с использованием tun-устройств, плюс network namespaces для изоляции приложения от всех остальных сетевых устройств.

Network namespaces

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

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

Если у нас есть несколько интерфейсов (один из которых относится к VPN), то нет штатных методов сказать стиму, что надо использовать его, а не eth0/wlan0. Точнее, мы можем «завернуть» весь трафик в VPN, но это не всегда желательно. Как минимум — рост latency и снижение скорости (даже если VPN ведёт на супербыстрый сервер, увеличение latency, оверхед от туннеля и фиксированная ширина локального канала ставят TCP в положение, когда приходится резать скорость). Как максимум — одно дело «покупать через русский VPN», другое дело — пускать туда весь трафик. Меня совсем не прельщает использование VPN для получения защиты роскомнадзором от оппозиции и вольнодумства.

В этих условиях возникает большое желание оставить один на один конкретное приложение и заданный сетевой интерфейс. Один. Сконфигурированный для нужд только этого приложения.

Для решения этой задачи в Linux, уже довольно давно (аж с 2007 года) существует технология, называемая network namespaces, то есть пространства имён для сетей. Суть технологии: над сетевыми интерфейсами создаётся подобие «каталогов», в каждом каталоге может быть несколько сетевых интерфейсов и приложений. Приложение, оказавшееся в заданном сетевом пространстве имён, может использовать (и видит) только те сетевые интерфейсы, которые отнесены к этому пространству.

Картинка ниже поясняет происходящее:

Уже довольно давно у веб-приложений появилась возможность хранить часть данных или файлов локально. Можно даже кешировать MP3-файлы. Браузеры научились хранить немалые объёмы данных. Тем не менее, пока что технологии локального хранения сильно фрагментированы.

localStorage предоставляет лишь самые базовые функции, это хранилище довольно медленно и не умеет хранить блобы. IndexedDB и WebSQL асинхронны, быстры и поддерживают большие объемы данных, но их API довольно запутан. Кроме того, ни IndexedDB, ни WebSQL не поддерживаются всеми основными браузерами, и, похоже, в ближайшем будущем эта ситуация не изменится.

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

Почувствовать на своей шкуре все сложности работы с локальным хранилищем мне помогла разработка around — HTML5-клиента для Foursquare. Хотя в этой статье я рассказываю, как использовать localForage, возможно кто-то предпочтёт изучить реальные примеры работы с ней.

localForage — очень простая библиотека JavaScript, которая использует API, похожий на API localStorage, с теми же самыми базовыми методами get, set, remove, clear и length, но имеет ещё несколько важных улучшений:

• асинхронный API с колбэками;
• драйвера IndexedDB, WebSQL и localStorage (самый подходящий драйвер выбирается автоматически в зависимости от возможностей браузера);
• поддержка блобов и произвольных форматов данных, так что можно хранить изображения, файлы и так далее;
• поддержка обещаний ECMAScript 6.

Использование IndexedDB и WebSQL позволяет хранить намного больше данных, чем localStorage. Неблокирующий асинхронный API делает приложение более быстрым и отзывчивым, так как основной поток приложения не подвисает во время выполнения вызовов get/set. Поддержка обещаний позволяет писать чистый код без спагетти из колбэков. Конечно, если вы любите колбэки, можно использовать и их.

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


Наш программист специально для читателей Хабра сделал калькулятор, можно побаловаться.

Это перевод статьи Analysis Paralysis: Over-thinking and Knowing Too Much to Just CODE Скотта Хансельмана за 30 марта.

Прочитал сегодня пост на ArsTechnica «Я знаю слишком много чтобы программировать быстро. Что мне делать?» — это обзор вот этого вопроса на StackOverflow:

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

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

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

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

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

Под катом попробуем разобраться чем отличаются «высокотехнологичные» компании от «низкотехнологичных», что нужно, чтобы высокотехнологичные компании могли рождаться и выживать, почему с софтом у нас лучше, чем с хардом, с чего начиналась кремниевая долина в США и можно ли её «скопировать», почему Китай всех рвет, а также — окинем взором все, что происходит в Сколково, Роснано, фонде перспективных исследований и приведут ли они к расцвету российских инноваций. Безусловно, я где-то могу ошибаться — буду рад дополнениям в комментариях.

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