Ещё в начале марта большинство крупнейших IT-компаний США перевели своих офисных сотрудников на работу из дома. Microsoft, Alphabet, Twitter, Microsoft, Apple, Uber и многие другие. И вот теперь подоспели первые результаты. Новые исследования показывают, как удалённая работа из-за коронавируса влияет на продуктивность сотрудников, и в чём могут заключаться подводные камни.

Материал статьи взят с моего дзен-канала.

Механизм перемещения данных

• Блок данных dblk_t
• Сообщение mblk_t
• Функции работы с сообщениями mblk_t
• Очередь queue_t
• Функции работы с очередями queue_t
• Соединение фильтров
• Сигнальная точка графа обработки данных
• Закулисная деятельность тикера
• Буферизатор MSBufferizer
• Функции работы с MSBufferizer

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

Для начала посмотрим на определение интерфейса у Эндрю Троелсена и Филиппа Джепикса: «Интерфейс представляет собой всего лишь именованный набор абстрактных членов. Абстрактные методы являются чистым протоколом, поскольку они не предоставляют свои стандартные реализации. Специфичные члены, определяемые интерфейсом, зависят от того, какое точно поведение он моделирует. Другими словами, интерфейс выражает поведение, которое заданный класс или структура может избрать для поддержки». И дальше по тексту: «Запомните, что при определении членов интерфейса область реализации для них не определяется. Интерфейсы — это чистый протокол и потому реализация для них никогда не предоставляется».

Отлично, вроде бы все понятно, приблизительно такая же трактовка интерфейса будет описана и в других книгах по языку, но в C# 8 интерфейс несколько пересмотрен и добавлены на первый взгляд противоречащие возможности типа. Рассмотрим же интерфейсы в C# 8 более подробно.

Всем привет!

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

TL;DR: Сейчас я живу в городе Виктория, на острове Ванкувер. Это Канада, Британская Колумбия. Свою мечту жить у океана я реализовал, но это заняло 5 лет, и сначала были совершенно другие планы. Более подробно ниже. Ниже картинка моих рабочих мест за последние 10 лет.

Меня всегда тянуло уехать куда-нибудь. Поначалу было все равно, я хотел лишь находиться в новом для себя месте, желательно не России. Это совершенно не связано с политическим климатом или еще чем-то. Я родился и учился в Москве, и Москва это офигенный город. С карьерой более-менее все хорошо было.

В студенческие годы мой отец, подсунул мне ссылку на world4u — это волонтерская организация по обмену. В 2007, 2008, 2009 я посетил Германию, Францию и Италию. В среднем программа была по 1-2 месяца и нужно было оплатить только за перелет. Именно эти европейские проекты оказали на меня влияние, я увидел мир, и понял, что это скучно прожить жизнь в одном месте, даже с комфортом. Картинка ниже очень хорошо передает мой основной мотив:

Это из детского рассказа про Улитку и Кита:

Начинаем рассказ (занимайте места!)
Про малютку улитку и великана кита.
Вот скала,
Где над морем улитка жила,
И вздыхала она то и дело:
-Как мне все надоело!
Мир огромен, а я тут сижу на скале,
А могла бы уплыть на большом корабле…

Всем привет! В преддверии старта курса «Инфраструктурная платформа на основе Kubernetes» подготовили перевод еще одного интересного материала.

---

Эта статья рассчитана на новичков в Kubernetes, которым будет интересно разобраться на практическом примере, как написать Golang API для управления TODO list-ом, и затем как развернуть его в Kubernetes.

Каждый разработчик любит хороший TODO list, не правда ли? Как бы еще мы могли себя организовать иначе?


Каждый разработчик любит хорошее TODO приложение, не так ли?

Мы начнем с обзора перечня необходимых компонентов, затем перейдем к настройке Kubernetes, предоставим базу данных Postgresql, а затем установим фреймворк приложения, который поможет нам легко развернуть Go API в Kubernetes, не зацикливаясь на деталях.

Предлагаю ознакомиться с расшифровкой доклада Николая Самохвалова "Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных"

Shared_buffers = 25% – это много или мало? Или в самый раз? Как понять, подходит ли эта – довольно устаревшая – рекомендация в вашем конкретном случае?

Пришло время подойти к вопросу подбора параметров postgresql.conf "по-взрослому". Не с помощью слепых "автотюнеров" или устаревших советов из статей и блогов, а на основе:

1. строго выверенных экспериментов на БД, производимых автоматизированно, в больших количествах и в условиях, максимально приближенных к "боевым",
2. глубокого понимания особенностей работы СУБД и ОС.

Используя Nancy CLI (https://gitlab.com/postgres.ai/nancy), мы рассмотрим конкретный пример – пресловутые shared_buffers – в разных ситуациях, в разных проектах и попробуем разобраться, как же подобрать оптимальную настройку для нашей инфраструктуры, БД и нагрузки.

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

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

Слёрм запустил Вечернюю школу по Kubernetes: цикл бесплатных лекций и платных практических занятий для тех, кто изучает k8s с нуля.

Занятия ведут Марсель Ибраев, инженер Southbridge, CKA, и Сергей Бондарев, инженер Southbridge, СКА, один из разработчиков kubespray с правами на принятие pull request.

Выкладываю записи первой недели для тех, кто перед регистрацией хочет понять, как у нас все устроено.

На первой неделе разбирали Docker. Перед нами стояла конкретная задача: дать основы Docker, достаточные для последующей работы с k8s. Поэтому под него выделили одну неделю, и многое осталось за кадром.

Запись первого дня:

Привет, Хаброжители! Если вы побаиваетесь конкурентного и многопоточного программирования, эта книга написана для вас. Стивен Клири предоставляет в ваше распоряжение 85 рецептов работы с .NET и C# 8.0, необходимых для параллельной обработки и асинхронного программирования. Конкурентность уже стала общепринятым методом разработки хорошо масштабируемых приложений, но параллельное программирование остается непростой задачей. Подробные примеры и комментарии к коду позволят разобраться в том, как современные инструменты повышают уровень абстракции и упрощают конкурентное программирование. Вы научитесь использовать async и await для асинхронных операций, расширять возможности кода за счет использования асинхронных потоков, исследовать потенциал параллельного программирования с библиотекой TPL Dataflow, создавать конвейеры потоков данных с библиотекой TPL Dataflow, задействовать функциональность System.Reactive на базе LINQ, использовать потоково-безопасные и неизменяемые коллекции, проводить модульное тестирование конкурентного кода, брать под контроль пул потоков, реализовывать корректную кооперативную отмену, анализировать сценарии на предмет объединения конкурентных методов, пользоваться всеми возможностями асинхронно-совместимого объектно-ориентированного программирования, распознавать и создавать адаптеры для кода, в котором используются старые стили асинхронного программирования.

Мы широко используем микросервисную архитектуру, хоть и не считаем ее панацеей, и чуть больше 2 лет назад начали переходить на язык Go. Он сравнительно прост и, на мой взгляд, очень хорошо подходит для создания простых, небольших и быстрых микросервисов. Эта простота имеет и обратную сторону: из-за неё возникает множество способов решить одну и ту же задачу.

Казалось бы, насколько сильно может отличаться один микросервис, который ходит в базу данных, от другого микросервиса, который ходит в соседнюю базу данных? Например, одна команда использует Go 1.9, glide, стандартный database/sql и одну структуру проекта, а в это же время другая команда использует Go 1.13, modules, sqlx и, конечно же, другую структуру проекта.

Когда один микросервис в компании отличается от другого, а он, в свою очередь, отличается от третьего — это замедляет разработку. А медленная разработка — это убытки повод для оптимизации.

Меня зовут Алексей Партилов, я техлид команды web-разработки в компании Lamoda. В этой статье я расскажу, как мы справляемся с разношерстностью около 40 наших микросервисов на Go. Статья будет полезна разработчикам, которые только вливаются в Go и не знают, с чего начать более сложный проект, чем “helloworld”.

Прелюдия

Это первая из четырех статей в серии, которая даст представление о механике и дизайне указателей, стеков, куч, escape analysis и семантики значения/указателя в Go. Этот пост посвящен стекам и указателям.

Оглавление цикла статей:

1. Language Mechanics On Stacks And Pointers
2. Language Mechanics On Escape Analysis (перевод)
3. Language Mechanics On Memory Profiling (перевод)
4. Design Philosophy On Data And Semantics

Вступление

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

В предыдущей статье мы говорили о новой программной модели чейнкода в Hyperledger Fabric. И хотя релиз нового Go SDK ещё не состоялся, ничто не мешает нам уже сейчас посмотреть, что нас ждет в будущем, и даже протестить это на тестовой сборке. Не всё ещё реализовано (как, например, commit handlers), но планируемый дизайн программной модели уже ясен, так что давайте взглянем на него ближе.

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

Ядро LXD — это привилегированный демон (сервис запущенный с правами root), который предоставляет REST API через локальный unix сокет, а также через сеть, если установлена соответствующая конфигурация. Клиенты, такие как инструмент командной строки поставляемый с LXD посылают запросы через этот REST API. Это означает, что независимо от того, обращаетесь ли вы к локальному хосту или к удаленному, все работает одинаково.

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

Можно ли изучить Kubernetes — такую сложную и глубокую технологию — за три дня?

Слёрм запустил «Вечернюю школу», где базовый курс по Кубернетес можно пройти за 4 месяца.
В честь этого события узнаем у Павла Селиванова, архитектора Kubernetes-решений, Certified Kubernetes Administrator и автора интенсивов Слёрм, зачем вообще изучать Кубернетес и в чем сила трехдневного интенсива по сравнению с 4-месячным курсом.

Павел стоял у истоков интенсива по Kubernetes и решал задачу, как быстро и качественно подготовить администратора за три дня, чтобы тот мог вернуться на работу и запустить K8s — тем самым решая потребность бизнеса «уже вчера запустить кластер».

Я работаю в Red Hat над GCC, GNU Compiler Collection. Для следующего основного релиза GCC, GCC 10, я реализовывал новую опцию -fanalyzer: проход статического анализа для выявления различных проблем во время компиляции, а не во время исполнения.

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

Привет! Меня зовут Катя Лебедева. Я работаю ВКонтакте последние 8 лет: трудилась в Поддержке, потом руководила этой же командой, а в прошлом году возглавила ещё два направления: Редакция, где создаются все тексты ВКонтакте на всех языках, и Лаборатория, в которой мы занимаемся внутренними коммуникациями компании и отдельными межкомандными проектами. В каждой из моих команд большая часть сотрудников либо полностью, либо частично работают на удалёнке — мы выбрали этот формат за много лет до того, как самоизоляция стала мейнстримом.

Предлагаю ознакомиться с расшифровкой доклада 2018 года Андрея Сальникова "Практика обновления версий PostgreSQL"

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

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

В Data Egret мы накопили огромный опыт проведения мажорных апгрейдов PostgreSQL в проектах, где нет права на ошибку. Я поделюсь своим опытом и расскажу о следующих шагах процесса: как правильно подготовиться к upgrade-у PostgreSQL? что необходимо сделать на этапе подготовки? как запланировать последовательность действий на сам upgrade? как провести процедуру upgrade-а успешно, без возврата на предыдущую версию бд? как минимизировать или вообще избежать простоя всей системы во время upgrade-а? какие действия необходимо выполнить после успешного upgrade-а PostgreSQL? Я также расскажу про две наиболее популярные процедуры апгрейда PostgreSQL — pg_upgrade и pg_dump/pg_restore, плюсы и минусы каждого из методов и расскажу про все типичные проблемы на всех этапах этой процедуры, и как их избежать.

Доклад будет интересен как новичкам так и тем ДБА которые уже давно работают с PostgreSQL, но хотят побольше узнать о том как правильно планировать и проводить upgrade максимально безболезненно.

Предыстория

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

Реализация

Так как я постоянно постил новые купоны в телеграм, да и в целом мне нравится этот инструмент, решил создать еще одного бота для телеграма, благо дело для него уже создано достаточное количество библиотек. Возьмем в качестве языка golang и библиотеку telegram-bot-api. Так же нам нужно выбрать ресурс с которого можно было бы тянуть информацию, у меня на примете было несколько сайтов и я думал в целом написать универсальный парсер, но в какой-то момент мне стало лень, и я решил остановить свой выбор на одном ресурсе. Для того чтобы хранить купоны даже после рестарта, решил воспользоваться простой базой sqlite3. В ней будем хранить информацию о купонах, а так же информацию о зарегистрированных пользователях в телеграм боте, так же информацию о том какие купоны пользователь уже получил и какие ещё нет.

Выглядит это примерно так

Зачем переносить данные

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

Я решил изучить процесс миграции данных, изучая то, как реализовать пожелания конкретного заказчика, а также из практического любопытства, теперь я пробую перенести небольшую схему около 15 Гбайт с Oracle 11.2.0.4 на Linux Redhat 6.8 в Postgres 9.4 на Windows. Немного погрузившись в тему, я решил написать эту статью и рассмотреть процесс подробно. В отрыве от нашей специфики пост будет полезен интеграторам и DBA при планировании переноса данных/CUT.