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

В продолжение статьи о теории и практике миграции хранилищ данных на PostgreSQL, мы поговорим о проблемах, с которыми вы можете столкнуться при переезде с распространенной СУБД MySQL. Дабы не утомлять всех лишней риторикой, сегодняшний рассказ будет более тезисный и проблемно-ориентированный.

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

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

Перейдем к делу.

Привет, Хабр! Эта публикация — попытка развеять некоторые популярные мифы и легенды о MySQL. Я не ошибся с хабом, так как поводом для написания послужила публикация varanio Возможности PostgreSQL, которых нет в MySQL, и наоборот отсюда же. Сама публикация в части критики MySQL хоть и неидеальна, но вполне корректна, а вот комментарии к ней наводят на грустные размышления.

Вообще говоря, я собирался написать публикацию о возможностях MySQL, которые не реализованы или реализованы в PostgreSQL хуже. Но для того, чтобы не мешать много тем в одну публикацию, и учитывая довольно нелёгкую работу по сравнению того, что я знаю очень хорошо (MySQL) с тем, что я знаю очень плохо (PostgreSQL), такую публикацию я решил отложить на потом и для начала ответить сразу на многие комментарии из публикации varanio.

После значительной задержки публикую продолжение цикла своих статей.
Для ознакомления:

• Steam Protocol 2 и Steam Files — Введение
• Steam Files. Часть 1 — GCF/NCF

В данной статье я затрону оставшиеся форматы файлов:

• BLOB — устаревший формат данных, служащий контейнером для двоичных данных. Содержал в себе базовые параметры (IP-адреса серверов, CRD-запись и еще много чего);
• CDR (Content Description Record) — бинарный файл, содержащий данные о приложениях и их файлах кеша. На данный момент не используется;
• VDF — бинарный/текстовый файл, содержащий множество данных и имеющий структуру, зависящую от конкретного применения. Разработан как замена BLOB и CDR;
• PAK — ранее использовался в Half-Life 1, великое наследие Quake 1, уже не используется;
• VPK — новый формат игровых архивов внутри самих игр, активно используется на данный момент. Подробное описание файла имеется на официальном ресурсе. В статье описана только первая версия формата.

Статья представлена только для ознакомления, поскольку актуальной информации здесь относительно мало, а примеров алгоритмов почти нет — всё можно просмотреть в упомянутом ранее репозитории.

Увеличение числа пользователей Интернета в развивающихся странах влечёт за собой необходимость развития соответствующей инфраструктуры, в том числе и DNS-серверов.

За последнее несколько лет география корневых серверов DNS была существенно расширена. Ещё совсем недавно рабочие узлы корневых серверов были в основном сконцентрированы в Европе и США, то сегодня они появляются в странах Азии, Африки, Южной Америки. В этом году один из узлов сервера K-Root был установлен даже в Иране, с которого до сих пор не сняты до конца западные санкции.

Вопрос расширения корневой системы DNS актуален и для России. Определённый вклад в его решение удалось внести и нам: в августе этого года у нас был размещён один из узлов корневого DNS-сервера K-Root. В этой статье мы расскажем о его архитектуре и об участии в конкурса на его размещение.

Я с удивлением обнаружил, что многие разработчики, даже давно использующие postgresql, не понимают оконные функции, считая их какой-то особой магией для избранных. Ну или в лучшем случае «копипастят» со StackOverflow выражения типа «row_number() OVER ()», не вдаваясь в детали. А ведь оконные функции — полезнейший функционал PostgreSQL.
Попробую по-простому объяснить, как можно их использовать.

Ты просто-напросто ненавидишь Git? Ты абсолютно счастлив с Mercurial (или, фу, с Subversion), но раз в месяц тебе приходится отважно сталкиваться с Git, потому что каждый, даже его чертова собака, теперь использует GitHub? Тебя терзают смутные подозрения, что половина всех команд Git на самом деле удалят всю твою работу навсегда, но ты не знаешь какие именно и не хочешь проводить три недели, углубляясь в документацию?

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

Я постараюсь излагать коротко, но также, чтобы это было потенциально полезно тем людям, кто вообще никогда не сталкивался с контролем версий, поэтому повсюду будет разбросан 101 совет. Не бойся! Я не думаю, что пользователи Mercurial понятия не имеют, что такое патч.

Знакомимся с RabbitMQ

Переводы на хабре:
RabbitMQ tutorial 1 — Hello World
RabbitMQ tutorial 2 — Очередь задач
RabbitMQ tutorial 3 — Публикация/Подписка

Сразу дополню некоторые недочеты. И кратко повторю основные термины.

Принцип работы архитектуры использующей rabbitMq

Довольно много времени прошло после моей последней статьи про nginx под windows, неделя nginx закончилась. Стоит поправить это упущение.

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

После небольшого разбора и оценки в сравнении с результатами предыдущего анализа, заметил одну странность — абсолютная скорость отдачи nginx упала в среднем от 5 до 15%.

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

Покрутив логи и так и сяк, зацепился за отдачу маленькой статики — выяснилась одна закономерность: чем длиннее путь (url) — тем «медлительней» становился nginx (независимо от размера файла).

Итак после нескольких экспериментов, имеем следующие факты:

• скорость отдачи падает прямо пропорционально увеличению длины пути до файла
• скорость практически не зависит от длинны URL, т.е. если URL короткий, но увеличиваем длину root/alias, скорость отдачи падает также, т.е. это все-таки длинна пути, а не URL
• ну и наконец, поиграв с путями файла, а именно его вложенности, выяснилось, что скорость отдачи падает в зависимости от количества поддиректорий, и не зависит от длины как-таковой. Т.е. файл «D:\...\ms-ms-ms-ms-ms-ms-ms-ms\test.gif» отдается много быстрее «D:\...\ms\ms\ms\ms\ms\ms\ms\ms\test.gif»

И тут пришло озарение — я вспомнил, что в этом проекте изменилась файловая структура, и вложенность до некоторой статики и динамики, отдаваемой файлом (по redirect), увеличилась на два-три, а местами до пяти каталогов.

Что здесь интересного:

Обзорная статья о Consul (http://consul.io) — системе для поддержания обнаружения сервисов и распределенного хранилища ключ-значение. Кроме самого Consul, рассмотрим Consul-Template — средство для управления конфигурациями сервисов автоматически отражающее изменения в топологии. Статья будет интересна DevOps инженерам, системным архитекторам, тим-лидам проектов и прочим интересующимся микросервисными архитектурами.

Примечания tsafin:

Перед публикацией своего цикла статей по MapReduce в Caché, мне показалось важным озвучить данную прошлогоднюю точку зрения из статьи Адама Дрейка «Command-line tools can be 235x faster than your Hadoop cluster». К сожалению оригинальная статья Тома Хайдена, на которую он ссылается стала уже недоступна на сайте Тома, но её, по-прежнему, можно найти в архивах. Для полноты картины предлагаю ознакомиться и с ней тоже.

Введение

Посещая в очередной раз свои любимые сайты, я нашел крутую статью Тома Хайдена об использовании Amazon Elastic Map Reduce (EMR) и mrjob для вычисления статистики отношения выигрыш/проигрыш в наборе данных со статистикой по шахматным матчам, которую он скачал с сайта millionbase archive, и c которой он начал играться используя EMR. Так как объем данных был всего 1.75GB, описывающий 2 миллиона шахматных партий, то я скептически отнесся к использованию Hadoop для данной задачи, хотя были и понятны его намерения просто поиграться и изучить плотнее, на реальном примере, утилиту mrjob и инфраструктуру EMR.

Управление памятью – одна из главных задач ОС. Она критична как для программирования, так и для системного администрирования. Я постараюсь объяснить, как ОС работает с памятью. Концепции будут общего характера, а примеры я возьму из Linux и Windows на 32-bit x86. Сначала я опишу, как программы располагаются в памяти.

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



Это не значит, что ядро использует так много физической памяти – просто у него в распоряжении находится часть адресного пространства, которое можно поставить в соответствие необходимому количеству физической памяти. Пространство памяти для ядра отмечено в таблицах страниц как эксклюзивно используемое привилегированным кодом, поэтому если какая-то программа пытается получить в него доступ, случается page fault. В Linux пространство памяти для ядра присутствует постоянно, и ставит в соответствие одну и ту же часть физической памяти у всех процессов. Код ядра и данные всегда имеют адреса, и готовы обрабатывать прерывания и системные вызовы в любой момент. Для пользовательских программ, напротив, соответствие виртуальных адресов реальной памяти меняется, когда происходит переключение процессов:

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

Мы пришли к выводу, что нужно предложить арендодателям удобный автоматизированный сервис, помогающий принять решение при назначении стоимости аренды. Разработка началась в 2012 году, и мы до сих пор его периодически дорабатываем. Этим летом мы внедрили динамическое ценообразование: ориентировочные цены пересчитываются ежедневно, исходя из текущей рыночной ситуации. Мы настроили алгоритм так, чтобы он учитывал наличие необычных, даже удивительных свойств выставляемого жилья. Также мы внедрили, уникальный, как мы считаем, механизм машинного обучения, позволяющий системе не только обучаться на своём опыте, но и, при необходимости, использовать небольшую толику «человеческой» интуиции.

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

Гуглил информацию по Ansible, наткнулся на статью на Хабре. Прочитал и сильно удивился: ведь можно сделать красивее! Если вы заинтересованы — добро пожаловать под кат!

Мы в HOSTKEY регулярно сталкиваемся с необходимостью организации VLAN на скорости 10Гбит для кластеров виртуализации – своих и клиентских. Эта технология необходима для взаимодействия с СХД, для резервного копирования, для доступа у БД и для обеспечения живой миграции виртуальных машин. Всегда возникает вопрос — как сделать это надежно и с минимальными затратами?

До последнего времени минимальные затраты для такого решения были существенными. Самый маленький коммутатор 10GbE был на 24 порта, а самая простая карта – Intel X520 за 500 долларов. Бюджет на порт составлял около 700-1000 долларов, а входной билет был очень высокий.

Прогресс не стоит на месте, в начале 2015 года появился новый класс устройств 10GbE за приемлемые деньги со склада в Москве и под гарантией.
Так как мы в HOSTKEY регулярно строим на их базе выделенные сервера и частные облака, то хотим поделиться опытом.

Итак, у нашего Клиента 5 машин в кластере и ему нужен 10GbE VLAN – там 2 файлера, одна машина для резервного копирования и несколько нод. На гигабите все медленно и не хочется ставить в машины гигабитные четырехпортовки в тиминге. Надо 10GbE и бюджет ограничен. Звучит знакомо, не правда ли?

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

В деле удалённого вызова процедур дела уже давно обстоят в точности как в известном комиксе «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 важных шагов, без которых ничего не собирается), а также попробуем написать простенький сервис и клиент, обменивающиеся запросами и ответами.

Для курса по программированию MIT разработан интерактивный инструмент Online Python Tutor, он в графическом виде показывает изменение стека и кучи на каждом шаге выполнения кода. Таким образом, онлайновый «наставник» как бы наглядно объясняет студенту работу программы.



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

Вчера, 25 августа, произошло важное для большого числа программистов событие: компания Intel выпустила новую версию программного комплекса Intel Parallel Studio XE — 2016, включающего в себя компиляторы Intel, библиотеки для повышения производительности, средства анализа и отладки программ, а также библиотеку Intel MPI и MPI инструментарий. Но это еще не вся радость. В новой «студии» к имевшей и ранее бесплатную версию библиотеке Intel Threading Building Blocks добавилось целых три продукта с community (то есть бесплатной) лицензией: новая библиотека Intel Data Acceleration Library, о которой мы только что писали, а также два очень полезных компонента: Intel Math Kernel Library и Intel Integrated Performance Primitives. Используйте на здоровье, какие-либо ограничения у бесплатных версий отсутствуют.
Community лицензиям для продуктов Intel посвящен отдельный сайт — там вы найдете подробности программы.