Привет, Хаброжители! Если вы побаиваетесь конкурентного и многопоточного программирования, эта книга написана для вас. Стивен Клири предоставляет в ваше распоряжение 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.

В интернете огромное количество заметок на тему удаленной работы, с лаконичным обзором минусов, плюсов и известными советами, как вытащить себя из рутины, начиная с «Первым делом снимите пижаму». В блоге Surf мы уже затрагивали эту тему в статье моей коллеги, которая поделилась своим опытом, но с ростом количества удаленных сотрудников (и моим переходом на «удаленку» после 20-летнего опыта работы в офисе), я решила изучить вопрос глубже: читала зарубежные блоги про удаленную работу и пробовала разные идеи. Здесь поделюсь своим опытом, методами сохранения и повышения мотивации. А в конце статьи я приготовила небольшую памятку сотруднику home office.

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

Существует ли в мире очень большая и крупная база данных, которая время от времени не страдает от проблем с производительностью? Держу пари, что их не так уж много. Поэтому каждый DBA (администратор базы данных), отвечающий за PostgreSQL, должен знать, как отслеживать потенциальные проблемы производительности, чтобы выяснить, что на самом деле происходит.

Повышение производительности PostgreSQL после настройки параметров

Многие думают, что изменение параметров в postgresql.conf — это реальный путь к успеху. Однако это не всегда так. Конечно, чаще всего хорошие параметры конфигурации базы данных очень полезны. Тем не менее, во многих случаях реальные проблемы будут возникать из-за странного запроса, скрытого глубоко в некоторой логике приложения. Даже вполне вероятно, что запросы, вызывающие реальные проблемы, не являются теми, на которые вы обратили внимание. Возникает естественный вопрос: как мы можем отследить эти запросы и выяснить, что на самом деле происходит? Мой любимый инструмент для этого — pg_stat_statements, который всегда должен быть включен по моему мнению, если вы используете PostgreSQL 9.2 или выше (пожалуйста, не используйте его в более старых версиях).

При сложной обработке больших наборов данных (разные ETL-процессы: импорты, конвертации и синхронизации с внешним источником) часто возникает необходимость временно «запомнить», и сразу быстро обработать что-то объемное.

Типовая задача подобного рода звучит обычно примерно так: «Вот тут бухгалтерия выгрузила из клиент-банка последние поступившие оплаты, надо их быстренько вкачать на сайт и привязать к счетам»

Но когда объем этого «чего-то» начинает измеряться сотнями мегабайт, а сервис при этом должен продолжать работать с базой в режиме 24x7, возникает множество side-эффектов, которые будут портить вам жизнь.

Чтобы справиться с ними в PostgreSQL (да и не только в нем), можно использовать некоторые возможности для оптимизаций, которые позволят обработать все быстрее и с меньшим расходом ресурсов.

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

Эта статья будет особенно интересна тем, кто много слышал о Go, но пока еще не попробовал его самостоятельно.

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

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

Я расскажу про собственный опыт и про найденное решение.

Привет, меня зовут Андрей Щукин, я помогаю крупным компаниям мигрировать сервисы и системы в Облако КРОК. Вместе с коллегами из компании Southbridge, которая проводит в учебном центре «Слёрм» курсы по Kubernetes, мы недавно провели вебинар для наших заказчиков.

Я решил взять материалы отличной лекции Павла Селиванова и написать пост для тех, кто ещё только начинает работать с инструментами provisioning’а облаков и не знает, с чего начать. Поэтому я расскажу про стек технологий, которые используются у нас в обучении и продакшене Облака КРОК. Поговорим о современных подходах к управлению инфраструктурой, про связку компонентов Packer, Terraform и Ansible, а также про инструмент Kubeadm, с помощью которого мы будем производить установку.

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

Не давайте имён курам
Печёные пирожки полезнее жареных
Начинаем печь. Packer
Terraform — инфраструктура как код
Запуск Terraform
Структура кластера Kubernetes
Kubeadm
Репозиторий со всеми файлами

В статье Raspberry Pi + CentOS = Wi-Fi Hotspot (или малиновый роутер в красной шляпе) я рассказал о способе превращения «малинки» в беспроводную точку доступа при помощи операционной системы CentOS. Собрав по такому чертежу мой домашний роутер, я удовлетворил свое творческое эго и получил заряд спокойствия за критически важный элемент моей уютной инфраструктуры. Однако ощущение незаконченности решения и внутренний перфекционизм не давали покоя: «несовершенный результат работы не имеет права на существование». Мысль о том, «что идеал может и должен быть достигнут» не покидала меня ни на минуту.

И вот однажды на одном из тематических форумов я натолкнулся на обсуждение разрядности существующих операционных систем для «малинки» (aarch64 vs armhfp): какие 64-битные ОС в принципе могут влезть и заработать на Raspberry версии 3++?

Моя любимая CentOS для архитектуры ARM от «Userland» не спешила переходить на ядро последней версии и превращаться в 64-битную. А репозиторий EPEL, подключенный Бог весть откуда без цифровой подписи, являлся кошмаром в мой неспокойный сон…

Выступая адептом RPM-based дистрибутивов, я с удивлением обнаружил, что в обсуждениях ОС для «малинки» абсолютно забытой оказалась Fedora! И это при том, что ее релиз
с 28-ой версии официально поддерживает Raspberry Pi 3B+ в 64-битном исполнении!

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

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