В ИТ редко встретишь человека, который не слышал о микросервисах. В интернете и на профильных сайтах на эту тему есть масса статей, которые в целом хорошо объясняют отличия между монолитом и, собственно, микросервисами. Неискушенный разработчик Java, прочитав статьи из разряда «Что такое микросервисы для web-приложений и с чем их едят», преисполняется радости и уверенности, что вот теперь-то всё станет замечательно. Ведь главная цель — «попилить» монструозный монолит (конечный артефакт, который, как правило, представляет собой war/ear файл), выполняющий кучу всего, на ряд отдельно живущих сервисов, каждый из которых будет выполнять строго определённую, относящуюся только к нему функцию, и будет делать это хорошо. В дополнение к этому идёт горизонтальная масштабируемость — просто делай scaling соответствующих узлов, и всё будет здорово. Пришло больше пользователей или требуется больше мощностей — просто добавил 5–10 новых инстансов сервисов. Грубо говоря, в целом так это и работает, но, как известно, дьявол кроется в деталях, и то, что изначально казалось довольно простым, при более внимательном рассмотрении может обернуться проблемами, которые первоначально в расчёт никто не брал.

В этом посте своим опытом о том, как дебажить микросервисы для web делятся коллеги из практики Java компании «Рексофт».

Особенности работы внутренних механизмов PostgreSQL позволяют ему быть очень быстрым в одних ситуация и «не очень» в других. Сегодня остановимся на классическом примере конфликта между тем, как работает СУБД и тем, что делает с ней разработчик — UPDATE vs принципы MVCC.

Кратко сюжет из отличной статьи:

Когда строка изменяется командой UPDATE, фактически выполняются две операции: DELETE и INSERT. В текущей версии строки устанавливается xmax, равный номеру транзакции, выполнившей UPDATE. Затем создается новая версия той же строки; значение xmin у нее совпадает с значением xmax предыдущей версии.

Через какое-то время после завершения этой транзакции старая или новая версии, в зависимости от COMMIT/ROOLBACK, будут признаны «мертвыми» (dead tuples) при проходе VACUUM по таблице и зачищены.



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

Автор статьи, перевод которой мы публикуем сегодня, хочет рассказать о том, как упаковывать в контейнеры Docker веб-приложения, основанные на React, Express и MongoDB. Здесь будут рассмотрены особенности формирования структуры файлов и папок таких проектов, создание файлов Dockerfile и использование технологии Docker Compose.

В PostgreSQL нет High Availability из коробки. Чтобы добиться HA, нужно что-то поставить, настроить — приложить усилия. Есть несколько инструментов, которые помогут повысить доступность PostgreSQL, и один из них — Patroni.

На первый взгляд, поставив Patroni в тестовой среде, можно увидеть, какой это прекрасный инструмент и как он легко обрабатывает наши попытки развалить кластер. Но на практике в production-среде не всегда всё происходит так красиво и элегантно. Data Egret начали использовать Patroni еще в конце 2018 года и накопили определенный опыт: как его диагностировать, настраивать, а когда вовсе не полагаться на автофейловер.

На HighLoad++ Алексей Лесовский обстоятельно, на примерах и с разбором логов рассказал о типовых проблемах, возникающих при работе с Patroni, и best practice для их преодоления.


В статье не будет: инструкций по установке Patroni и примеров конфигураций; проблем за пределами Patroni и PostgreSQL; историй, основанных на чужом опыте, а только те проблемы, с которыми в Data Egret разобрались сами.

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

Часто жалуются, что count (*) в PostgreSQL очень медленный.

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

Почему count (*) такой медленный?

Большинство людей без проблем понимают, что следующий запрос будет выполняться медленно:

SELECT count(*)
FROM /* сложный запрос */;

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

Но многие люди потрясены, когда узнают, что следующий запрос медленный:

SELECT count(*) FROM large_table;

Тем не менее, если вы подумаете еще раз, все вышесказанное остается в силе: PostgreSQL должен вычислить результирующий набор, прежде чем сможет его посчитать. Поскольку в таблице не хранится «магический счетчик строк» (как в MyISAM MySQL), единственный способ подсчитать строки — это просмотреть их.

Поэтому count (*) обычно выполняет последовательное сканирование таблицы, что может быть довольно дорого.

Disclaimer: Данный пост написан мною как частным лицом. Этот пост является экспериментом, который  хочется продолжить на примере и других ИТ-компаний. Мне хотелось самому разобраться во многих вопросах, однако возникла идея поделиться этим с другими. Я не являюсь экспертом в области финансов, комментарии будут крайне ценными!

На этой неделе состоялся традиционный регулярный “звонок” компании Google своим инвесторам, в рамках которого компания делится своими результатами за последний период и отвечает на вопросы. Являясь публичной компанией, Google предоставляет всю информацию в открытом виде, интересующиеся могут ознакомиться с записью звонка, слайдами и пресс-релизом со всеми финансовыми деталями. Звонок – это презентация от финансового директора компании и ключевых руководителей (в этот раз был и CEO Эрик Шмидт), слушатели – аналитики крупнейших финансовых институтов – Goldmahn Sachs, JPMorgan, Barclays и др.

Несомненно, третий квартал 2010 года (у Google финансовый год совпадает с календарным) получился впечатляющим и кроме того отражает продолжающийся большой рост ИТ-индустрии (я могу, например, вспомнить рекордные цифры Microsoft в июле этого года). В то же время для самой компании это было крайне важно, так как результаты второго квартала оказались ниже прогнозов аналитиков, что послужило поводом для разного рода размышлений специалистов.

DDoS-атака — сокращение от Distributed Denial Of Service Attack. Это когда куча зараженных компьютеров посылают на сервер множество запросов. В итоге сервер тратит все свои ресурсы на обслуживание этих запросов и становится практически недоступным для пользователей. Размер атак бывают разные, от крупных может спасти только специалист и Cisco Guard :) и такое решение стоит не менее 1000$/мес. Но такие атаки, слава богу, довольно редкое явление. Чаще всего мы видим простые атаки, которые делают как правило школьники (им же все интересно). Создать свой ботнет не сложно, можно даже купить готовый :). Но такие атаки тоже могут нанести вред нашему веб-проекту. Что же делать если атака маленькая и платить огромные деньги специалисту мы не хотим?

Не так давно я столкнулся с проблемой аналога ip unnumbered на Linux, которая с легкостью реализовывается на оборудование Cisco.
При использование такого вида маршрутизации, не придется делить сеть глобально маршрутизируемых ip адресов на небольшие с маской /30 или /31. Достаточно присвоить, например, интерфейсу loopback сеть класса C ( /24 ), а клиентским интерфейсам указать на то, что вся обработка IP пакетов будет осуществляется с адресом присвоенным loopback interface. Тем самым вы получаете рациональное использование IP адресов.
Рассмотрим теперь выше сказанное на практике.

Точное время в сети большого стоит. Сегодня поговорим о настройке точного времени используя оборудование Cisco.

Проблема стара как мир и сегодня мы ее решим :)
Дано: 2 провайдера (ISP1 и ISP2), внутренняя сеть и между ними маршрутизатор.
Задача: настроить один основной (ISP1) и один резервный канал (ISP2), при падении первого переключится на второй, при поднятии первого переключится обратно.

UPD: Обновил, дописал ip sla, пока без объяснений.

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

Вот решил поделиться некоторым материалом, который сам составил в ходе экспресс-изучения SEO оптимизации и раскрутки сайтов. Просто попался видео-курс Юсуфа Губайдуллина, который продает его на promoguide.ru и решил воспользоваться случаем. Честно говоря, курс не понравился — нудно как-то рассказывается. Оценил содержание на 4 с минусом, а изложение — на 2 с плюсом. Само SEO весьма скучная вещь, но нужная, поэтому составил небольшую памятку для себя — чтобы не держать это в голове и легко вспомнить когда понадобится. Здесь два файла: первый — просто картинка, второй — в формате freemind, для тех, кто желает что-то для себя добавить.

Рекомендации геймдизайнеру от программиста (архитектора).

Вступление

Компьютерные игры — относительно молодая отрасль, которая в перспективе сменит киноиндустрию, так-же как кинофильмы заменили театр. Создание игры — это коллективное творчество, во многом напоминающее создание кинофильма. Кроме того, создание компьютерных игр — одна из самых сложных IT задач, поскольку она включает все себя практические все IT области.

Все слышали про pre poduction, но мало кто знает как именно это происходит. И если про стадию разработки написано много, а про стадию издания — еще больше, то про стадию планирования известно очень мало. В лучшем случае вам посчастливится ознакомится с результатами планирования. А вот как были достигнуты эти результаты? — загадка во тьме.

Этот документ является результатом «разбора полетов» после написания игры Звездная арена для социальных сетей. В этом документе я попытался упорядочить список проблем и решений к которым я и Александр пришли в процессе совместной работы над игрою. Кроме того этот документ является частью большой работы по выстраиванию рабочего процесса создания компьютерных игр.

Я намеренно оставил за кадром другие документы: концепцию, экономическое обоснование и ТЗ для других исполнителей. Это позволило сфокусироваться на одной теме и осветить ее и только ее достаточно подробно.

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

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

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

Уверен, что не готовы ни мы, ни любая иная отечественная компания-разработчик. И если основная задача юриста – это распознать и нивелировать правовые риски, то мне бы стоило задуматься над тем, какие гарантии мы можем предложить Заказчику, а какие оставить за бортом.
Проведя небольшое исследование, хочу поделиться своими выводами по этому поводу:

    Наверняка многие из нас хоть раз думали про себя: «Черт побери, и везет же этим американцам!». Это касается многого, от магазинов с доставкой «только в пределах 48 континентальных штатов» до вполне серьезных контрактов, которые срываются только потому, что потенциальный заказчик в США категорически не желает иметь дело с иностранцами.

    В этой статье я попробую осветить процесс создания и администрирования американской корпорации для резидента РФ. Наверняка многие из фактов для самих американцев покажутся тривиальными, однако для жителя России все куда сложнее — увы, это данность. Чтоб не сказать — это Родина, сынок. Оговорюсь сразу — я все это проделал более 2 лет назад, так что, некоторые детали могут быть не совсем актуальны. Но вряд ли что-то поменялось принципиально.

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

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

$query = "Select something";
$result = $cache->get($query, $tag);
if (!$result) {
    $result = $db->queryAll($query);
    $cache->set($query, $tag);
}

И хочется чего-то другого. Конечно, код можно вынести в отдельную функцию или метод, но это как-то скучно и к тому же, для каждого разного вызова (а там есть не только $db->queryAll, а несколько разных вариантов) нужен будет свой код и своя функция/метод.

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

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

Хотелось бы поделиться опытом по использованию MySQL с хранением данных в памяти, а не на диске. Это позволило нам сократить load average сервера, который из-за операций с диском стал сильно расти.

Сердце кровью обливается, когда читаю статью и уж тем более — комментарии к ней. Одно упоминание о магнатах среды 1С в качестве решения для автоматизации деятельности аптечной сети чего стоит. Уважаемые хабратоварищи, 1С Управление Торговлей В ПРИНЦИПЕ не приспособлена для торговли в фармбизнесе! А заслуживающие внимания потуги любимой дочки 1С на поприще адаптации Розницы все так же не решают до конца главных проблем этой системы. А при этом условии это решение не имеет права стоить таких денег, за которые оно продается.
Мое мнение — это всего лишь мнение, накопленное в процессе многолетней работы в среде фармацевтических торговых предприятий, как розничных, так и оптовых. Но раз уж я упомянул ту статью, то знакомому с ней станет понятно, что речь пойдет все-таки о розничной части.
Итак, попробую пояснить, почему обливается кровью мое сердце. В некотором смысле этот пост задумывается как набор рекомендаций автору статьи, пока не потрачены впустую совершенно неоправданные деньги.
Кому интересно — добро пожаловать под кат. Предупреждаю: ни одной картинки и много букв.

Те, кто читал книгу Андрея Александреску «Современное программирование на C++» знают, что существует обширный класс задач (в области метапрограммирования с использованием шаблонов), когда шаблону при инстанцировании необходимо указать переменное (заранее неизвестное) количество аргументов. Типичные примеры таких задач:
— Описание кортежей (tuples)
— Описание типов наподобие вариантов (variants)
— Описание функторов (в этом случае перечень типов аргументов зависит от сигнатуры функции)
— Классификация типов по заранее заданным множествам
— и т. п.

В каждой такой задаче точное количество типов, передаваемых соответствующему шаблону в качестве аргументов, заранее определить сложно. И, вообще говоря, зависит от желания и потребностей того, кто намеревается использовать соответствующий шаблонный класс.
В рамках действующего стандарта С++ сколь-нибудь удобного решения таких задач не существует. Шаблоны могут принимать строго определённое количество параметров и никак иначе. А. Александреску (в упомянутой выше книге) предлагает общее решение, основанное на т. н. «списках типов», в котором типы представлены в виде односвязного списка, реализованного посредством рекурсивных шаблонов. Альтернативным решением (используемом, например, в boost::variant и boost::tuple) является объявление шаблонного класса с большим количеством параметров, которым (всем, кроме первого) присвоено некоторое значение по умолчанию. Оба этих решения являются половинчатыми и не охватывают весь спектр возможных задач. По этому, для устранения недостатков существующих решений и упрощения кода новый стандарт предлагает С++-разработчикам новый вариант объявления шаблонов? «шаблоны с переменным количеством параметров» или, в оригинале, «variadic templates».