Шел апрель 2020 года, ковидная пандемия набирала обороты. Местные власти объявили "карантин", и от скуки сидения дома в один из дней мне пришла в голову мысль разобрать завалы хлама в старой квартире. В одной из коробок мне попался ноунеймовый USB DVB-тюнер на чипе RTL2832U с Алиэкспресса, и тут я призадумался. Вспомнилось, что много-много лет назад я игрался с ним и в эфире можно было услышать много интересного. "А почему бы не поиграться еще раз?" — возникла в голове мысль, которая и положила начало этой истории.

На современных картах все больше появляется 360 аэроснимков, которые принято называть "Сферические панорамы". Почти каждый владелец БПЛА с камерой может создавать свою собственную сферу. Разбираем подробный способ создания 360 панорамы с помощью бюджетного дрона DJI Mini 2.

Понятие DevOps знакомо многим, но в своей практике я часто наблюдаю такую ситуацию, когда соискатель на должность DevOps-инженера в нашу компанию не может ответить на вопрос “А что же такое DevOps?”. В данной статье я хочу упорядочить и структурировать знания и основные понятия DevOps. Ещё раз обозначить какие процессы там существуют, для чего они и с чего начать внедрение DevOps у себя в проекте.

Когда я начал работу с Kubernetes, и Infrastructure as Code (IaC), я быстро понял, что мне нужно решение для работы с секретами. Когда я поискал в интернете, то не увидел единого мнения по поводу практического подхода к проблеме, подходящего ко всем ситуациям. Поэтому, в этом году, я поставил себе задачу изучить, какие решения для управления секретами приложения и инфраструктуры существуют, решить, которое из них я считаю лучшим и освоить его. В конце исследования, я пришел к выводу, что HashiCorp Vault перехвален, а Mozilla SOPS с KMS и Git неоправданно недооценены.

- Составь, пожалуйста, руководство по тому, как делать архитектуру.

С такой просьбой ко мне однажды обратились менеджеры по разработке софта в компании, где я работаю или работал (не хочу раскрывать время и место). И надо сказать, что сначала эта просьба меня здорово озадачила. На тему архитектуры софта написано много книг, и не самых тонких. Мне предлагается написать еще одну? Чем она будет отличаться от существующих? И зачем вообще им это?

Что касается "зачем", то здесь все было понятно. Цель у менеджеров была благая. Проектов в компании обычно больше, чем могут осилить штатные архитекторы. Идея была в том, чтобы архитектуру для небольших проектов делали либо сами менеджеры по разработке, либо старшие разработчики, а архитектор только проверял, направлял и помогал где нужно.

Цель хорошая, запрос хороший. Оставалось только понять, как оказать им конструктивную помощь, а не отправить читать книжки или не засесть писать свою.

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

Собственно, этот список я здесь и публикую.

Это аппаратный ключ безопасности, который поддерживает протокол универсальной двухфакторной аутентификации, одноразовые пароли и асимметричное шифрование. Если вы добавите его, допустим, в аккаунт на Гитхабе, то для входа в свой аккаунт, понадобится ввести логин/пароль и коснуться кнопки юбикей.

Год назад я приобрел Yubikey, чтобы использовать его в качестве второго фактора для аккаунтов Google, Github и других, которые работают с U2F. Однако я для себя выяснил, что Yubikey обладает куда более расширенным функционалом. Большая часть из нижеописанных действий  актуальна для работы и без Yubikey, однако преимущество в портативности будет потеряно.

Все действия описаны для Yubikey 5 и Ubuntu 21.04.

Предисловие

Краткое содержание:

• Пишите, исходя из структуры хранения данных: если вы храните данные типа datetime, используйте именно datetime, а не varchar или что-нибудь еще.
• Пишите, исходя из наличия индексов: если на таблице построены индексы, и они должны там быть, пишите код так, чтобы он мог использовать все преимущества, предоставляемые этими индексами. Убедитесь, что кластерный индекс, а для каждой таблицы он может быть только один, используется наиболее эффективным образом.
• Пишите так, чтобы помочь оптимизатору запросов: оптимизатор запросов – восхитительная часть СУБД. К сожалению, вы можете сильно затруднить ему работу, написав запрос, который ему «тяжело» будет разбирать, например, содержащий вложенные представления – когда одно представление получает данные из другого, а то из третьего – и так далее. Потратьте свое время для того, чтобы понять как работает оптимизатор и писать запросы таким образом, чтобы он мог вам помочь, а не навредить.