227
Гитхаб: https://github.com/vladzvx Навигация по каналу: #телеграм - о телеге и ботах #csharp - о шарпе #кодинг - разное об IT #проекты - мои проекты Стек: C#, PostgreSQL, Tarantool, MongoDB, RabbitMQ
Продолжение заметок по новым фишкам постгреса, которые я узнал на обучении. Начало выше.
9. Я узнал о существовании фильтрованных индексов. Например, при создании btree индекса по дате указываешь > 01.01.2024 - и твой индекс будет работать только на данные в указанном тобой условии. Собственно, можно оставить архивированое в архиве и работать только со свежими данными.
10. Увидел на практике, как использовать хинты для оптимизации запросов. С хинтами забавная история: контрибьюторы постгреса встали стеной против введения их в ядро СУБД. Потому японский Ростелеком в какой-то момент реализовал их в виде расширения pg_hint, которое может поставить себе любой желающий, если ему дадут админы и безопасники:)
11. Узнал некоторые особенности индексов, о которых раньше не задумывался.
Хэш индексы немногим быстрее btree, но при этом лишены упорядочивания, ускорения запросов по интервалу, возможности сортировать таблицу по ним. Зато, если мы строим их по большим строкам, по которым надо будет искать только на условие равенства - они дают существенный выигрыш по размеру индекса. При этом, размер хэша меняется, подстраиваясь под данные так, чтобы был минимум коллизий.
Есть такой тип индекса - BRIN. Отлично работает для индексации неизменяемого вечнохранимого набора данных, ранжированных по какому-то параметру. Занимает мизерное пространство на диске, но в большинстве кейсов бесполезен.
#postgresql
Попал я на обучение постгресу. Достаточно продвинутый уровень, для миддл разработчиков и выше, ранее активно пользовавшихся MS SQL или Oracle. У меня основная СУБД в стеке - PostgreSQL, но интересного и нового довольно много. Далее будет что-то типа заметок, содержащих новые для меня вещи, которые я узнал.
1. Штатная среда для написания запросов для постгреса - PgAdmin, очень функциональна в плане администрирования базы. Я всю жизнь сидел на DataGrip. Она хороша для написания запросов, спору нет. Но для сложных вещей, связанных с администрированием - лучше использовать PgAdmin. Как минимум, многие запросы для администрирования (ограничения для пользователей, собственные типы данных) проще сгенерировать через UI чем по кусочкам собирать копипастя из документации. В дополнение там очень подробный визуализатор внутренних объектов базы: в ui можно посмотреть кастомные типы, расширения, инструменты для полнотекстового поиска. В DataGrip или Dbeaver все намного беднее в этом плане.
2. Очень понравилось что-то типа кастомного типа: Domain. Это унаследованный базовый тип с прикрученным к нему ограничением на диапазон значений. Например - терминал аэропорта. Предположим, есть терминалы A, B, C, D, E. Унаследуемся от текстового типа, поставим ограничение - только одна заглавная буква из этого диапазона.
3. Механизм TOAST. Когда размер поля в таблице превышает определенное (настраиваемое) значение, в таблицу пишется ссылка на элемент "теневой таблицы", куда собственно записываются данные из поля. Для типа text по дефолту это 2Кб. Максимальное значение - 1Гб, обусловлено особенностями самого постгреса. Для записываемого в теневую таблицу значения можно настроить механизм сжатия. Кроме простой экономии занимаемого места, достигается и буст производительности: при чтении данных из таблицы, например при полном сканировании, вместо тяжёлых значений читаются десятки байт, содержащих ссылку на нужное место теневой таблицы, куда постгрес полезет только в случае реальной нужды.
#postgresql
Небольшое наблюдение. Сейчас идёт седьмой крупный (от шести месяцев полной моей занятости) проект за мою карьеру в IT. Из них на трех у меня была полная свобода в плане написания тестов и возможности тянуть резину двигать сроки релиза.
Что характерно - именно эти три проекта, когда пришло время, просто запустились с минимальным предрелизным безумием. А все, где тестов не было - запускались с нервотрепкой и вычерпыванием бесконечного числа багов. При этом, основательный подход к разработке удлинял время от старта проекта до первого запуска в препрод процентов на 50-60. Вроде бы много.
Но если вспомнить, сколько времени проходило на оставшихся четырех проектах от первого запуска до состояния "работает приемлимо", то получается что на авральную пусконаладку уходило за 30% времени разработки. При том к концу её код обрастал костылями, затыкающими дыры, а я выдыхался до состояния выжатого лимона и терял в производительности на пару тройку месяцев или вообще менял работу.
Я стараюсь не рекламировать пиратство в паблике, но текущая ситуация - это просто идеальный пример bus factor 1.
https://flibusta.site/node/681117
TLDR. Флибуста походу всё. Единственный ментейнер сейчас в больнице с раком мозга, а хостинг оплачен только на пару недель. А что будет потом - неизвестно. Очередной проект, который определил дух эпохи, лично для меня, скоро канет в лету.
К своему стыду не осознавал применительно к работе и играм сего подхода: если уверен в успехе - не выпендривайся:
Читать полностью…
Начал строить инфраструктуру для проекта домашнего каталога настолок (и частично для других будущих проектов).
Базовую площадку - gitea для хранения кода и управления процессом развертывания мне любезно предоставил друг. Был мысль завести свой собственный гитлаб или вообще все сделать на Github Actions, но я отказался от этой идеи. Администрировать гитлаб и платить аренду за сервер под него мне откровенно не хочется. Да и таск трекинг в гитлабе избыточно мудреный. В общем gitea меня полностью устраивает: тут и девопсячьи и менеджерские инструменты, например - доски задач внутри репозиториев, с прилинковкой к ним коммитов без лишних приседаний.
Пока задействовано четыре отдельных виртуальных сервера:
1. Сервер с базой данных каталога - PostgreSQL 16
2. Сервер для апи и браузерного клиента.
3. Хранилище для образов, пакетов и прочих артефактов.
4. Отдельный сервер, на котором осуществляется билд образов, которые впоследствии пушатся в хранилище из п. 3
Все 4 сервера взяты в качестве виртуалок у RUVDS. Почему не запихнуть все на один сервер, возможно - железный, арендованный у того же selectel?
Сборка образов, если дополнительно не подкручивать какие-то настройки, съедает 100% CPU. Если туда же запихать базу и сервисы - они начнут лагать. Постоянные билды могут подразумевать солидный кэш пакетов и базовых образов. Скорость сборки мне пока проект мой личный некритична, потому HDD, 1 ядро. Но на сборку может требоваться солидное количество оперативки, иначе она просто отваливается по out of memory, поставил пока 2Гб.
Для хранения образов мне в перспективе нужно много места, при этом, оперативки и ядер мне тупо не нужно. Потому тут 1 ядро, 500 Мб оперативки и HDD, который у RUVDS можно раздуть до 600 Гб
Базе данных при росте будут критичны все параметры, но на время разработки я ограничиваюсь самым дешёвым конфигом - 1 ядро, 500 Мб оперативки, 10 Гб SSD, 3 из которых сразу отданы под своп.
К серверу для сервисов требования примерно те же, что и к базе, но я решил завести его отдельно, чтобы проще было управлять зоопарком из контейнеров. Иногда приходится осуществлять массовые репрессии мероприятия, не хотелось бы случайно грохнуть базу.
Ну и вместо хорошей железной тачки ценой аренды тысяч в 8-10 в месяц, я имею 4 виртуалки, которые все вместе обходятся в 1100р на этапе разработки, а ресурсы я смогу наращивать по мере необходимости. Но да, настраивать придется 4 сервера вместо одного.
Начал новый проект - домашний каталог настольных игр. Пока планируется веб версия для браузера, мобильное приложение под андроид, сервис-апи и база.
Путем наименьшего сопротивления было бы сваять браузер на React.js, а приложение - на том же реакте, или на котлине. Но я решил попробовать нестандартный путь - шарповый фреймворк Avalonia.UI. Он заявляется как тру кросс-платформенный: единая кодовая база для web, desktop, android и ios.
Пока я потратил часов 7 на утрамбовку браузерной авалонии в докер. Работающих примеров утрамбовки Avalonia в докер я так и не нашёл, пришлось собирать что-то по мотивам обсуждения в сообществе авалонии. Логика примерно такая: подсунуть результаты билда шарпового проекта в WASM в папку для раздачи статического контенда nginx. Пример докерфайла в репозитории. Для запуска надо стартовать docker-compose-avalonia.yml в корне решения.
Продолжил читать Рихтера, дошел до делегатов. Делегат - это тип, описывающий метод: входящие и выходящие параметры. Можно например сделать метод, принимающий на вход делегат и вызывающий его внутри. И таким образом по ситуации подменять вызываемый метод. В общем штука банальная, иметь такое мне захотелось ~на третий месяц программирования на c#.
Но вот чего я не знал до текущего момента, это что делегаты могут представлять не только одиночные методы, но и их цепочки. В любой момент можно прикрепить к делегату метод, сделав +=. При вызове делегата будет последовательно вызвана вся цепочка методов. Возвращен будет результат выполнения последнего. Соответственно, открываются дополнительные возможности для формирования конвейеров обработки данных по критериям, задаваемым в рантайме.
Метод из цепочки также можно удалить вызвав -= метод.
#csharp
#рихтер
Некоторое время назад потыкал питоновские фреймворки на предмет быстрого создания веб апи. Мои требования:
1. Сваггер с описаниями методов и полей.
2. Типизированные модели, чтобы всякий мусор присылаемых извне отваливался на этапе десериализации.
3. Упаковка проекта в докер, желательно из коробки.
Этот набор требований - то что в c# даётся из коробки в шаблоне проекта.
Сначала я попробовал по старой памяти потыкать Flask. Читаю про сваггер. Можно подключить его десятком разных способов, в некоторых случаях мне предлагают прицепить yml описание методов.
Посмотрел в Django. Оказывается все не так плохо как несколько лет назад: туда завезли асинхронщину, не прошло и 10 лет. Сваггер описывается вроде нормально. Но тащить весь джанговский зверинец вместе с MVC для легковесной апишки мне запрещают религиозные убеждения. Плюс Django надо отдельно изучать, шарповый опыт не особо помогает понимать происходящее.
Попробовал новую для меня библиотеку - FastApi. Она вошла в употребление уже после того, как я полностью ушел от питона и она меня приятно удивила: все мои требования были удовлетворены в течении часа.
Все бы ничего, но возник вопрос: а питон - это точно про сделать что-то без боли и мучений?
Познакомился на практике с двумя шарповыми фреймворками для веб разработки: Razor Pages и Blazor. Оба позволяют писать фронтенд без js-a, на смеси c# и особого диалекта html.
Razor реализует паттерн MVC. Логика работы фреймворка примерно такая: поднимается сервер, который по согласованному множеству ссылок отдает в браузер html страницы по http.
Blazor несколько сложнее. Логика описывается на c#, после чего в браузер отдается нечто, висящее на веб сокете (SignalR) с бэком. Бэк отсылает обновления и реакции на действия юзеров, они отрисовываются. Такой черный магический ящик. Вообще, есть вариант Blazor-а, отдающий в браузер клиент на WebAssembly, но я не тыкал его пока.
Мне нужно было накидать полторы страницы. По ощущениям, лучше просто брать React.js всегда, когда можно и не страдать фигнёй, несмотря на простоту шарповых фреймворков.
У нас нет телевизора в общепринятом смысле: с каналами и антенной. Есть мини компьютер с виндой, к которому подключен настенный экран. С него мы включаем детям мультфильмы с флешки или видео про природу или рыбалку с Ютуба.
Вчера пришла идея - было бы неплохо управлять ютубом с телефона. Нужны включение нового видео и постановка на паузу. Прикинул решение - самым простым показалось использование использование телеграм бота в качестве виндовой службы, управляющей браузером через PowerShell. В можно было бы вспомнить/изучить нативную виндовую часть c# и сделать все по фен-шую, но желания не было от слова совсем. В итоге для отправки в браузер горячих клавиш Ютуба - F (полный экран) и K (пауза) - бот запускает скрипт PowerShell из строковой переменной:)
Какая там разработка банковского ПО или СППВР! Вот - настоящая магия, приносящая удовлетворение: три часа и получившийся мутант запущен в качестве консольного приложения. Осталось спрятать окно так, чтобы не мозолило глаза...
После 6 часов мучений я узнал что надо внимательно читать мануалы. А кроме того, ряд нюансов по написанию виндовых служб на современном c#:
1. Чтобы запускать обычный шарповый серверный проект в качестве службы надо дополнительно ставить пакет. Microsoft.Extensions.Hosting.WindowsServices
2. Фреймворк мне нужен не просто .Net 8, а net8.0-windows и никак иначе!
3. В коде также надо специально указать, что я хочу именно виндовую службу: builder.Services.AddWindowsService.
4. Компилировать надо обязательно в релиз х64.
В итоге я уперся в то, что виндовые службы не имеют доступа к десктопным приложениям, приплыли. Вообще, обходные пути есть - например эмулировать powershell внутри моего приложения и парсить консольный вывод скриптов, но это уже совсем уродство.
В итоге пришлось запускать бота внутри пустой формочки WinForms, умеющей сворачиваться в системный трей (иконку там, где язык и часы). Код выложил на гитхаб.
P.S. До чего же я рад, что Microsoft прикопали серверную разработку под винду и что я не имею ничего общего с десктоп разработкой!
Вообще, для пишущих хранимые процедуры на не-SQL, есть отдельный котел в аду.
Но новость очень приятная.
Продолжая тему модульных тестов в c#. Вляпался в занятную ситуацию с Autofixture. Строки и числа Autofixture заполняет случайными значениями, меняющимися от запуска тестов к запуску. А вот тот момент, что значения булевых полей меняются по другим законам я как-то упустил.
Удаляю я неиспользуемое поле в одном из классов, экземпляры которых я создаю с помощью Autofixture - и тут у меня перестает проходить несколько тестов, при том покрывающих вообще случайные места в проекте. А переименование поля (неиспользуемого) такого эффекта не оказывает.
Первое на что я подумал - что-то где-то закешировалось у меня на компе и тесты заглючили, так иногда бывает. Следующий час прошел в попытках провести экзорцизм над проектом. Не помогло, зато я выяснил что проблема воспроизводится и в пайплайне CI/CD на серверах. Приплыли.
В итоге, оказалось, что генерируемые с помощью Autofixture значения булевых полей не меняются от запуска к запуску тестов, но являются функцией от набора полей в классе. Убрали или добавили поле - значения поехали.
А ошибки полезли из-за того, что я их допустил при написании тестов. Сочетание сгенерированных булевых флагов делало их незаметными, но минус на минус перестал давать плюс и тайное стало явным.
#csharp
#tests
При работе над проектом #sphagnum у меня возникают довольно большие паузы, иногда по нескольку недель. В итоге, когда возвращаешься к проекту, зачастую тратишь несколько часов на то, чтобы вспомнить, а что ты делал раньше и на чем вообще остановился.
Так возникла идея сделать себе доску и начинать весело двигать таски. Сначала я посмотрел на Asana, на одном из мест работы была она и в целом оставила приятные впечатления. В бесплатной версии мне не хватило интеграции с гитом, чтобы без проблем линковать коммиты к задачам.
Затем я подумал о Гитлабе. Весь нужный функционал есть, но вспомнил, сколько мороки с администрированием и настройкой и расхотел.
Зашёл на гитхаб - ux не очень. Быстро (в течение 2 минут) сделать минималистичный канбан в проекте не удалось.
Тогда я решил причаститься Gitea. Доска конкретного репозитория создалась за минуту, коммиты прилинковались, чек листы в задачах удобные. Зеркалирование на гитхаб настроилось мгновенно.
В целом, для работы в одного разработчика (или в маленькой команде) - отличное минималистичное решение, не перегруженное рюшечками, с интерфейсом, интуитивно понятным засыпающему разработчику.
#gitea
#cicd
#devops
Продолжаю конспект интересных вещей, услышанных на обучении постгресу. Начало выше.
4. Механизм шардирования постгреса на партицированную таблицу, партиции которой - foreign table на других инстансах постгреса - нормальная практика, применяется, например, в Авито.
5. Постгресовский varchar от типа text под капотом отличается только наличием проверки на размер, потому если проверка на размер не нужна - просто используем text.
6. Для полнотекстового поиска я раньше использовал индекс Gin. Теперь я узнал, что можно настроить задержку на его дополнение при вставке данных, чтобы не задерживать пишущего.
7. Есть крайне полезное расширение для диагностики таблиц и индексов: pgstattuple. Ставишь его, делаешь select * from pgstatindex('my_index') и тебе выдаётся статистика, насколько разреженный индекс. И по этой статистике принимаешь обоснованное решение, пора ли индекс перестраивать.
8. Вместо limit + offset для пагинации возвращаемых результатов лучше использовать fetch: он гибче.
#postgresql
Подумал тут - насколько шикарный инструмент для сбора крайне интересных данных сайты типа https://jsonformatter.org и https://jsoncompare.org. Представляете - разработчик/тестировщик в недрах большой корпорации возится в json-е, возвращаемом каким-нибудь сервисом для запуска ядерных ракет для обработки персональных данных. А json здоровый и нечитаемый. Что-то не сходится, надо сравнивать, ну он и запуливает json на форматирование/сравнение.
Как по мне, одно из первых правил информационной безопасности - из внутренней сети этих сайтов быть не должно видно вообще.
Познакомился с занятным инструментом: Approval тестами. Понятно, зачем нужны юнит тесты: фиксировать работоспособное состояние бизнес логики. Понятно, зачем нужны интеграционные тесты: фиксировать работоспособное состояние нескольких компонентов системы.
А тут появляется ещё один достаточно удобный рубеж обороны от багов. Approval тест фиксирует состояние Api. Если каким-то образом были внесены любые изменения, меняющие контракт - тест будет заваливаться, пока изменения не будут в явном виде внесены в специальный файл и закоммичены.
То есть при коммите мы в явном виде подтверждаем, что намеренно внесли изменения в контракт. А заодно имеем четкую историю того, кто и когда менял контракты и к кому в случае необходимости нужно применять устройство с картинки.
А если уверен в неуспехе, но ковыряться надо - можно пробовать любую дичь в рамках УК, хуже не будет:)
Читать полностью…
Игра победителя
Давайте сегодня чуть-чуть отвлечемся от процессов, ИТ и всякого. Я вот люблю игры, особенно МОВА, особенно доту. Играю я редко, но постоянно замечаю нюанс: все члены моей команды пытаются победить... И из-за этого проигрывают. Да-да, именно так: люди проигрывают, потому что стараются выиграть. Я не сошел с ума: дайте мне буквально пару минут, и я все объясню.
Ученый Саймон Рамо проанализировал тысячи теннисных матчей игроков всех уровней, от начинающих до звезд. Саймон старался понять, почему одни игроки побеждают чаще других.
Открытие его поразило. Оказалось, что новички и любители играют в принципиально другой теннис. Если в профессиональном теннисе побеждает игрок, который забил больше мячей, то в играх классом ниже побеждает тот, кто меньше пропустил. Саймон пошел еще дальше и свел все к выводу: "В профессиональном теннисе 80% игр выигрываются, а в любительском те же 80% проигрываются."
Игрой победителя Саймон назвал те матчи, где исход решил игрок, который забил больше мячей. Матчи, где победителем стал тот, кто меньше пропустил, Саймон назвал игрой проигравшего.
И под конец еще один парадокс: чем больше любитель старается победить, тем больше он фокусируется на победных действиях и тем больше любительских ошибок допускает, ведь его внимание заключено в победных действиях. Если бы вместо этого он старался бы избегать ошибок, шансов победить у него бы прибавилось.
Аналогий с работой избежать не получится. Я часто вижу, как начинающие тимлиды, проджекты и продакты пытаются сыграть в игру победителя: отойти от лучших практик, закостылить свой фреймворк, срезать углы, которые лучше не срезать... Иными словами, я вижу, как игроки-любители играют в игру победителя и совершают ошибки, из-за чего срывают себе проекты.
В доте и любых онлайн играх все то же самое. Если вы не профи и не тратите 8 часов в день на теннис или доту, предпочтите игру проигравшего и минимизируйте количество ошибок. Так вы начнете побеждать чаще.
Если интересно прочитать подробнее, вот книга Саймона
Совершенно ни к селу ни к городу вспомнил одну особенность RabbitMQ, просто запишу здесь чтобы не забыть.
Получая сообщения из RabbitMQ получатель должен подтвердить получение - ack (получено успешно) или nack (получено, но что-то пошло не так, можно указать, акутально ли еще сообщение). Но велик соблазн запустить какой-то процесс и сообщить кролику ack или nack уже по результатам его завершения.
Пока идёт отладка - всё прекрасно. А стоит поддать нагрузки так, чтобы в неопределенном статусе оказались 50+++ сообщений - начинаются чудеса. Кролика начинает колбасить, лучшего определения тут не подберешь, например сообщение отданное в кролик может дойти до адресата. А может - не дойти:)
Нормального пути решения проблемы я не нашёл, помогало удаление очереди. Ну и профилактика.
#rabbitmq
Некоторое время поэкспериментировал с Avalonia.UI, первые впечатления.
По сравнению с React.js, на котором начинаешь писать не приходя в сознание, прям тяжко. По ощущениям, тут нужно сначала продумать что делаешь, спроектировать все основные окна и переходы, а потом садиться кодить. Без этого получается какая-то фигня прям сразу.
Отработал основные моменты будущего приложения - переходы между экранами, обработка свайпа на экране смартфона (пришлось пилить самому обработку событий движения, нажатия и отпускания экрана, 5 часов в первый раз), обновление содержимого интерфейсов. Следующим этапом будет уже реализация альфа-версии приложения.
По логике работы все достаточно сильно напоминает React.js: отдельно разметка и стили, отдельно - логика и контент.
Отдельно вызывает восторг то, что у бэкенда и фронта по-настоящему единая кодовая база, что открывает огромные возможности для разработки толстых клиентов - переноса логики с бэка на клиентское устройство.
В общем, для шарписта AvaloniaUI прям обязательный инструмент: возможность сделать mvp сразу для всех платформ - браузер, десктоп Линукс, Мак, Винда, мобильное приложение Андроид и iOS одним махом явно стоит того, чтобы немного помучаться на старте врубаясь в непривычную парадигму.
Некоторое время назад я познакомился с отличным образцом импортозамещения: проектом для быстрой генерации отчётов - FastReports. Свой род они ведут из древних тёмных времен, когда Delphi был мейнстримным языком.
Идея отличная: нужен какой-то красивый отчёт? Аналитик рисует макет в редакторе, пишет sql запрос, получает красивую страничку с возможностью выгрузки в pdf.
А вот реализация немного подкачала, поделюсь некоторыми впечатлениями:
С MS SQL работа идёт из коробки. А чтобы подключиться к постгресу - надо подключить расширение. Для этого вы можете собрать нужную dll-ку воооот из этих исходников, которые доложили в ProgramFiles при установке. Исходники на c#. Что характерно, в руках у меня, шарписта, они что-то не билдятся. В итоге пришлось чуть-чуть подправить их. А так - FastReports - инструмент, который можно дать в руки аналитику, чтобы он просто шлёпал отчётики, да.
В свое время я огорчался с документации для Tarantool-а. Но она оказывается неплоха. В FastReports документация изобилует неработающими примерами кода, частенько в одну кучу замешиваются примеры для разных поколений шарповой экосистемы. Для полноты счастья документация сегментирована, Гуглом не индексируется, внутренней навигации тоже нет. Когда я жаловался на жизнь дедам старшим товарищам, я получил такой комментарий:
Стабильность - признак мастерства. Для делфи в начале 00х их документация была такая же)
Но больше всего меня наверное огорчает то, что запросы к базе выполняются строго синхронно. Потому - или забываем про какие либо нагрузки на сервер отчётов, или пилим вавилонскую башню из костылей.
В общем, на мой взгляд, проект на твёрдую тройку, к нему бы приложить руки - и вышла бы конфетка, но альтернатив в настоящий момент для импортозамещения нет, потому кушоем что есть в том виде в каком оно есть.
P.S. Я бы для репортинга лучше посадил джун+ фронтендера в пару к аналитику клепать отчетики на реакте.
Кстати сегодня день рождения .NET Core (да, тогда он назывался так).
27 июня 2016го года - день релиза .NET Core 1.0 :)
Тут против России внезапно ввёл санкции докер. По утру отвалилась сборка контейнеров, завязанных на DockerHub. Проектов на c# это не коснулось: базовые образы тянутся с сайта Microsoft.
Решений у проблемы несколько:
1. Использовать vpn на сервере для сборок.
2. Использовать свежезапущенный проект хуёкер: https://huecker.io/
3. Закешировать нужные для сборок базовые образы у себя в экосистеме и либо переписать докерфайлы, чтобы они тянули с ваших хранилищ, либо понадеятся на кеширование самого докера.
UPD. Я бы пока не стал пользоваться хуёкером, ибо все мы помним SDEK. А вот зеркалом Гугла (mirror.gcr.io)- вполне.
Чуть более десятка полезных запросов для Postgres собрал и оформил с примерами. Для одного поста в телегу - это слишком много (особенно с разметкой примеров вывода). Так что положил в виде gist на github:
🔸Текущие выполняемые запросы
🔸Запросы, выполняемые более 1 секунды
🔸Таблицы с % попадания в кэш при их использовании
🔸Размеры таблиц (включая индексы)
🔸Размеры индексов
🔸Размер текущей БД
🔸Размеры и наличие временных файлов
🔸Статистика по чтению индексов
🔸Статистика использования индексов
🔸Топ 5 самых активных таблиц
🔸Топ 5 самых активных индексов
🔸Никогда не использованные индексы
#postgres
Если используете десктопный клиент телеги на Винде - обновитесь - там феерическая дыра обнаружилась. Для браузера/линуха не актуально.
Коллеги проверили - работает.
pl/dotnet
Для PostgreSQL появилась поддержка C# и F# как языков процедур.
Внутри используется модифицированная библиотека Npgsql, в которой сетевые вызовы заменены на прямые вызовы функций бд. Это позволяет писать в хранимых процедурах такой же код, как при работе с базой через библиотеку, с привычными Npgsql типами.CREATE OR REPLACE FUNCTION dynamic_record_generator_srf(lim INT8)
RETURNS SETOF record
AS $$
upperLimit = lim.HasValue ? lim : System.Int32.MaxValue;
for(long i=0;i<upperLimit;i++){ yield return new object?[] { i, $"Number is {i}" }; }
$$ LANGUAGE plcsharp;
CREATE OR REPLACE FUNCTION dynamic_record_generator_srf_fsharp(lim INT8)
RETURNS SETOF record
AS $$
let upperLimit = Option.defaultValue (int64 System.Int32.MaxValue) lim
seq { for i in 0L .. upperLimit - 1L do yield [| box i; $"Number is {i}" |] }
$$ LANGUAGE plfsharp;
https://www.postgresql.org/about/news/announcing-pldotnet-version-099-beta-2838/
https://github.com/Brick-Abode/pldotnet/wiki/pldotnet:-White-Paper
А о релизе интеграции я узнал из канала @vchirikov
@epeshkblog | Поддержать канал
Освоил девопсячий минимум на базе Gitea. В целом - тот же gitlab, но без понтов и ощутимо проще.
Поставил раннер на сервер (скачав бинарник с официального сайта, в apt не завезли), зарегистрировал его. Вариант с установкой раннера в докере мне прям не понравился: требуется задать кучу переменных окружения, а чтобы понять зачем они все - надо включать мозг и читать документацию, чего не хочется.
Вставляем кусок yml скрипта из примера в папку для ci cd скриптов - управление командной строкой работает. Если гитлаб раннер может выполняться миллионом разных способов: и в докере, и в командной строке самой машины и ещё хрен знает как, тот у act_runner-а - раннера gitea - вариант один - в докер контейнере с node.js.
Хранилище докер образов (и прочего мусора прочих артефактов, типа нугет пакетов) работает из коробки. Единственное, чтобы образы прикрепились к репозиторию, а не лежали в общей куче, надо вручную линкануть их через ui. Наверняка можно и через командную строку. Настроек автоочищения хранилища я не нашел.
В общем, отличное решение для микрокоманд. Но человек на 5 и более, работающих над одним проектом я бы уже ставил гитлаб.
#gitea
#devops
Познал дзен написания автотестов в c#. Тесты я пишу уже довольно давно и помногу, но во основном функциональные/интеграционные, закрывающие функционал проекта в целом. При этом зависел я обычно только от объектов инфраструктуры: баз данных, брокеров сообщений и т.д. Модульные тесты тоже писал, но только на места с неочевидной сложной логикой, которая не помещается в голове.
Перенесемся в мир кровавого энтерпрайза. Представим ситуацию, когда наш сервис ходит по сети более чем в 10 других микросервисов. Куда ходят эти 10 микросервисов чтобы собрать информацию - представить страшно.
Поднимать все это добро каждый раз, когда приспичит проверить бизнес логику - не очень удобно даже в светлую эпоху контейнеризации. Тут на помощь нам приходят моки: обносим источник данных интерфейсом, а дальше в тестах в тестируемый класс с бизнес логикой подсовываем фейковую реализацию интерфейса.
До недавнего времени я пилил эту реализацию сам, но тут проникся двумя инструментами - NSubstitute и Autofixture. Первый позволяет создавать фейковые реализации, второй - инициализировать инстансы классов для возвратов с заполненными полями.
У NSubstitute понравилась возможность легко задавать конкретные кейсы из пар запрос - ответ, очень удобно и никакой логики внутри фейка самому писать (и потом поддерживать) не надо.
Autofixture мне не казалось чем-то нужным, до тех пор, пока мне не пришлось тестировать проброс информации из глубинных слоев наверх, с возвращаемой моделью (в сумме с вложенными классами) в пару тысяч строк. Говоришь: мне нужен объект, поля id, name, userid должны иметь заданные значения. Остальные - заполнятся по усмотрению библиотеки чем-то не-дефолтным. Раз - и объект для теста готов, без бесконечной лапши с инициализацией полей руками.
#csharp
#tests