Этот материал будет полезен в первую очередь тем, кто много занимался программированием и вдруг внезапно стал вынужден заниматься управлением проектами и людьми. С год назад я рассказал про наказания на конференции, а солнышки из Битрикса сделали текстовую версию для #habr. К сожалению, потеряв в точности, четкости и правильности акцентов. За год материала добавилось. В конце — чеклист для ленивых :)

Итак. Если вы не садист или моральный урод, а ваши сотрудники — не мазохисты, то сомневаюсь, что кому-то из вас наказания доставляют удовольствие. Мне — нет.

Давным-давно перестал работать 1stat.ru — откровенно говоря, для нас это была трагедия (сейчас вроде он как-то работает).

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

• «Облачный» дайджест #1

• «Облачный» дайджест #2

• «Облачный» дайджест #3

В Бегете мы долго и успешно занимаемся виртуальным хостингом, используем много OpenSource-решений, и теперь настало время поделиться с сообществом нашей разработкой: файловым менеджером Sprut.IO, который мы разрабатывали для наших пользователей и который используется у нас в панели управления. Приглашаем всех желающих присоединиться к его разработке. О том, как он разрабатывался и почему нас не устроили существующие аналоги, какие костыли технологии мы использовали и кому он может пригодиться, расскажем в этой статье.

Сайт проекта:https://sprut.io
Демо доступно по ссылке: https://demo.sprut.io:9443
Исходный код: https://github.com/LTD-Beget/sprutio

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

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

Картинка Для Привлечения Внимания и выравнивание по левому краю

Так уж сложилось, что вся лента Хабрахабра выровнена по левому краю. По этой причине опытные авторы небольшие изображения оставляют слева или используют картинки шириной в 800-1000 px. Отдельно хочется заметить, что чуть ли не лучшим является соотношение КДПВ 2 к 1, т.е. изображения 800х400 px. Подобная пропорция позволяет SMM-щику соц. сетей не изгаляться с вашей картинкой (а то и вовсе искать что-то другое, более подходящее по размерам), а использовать оригинал, не нарушая задумки автора.

В продолжение серии публикаций «Памятка евангелиста PostgreSQL...» (1, 2) дорогая редакция снова выходит на связь, на этот раз с обещанным обзором механизмов репликации в PostgreSQL и MySQL. Главным поводом для написания послужила частая критика репликации MySQL. Как это часто бывает, типичная критика представляет из себя забористую смесь из правды, полуправды и евангелизма. Всё это многократно реплицируется разными людьми без особых попыток разобраться в услышанном. А поскольку это довольно обширная тема, я решил вынести разбор в отдельную публикацию.

Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабировании в product-группах. Список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу первой книги.

Архитектурные ошибки

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

Сразу скажу, что делал это не первый раз, до этого успешно делал партицирование у сайта на битрикс примерно вот таким образом:

Шаг 1. Убираем AUTO INCREMENT из таблицы b_iblock_element.

ALTER TABLE b_iblock_element MODIFY ID INT(11) NOT NULL

Шаг 2. Удаляем PRIMARY key из таблицы.

ALTER TABLE b_iblock_element DROP PRIMARY KEY

Шаг 3. Создаем новый PRIMARY KEY, который будет содержать прошлый ключ и IBLOCK_ID, по которому идет разбиение на partition`ы.

ALTER TABLE b_iblock_element ADD CONSTRAINT id_iblock_id PRIMARY KEY (ID,IBLOCK_ID)

Шаг 4. Возвращаем AUTO INCREMENT.

ALTER TABLE b_iblock_element MODIFY ID INT(11) NOT NULL AUTO_INCREMENT

Шаг 5. Наконец то делаем разбиением на 10 частей.

ALTER TABLE b_iblock_element PARTITION BY HASH(IBLOCK_ID) PARTITIONS 10;

Все довольно просто. Функция по которой идет разбиение может содержать ключи, но все эти ключи должны быть в PRIMARY KEY.

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

Тимлид (aka ведущий разработчик, team leader) — один из таких «специалистов», обязанности которого многие видят по-разному. Думаю, что складываются различные представления примерно так: поработал кто-то в команде под руководством тимлида, который хорошо справлялся с задачами проектирования системы, и считает теперь, что это именно то, что должен делать тимлид; в другой же команде тимлид плохо справлялся с планированием спринтов, а с другими обязанностями более или менее, и стали считать сотрудники, что планирование — не то, чем должен заниматься тимлид.

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

Введение

Страницы сайтов становятся всё больше по размеру, и встаёт вопрос асинхронной загрузки контента на них. Но если для изображений существует библиотека для их простой загрузки после загрузки основной страницы, то с асинхронной загрузкой HTML частей страницы (блоков), всё намного сложней. Например: для реализации асинхронной загрузки блоков в Drupal без потери производительности сайта необходимо понимать, как работает кэширование, как его использовать и как оптимизировать. А уже после реализовать по намеченному плану «Lazy Loading» загрузку блоков сайта.

Разработчик программного обеспечения Ришат Мухаметшин живет в Ижевске. Мы познакомились несколько лет назад на проекте по разработке сервиса обмена заказами такси, в котором он выступал руководителем со стороны заказчика. Ришат интересовался здоровым образом жизни. Сначала он завел блог на эту тему, потом решил написать книгу и даже женился на инструкторе по фитнесу! Мы решили дать ему микрофон на страницах нашего блога в эти выходные, когда рабочая неделя уже закончена, и можно поговорить о чём-то, что касается всех занятых сидячим трудом в офисе. Итак, слово Ришату.

Нода кластера: сервер отечественного производства Etegro (2 AMD Opteron 6320, 16 GB RAM, 4 HDD)

Системы хранения данных, используемые сейчас на практике в России, условно делятся на три категории:

• Очень дорогие high-end СХД;
• Мидрейнжевые массивы (тиринг, HDD, гибридные решения);
• И экономичные кластеры на базе SSD-массивов и HDD-массивов из «бытовых» дисков, часто собранные своими руками.

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

И вот на этот рынок пришла EMC, известная своими чертовски дорогими и надёжными железками с софтом, который позволяет без проблем поднять и VMware-ферму, и виртуальную СХД, и всякий приклад на одних и тех же х86 серверах. И ещё началась история с серверов русского производства.

В конце 2008 года на тогда ещё небольшую петербуржскую компанию вышел один западный медиахолдинг примерно так:
— Это вы там упоролись по хардкору и приспособили SSE-инструкции для реализации кода Рида-Соломона?
— Да, только мы не…
— Да мне пофиг. Хотите заказ?

Проблема была в том, что видеомонтаж требовал адовой производительности, и тогда использовались RAID-5 массивы. Чем больше дисков в RAID-5 — тем выше была вероятность отказа прямо во время монтажа (для 12 дисков — 6%, а для 36 дисков — уже 17-18%). Дроп диска при монтаже недопустим: даже если диск падает в хайэндовой СХД, скорость резко деградирует. Медиахолдигу надоело с криком биться головой о стену каждый раз, и поэтому кто-то посоветовал им сумрачного русского гения.

Много позже, когда наши соотечественники подросли, возникла вторая интересная задача — Silent Data Corruption. Это такой тип ошибок хранения, когда на блине одновременно меняется и бит в основных данных, и контрольный бит. Если речь о видео или фотографии — в целом, никто даже не заметит. А если речь про медицинские данные, то это становится диагностической проблемой. Так появился специальный продукт под этот рынок.

Ниже — история того, что они делали, немного математики и результат — ОС для highload-СХД. Серьёзно, первая русская ОС, доведённая до ума и выпущенная. Хоть и для СХД.

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

Напомню, что это сверхбыстрое решение, гарантирующее отказоустойчивость и обеспечивающее балансировку и проксирование TCP и HTTP запросов.


Любезно прошу о всех найденных неточностях и ошибках писать в ЛС — оперативно исправлю.

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

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

Так какими же недостатками обладает наше приложение?

• Отсылается один единственный пакет, длина которого не может превышать заранее заданной границы в 1 Кбайт.
• Приложение без проверки передаёт аргумент, принятый из сети, в оболочку (URL).
• Недостаток функциональности. Мы не можем, например, скачать все изображения с Хабра, или скачать отдельный хаб.

Сегодня я расскажу как решить первую проблему, а заодно и немного о TCP.

Описание протокола

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

Так как заранее узнать длину сообщения у нас не получиться, придётся передавать её в одном из пакетов. Разумеется, делать это лучше в самом начале первого пакета. Выделив под хранение длины сообщения всего 4 байта, мы сможем передать сообщение длиной свыше 4 млрд символов! Длина сообщения — это информация о нём, то есть, часть заголовка, заголовка нашего протокола. Какого протокола спросите вы? Если верить Википедии, то

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

Мы договорились, что будем передавать данные в нескольких пакетах по TCP, а в начале данных первого пакета будет храниться длина всего сообщения в байтах. Таким образом мы разработали наш простой протокол! Нужно помнить, что наш протокол основан на TCP, а значит, обладает теми же особенностями, что и последний.

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

Сейчас в распоряжении Amazon Web Services — минимум 30 дата-центров, причем руководство планирует построить дополнительно 10 или 15 новых. Большинство дата-центров размещаются в северной Вирджинии, здесь за работу AWS отвечает примерно 20 дата-центров, общей мощностью примерно в 500 МВт. Но география инфраструктуры дата-центров AWS не ограничена только лишь Вирджинией. Сейчас три крупных кампуса ДЦ строится в Огайо, плюс облачные дата-центры работают еще в Ирландии, Бразилии, Китае, Японии, Австралии и Сингапуре.

Cколько времени я использую GitFlow и Semantic Versioning, меня все не покидает чувство, что чего-то в них не хватает. Обе концепции хороши, но так как они предлагают решения для проблем из разных областей, их совместное использование выглядит сложнее, чем должно быть.

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

Сегодня поговорим об интеграции Asterisk'a с CRM системой. Со стороны CRM вопрос рассматривать не будем, достаточно знать, что CRM хочет знать о всех звонках (как входящих, исходящих, так и переведенных)

Что мы хотим получить:

Для каждого звонка должны отправляться в CRM 2 события: start и stop. Естественно с кучей аргументов.

Предлагаем вашему вниманию очередную подборку со ссылками на новости и материалы.

Приятного чтения!

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

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