Доброго времени суток, господа и дамы! Иногда у некоторых людей возникает желание заняться откровенным непотребством в программировании — то, что не несет практической пользы напрямую, но помогает развлечься. И я — не исключение. В этой статье я хочу рассказать вам о лайфхаках, трюках (магических и не очень), алгоритмах на языке C!

Идея написать эту статью зародилась из моего поста, после него я начал серию статей, которая раскрывала много интересных моментов — от математических алгоритмов и оптимизации до ГПСЧ.

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

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

Всех, кто заинтересовался — прошу под кат.

Неожиданное поведение приложения в отношении работы с базой приводит к войне между DBA и разработчиками: DBA кричат: «Ваше приложение роняет базу», разработчики — «Но ведь до этого всё работало!». Хуже всего, что DBA и разработчики не могут помочь друг другу: одни не знают про нюансы работы приложения и драйвера, другие не знают про особенности, связанные с инфраструктурой. Было бы неплохо такой ситуации избежать.

Надо понимать, часто недостаточно полистать go-database-sql.org. Лучше вооружиться чужим опытом. Еще лучше, если это будет опыт, полученный кровью и потерянными деньгами.

В последние несколько лет в среде технических писателей все больше на слуху концепция Docs as Code. Если вы раньше не сталкивались с этим термином, он обозначает подход к разработке технической документации с использованием тех же инструментов и процессов, что и написание кода. Если DocOps это про процессы и коллаборацию, то Docs as Code — про инструментарий, при помощи которого мы несмотря ни на что. Мы выбрали этот подход, когда создавали портал документации Plesk.

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

1. Файрвол PF в ОС FreeBSD
2. FreeBSD. Фильтрация трафика PF
3. FreeBSD. трансляции, тэги и якоря в PF
4. FreeBSD. Условная маршрутизация средствами PF <- Вы здесь
5. FreeBSD. Путь сетевого пакета внутри ядра

Введение

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

В этой статье разберем возможности PF и FreeBSD в части продвинутой маршрутизации. Policy Based Routing (PBR), Source Based Routing (SBR), условная маршрутизация, маршрутизация на основе политик, все эти понятия, по сути, равнозначны и описывают одну возможность. Выбирать маршруты, либо таблицы маршрутизации для трафика на основе правил фаервола.

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

Для уменьшения файлов конфигурации и большей наглядности, в этой статье правила фильтрации будут максимально упрощены.

15 сентября в Авито прошёл митап, на котором мы говорили о масштабировании приложений на PostgreSQL. Сегодня я хочу поделиться материалами с него — видеозаписями, презентациями от докладчиков, показать фото. Также под катом публикую разбор вопросов викторины, которую мы проводили здесь, на Хабре, перед митапом. И рассказываю о своих впечатлениях от встречи.

У многих достижений версии PostgreSQL 10 прописка в разделе Секционирование (Partitioning). И это справедливо: очевидно, что при переходе от 9.6 к 10 произошел мощный технологический скачок. В предыдущих версиях секции строили и управляли ими, теми средствами, что уже имелись: механизмом наследования со всеми его ограничениями и неудобствами.

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

К тому же последние пару лет параллельно велись разработки модуля pg_pathman в Postgres Professional. Некоторые важные возможности пересеклись, некоторые остались уникальны для PostgreSQL и pg_pathman (который работает с ванильной версией, то есть PostgreSQL 10 + pg_pathman дает уже вполне впечатляющую сумму функциональности). Об этом будет отдельная статья. Замечания, относящиеся к версии 11 и к pg_pathman для удобства выделены курсивом.

Эта статья представляет собой переработанные и дополненные фрагменты книжки Nouveaulités de PostgreSQL 10. (с) Dalibo, перевод с французского Игоря Лёвшина (оригинал). Примеры из книги проверены, иногда адаптированы и локализованы для большей наглядности.

• Хотя оконные функции объективно сложнее обычных агрегатных, но ничего запредельного в них нет; это абсолютно необходимый инструмент для SQL-разработчика. А создание собственной оконной функции, даже совсем простой, позволяет лучше разобраться с тем, как работают стандартные.
  
• Оконные и агрегатные функции — прекрасный способ совместить процедурную обработку с декларативной логикой. В некоторых ситуациях получается выполнить сложные действия, оставаясь в рамках парадигмы решения задачи одним SQL-запросом.
  
• Да и просто интересная тема, а уж тем более интересно сравнить две системы.
  

Добрый день/вечер/ночь/утро! Есть один экспериментальный курс по операционным системам. Есть он в Стэнфордском университете. Но часть материалов доступно всем желающим. Помимо слайдов доступны полные описания практических занятий.

Чем этот курс отличается от прочих других? Большая часть кода пишется самостоятельно и выполняется на вполне реальном современном железе. В качестве целевой платформы выбран Raspberry Pi 3 model B. Т.е. достаточно актуальная архитектура AArch64. ARMv8 Cortex-A53, четыре ядра, 64-бита и вот это всё. В качестве основного языка программирования выбран Rust. Который безопасный, быстрый, без GC и так далее. Его, Rust, предполагается изучать во время курса.

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

Автор статьи — Михаил Комаров, MVP — Cloud and Datacenter Management

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

Предисловие