Поддержка DoH уже встроена во все основные браузеры. Пользователям нужно её только включить и настроить.

1. Вводная (зачем, да почему)
2. Конкретные расчеты
3. Философско-практическая часть.

• неэффективный алгоритм
  когда вы решили сделать JOIN нескольких CTE по паре десятков тысяч записей
• неактуальная статистика
  если фактическое распределение данных в таблице уже сильно отличается от собранной ANALYZE'ом в последний раз
• «затык» по ресурсам
  и уже не хватает выделенных вычислительных мощностей CPU, постоянно прокачиваются гигабайты памяти или диск не успевает за всеми «хотелками» БД
• блокировки от конкурирующих процессов

«Понимание плана — это искусство, и чтобы овладеть им, нужен определённый опыт, …»

Существует много метрик, относящихся к логике и качеству работы блокчейна. Они помогают определить узкие места в коде и найти логические и оптимизационные проблемы в алгоритмах консенсуса и финальности в блокчейнах. Любая разработка распределенных систем, в том числе блокчейнов, требует анализа работы сразу множества узлов. Они позволяют команде проекта следить за состоянием всей блокчейн-сети, видеть проблемы с отдельными нодами, детектировать появление DoS атак на сеть и многое другое. Давайте рассмотрим основные из них. Let’s dive in.

Бессерверные вычисления — одна из наиболее заметных тенденций в облачных вычислениях. Основной принцип работы заключается в том, что инфраструктура — забота не DevOps’ов, а поставщика услуг. Масштабирование ресурсов автоматически подстраивается под нагрузку и обладает высокой скоростью изменения.

Другая общая черта — тенденция к минимизации и фокусировании кода, поэтому бессерверные вычисления иногда называют "функция как услуга" (FaaS).

type QueryError struct {
    Query string
    Err   error
}

func (e *QueryError) Error() string { return e.Query + ": " + e.Err.Error() }

Последнее время из каждого утюга слышатся хвалебные высказывания о многомировой интерпретации квантовой механики и негативные в сторону Копенгагенской. Вот, например, относительно недавняя статья на Хабре. Приверженцев идей отцов-основателей (Нильса Бора, Вернера Гейзенберга, Пола Дирака, Вольфганга Паули) теперь считают динозаврами, отказывающимися принять современную (1957 год) многомировую трактовку.

pprof — основной инструмент профилирования в Go. Профилировщик включен в стандартную библиотеку Go и про него, за годы, написано уже очень много. Чтобы подключить pprof в существующее приложение нужно просто добавить одну строчку кода:

import _ “net/http/pprof”

В HTTP-сервере по-умолчанию — net/http.DefaultServeMux — по пути /debug/pprof/ будут зарегистрированы обработчики, отдающие результаты профилирования.

curl -o cpu-profile.pb.gz http://<server-addr>/debug/pprof/profile

(подробнее см. https://godoc.org/net/http/pprof)

Но по опыту, не всегда все так просто и на практике с использованием pprof в бою, есть подводные камни.

[отсылка к американской детской сказке "Маленький паровозик, который верил в себя " ("The Little Engine That Could") — прим. пер.]*

Как автомагически создавать крохотные docker-образы для своих нужд

Необычная одержимость

Последние пару месяцев я был одержим навязчивой идеей: насколько можно уменьшить образ Docker, так чтобы при этом приложение работало?

Понимаю, идея странная.

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

Почему размер имеет значение

Сокращая содержимое образа Docker, мы тем самым сокращаем список уязвимостей. Дополнительно мы делаем образы чище, ведь они содержат только то, что нужно для запуска приложений.

Вероятность можно представлять себе разными способами. И квантовая механика охватывает их все

На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг "DevOps" инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.

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

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

А еще я хотел бы пригласить вас на Golang Conf 2019, которая пройдет 7 октября в Москве. Я член программного комитета конференции, и мы с коллегами выбрали много не менее хардкорных и очень, очень интересных докладов. То, что я люблю!

Под катом передаю слово автору.

Так повелось, что разработчики, еще только начинающие знакомиться с Go, часто сталкиваются с проблемой выбора рабочей директории для Go-проектов. Вот и в чате конференции GolangConf тоже задавался этот вопрос. Новые гоферы часто пугают друг друга словами GOPATH и GOROOT. Однако, в руководствах по быстрому старту с текущей версией Go (1.13) упоминания эти двух «страшных» слов вообще нет.