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 | Поддержать канал

Вообще, для пишущих хранимые процедуры на не-SQL, есть отдельный котел в аду.

Но новость очень приятная.

#postgresql
#csharp

Если используете десктопный клиент телеги на Винде - обновитесь - там феерическая дыра обнаружилась. Для браузера/линуха не актуально.

Коллеги проверили - работает.

У нас нет телевизора в общепринятом смысле: с каналами и антенной. Есть мини компьютер с виндой, к которому подключен настенный экран. С него мы включаем детям мультфильмы с флешки или видео про природу или рыбалку с Ютуба.

Вчера пришла идея - было бы неплохо управлять ютубом с телефона. Нужны включение нового видео и постановка на паузу. Прикинул решение - самым простым показалось использование использование телеграм бота в качестве виндовой службы, управляющей браузером через 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 прикопали серверную разработку под винду и что я не имею ничего общего с десктоп разработкой!

#проекты

Чуть более десятка полезных запросов для Postgres собрал и оформил с примерами. Для одного поста в телегу - это слишком много (особенно с разметкой примеров вывода). Так что положил в виде gist на github:
🔸Текущие выполняемые запросы
🔸Запросы, выполняемые более 1 секунды
🔸Таблицы с % попадания в кэш при их использовании
🔸Размеры таблиц (включая индексы)
🔸Размеры индексов
🔸Размер текущей БД
🔸Размеры и наличие временных файлов
🔸Статистика по чтению индексов
🔸Статистика использования индексов
🔸Топ 5 самых активных таблиц
🔸Топ 5 самых активных индексов
🔸Никогда не использованные индексы
#postgres

Познакомился на практике с двумя шарповыми фреймворками для веб разработки: Razor Pages и Blazor. Оба позволяют писать фронтенд без js-a, на смеси c# и особого диалекта html.

Razor реализует паттерн MVC. Логика работы фреймворка примерно такая: поднимается сервер, который по согласованному множеству ссылок отдает в браузер html страницы по http.

Blazor несколько сложнее. Логика описывается на c#, после чего в браузер отдается нечто, висящее на веб сокете (SignalR) с бэком. Бэк отсылает обновления и реакции на действия юзеров, они отрисовываются. Такой черный магический ящик. Вообще, есть вариант Blazor-а, отдающий в браузер клиент на WebAssembly, но я не тыкал его пока.

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

#front

Тут против России внезапно ввёл санкции докер. По утру отвалилась сборка контейнеров, завязанных на DockerHub. Проектов на c# это не коснулось: базовые образы тянутся с сайта Microsoft.

Решений у проблемы несколько:
1. Использовать vpn на сервере для сборок.
2. Использовать свежезапущенный проект хуёкер: https://huecker.io/
3. Закешировать нужные для сборок базовые образы у себя в экосистеме и либо переписать докерфайлы, чтобы они тянули с ваших хранилищ, либо понадеятся на кеширование самого докера.

UPD. Я бы пока не стал пользоваться хуёкером, ибо все мы помним SDEK. А вот зеркалом Гугла (mirror.gcr.io)- вполне.

Некоторое время назад потыкал питоновские фреймворки на предмет быстрого создания веб апи. Мои требования:
1. Сваггер с описаниями методов и полей.
2. Типизированные модели, чтобы всякий мусор присылаемых извне отваливался на этапе десериализации.
3. Упаковка проекта в докер, желательно из коробки.

Этот набор требований - то что в c# даётся из коробки в шаблоне проекта.

Сначала я попробовал по старой памяти потыкать Flask. Читаю про сваггер. Можно подключить его десятком разных способов, в некоторых случаях мне предлагают прицепить yml описание методов.

Посмотрел в Django. Оказывается все не так плохо как несколько лет назад: туда завезли асинхронщину, не прошло и 10 лет. Сваггер описывается вроде нормально. Но тащить весь джанговский зверинец вместе с MVC для легковесной апишки мне запрещают религиозные убеждения. Плюс Django надо отдельно изучать, шарповый опыт не особо помогает понимать происходящее.

Попробовал новую для меня библиотеку - FastApi. Она вошла в употребление уже после того, как я полностью ушел от питона и она меня приятно удивила: все мои требования были удовлетворены в течении часа.

Все бы ничего, но возник вопрос: а питон - это точно про сделать что-то без боли и мучений?

#python

Кстати сегодня день рождения .NET Core (да, тогда он назывался так).
27 июня 2016го года - день релиза .NET Core 1.0 :)

Продолжил читать Рихтера, дошел до делегатов. Делегат - это тип, описывающий метод: входящие и выходящие параметры. Можно например сделать метод, принимающий на вход делегат и вызывающий его внутри. И таким образом по ситуации подменять вызываемый метод. В общем штука банальная, иметь такое мне захотелось ~на третий месяц программирования на c#.

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

Метод из цепочки также можно удалить вызвав -= метод.

#csharp
#Рихтер
#книги

Некоторое время назад я познакомился с отличным образцом импортозамещения: проектом для быстрой генерации отчётов - FastReports. Свой род они ведут из древних тёмных времен, когда Delphi был мейнстримным языком.

Идея отличная: нужен какой-то красивый отчёт? Аналитик рисует макет в редакторе, пишет sql запрос, получает красивую страничку с возможностью выгрузки в pdf.

А вот реализация немного подкачала, поделюсь некоторыми впечатлениями:

С MS SQL работа идёт из коробки. А чтобы подключиться к постгресу - надо подключить расширение. Для этого вы можете собрать нужную dll-ку воооот из этих исходников, которые доложили в ProgramFiles при установке. Исходники на c#. Что характерно, в руках у меня, шарписта, они что-то не билдятся. В итоге пришлось чуть-чуть подправить их. А так - FastReports - инструмент, который можно дать в руки аналитику, чтобы он просто шлёпал отчётики, да.

В свое время я огорчался с документации для Tarantool-а. Но она оказывается неплоха. В FastReports документация изобилует неработающими примерами кода, частенько в одну кучу замешиваются примеры для разных поколений шарповой экосистемы. Для полноты счастья документация сегментирована, Гуглом не индексируется, внутренней навигации тоже нет. Когда я жаловался на жизнь дедам старшим товарищам, я получил такой комментарий:
Стабильность - признак мастерства. Для делфи в начале 00х их документация была такая же)

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

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

P.S. Я бы для репортинга лучше посадил джун+ фронтендера в пару к аналитику клепать отчетики на реакте.

#fastreports

Каталог настолок. Часть 1. Начало.

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

Дальнейшие сообщения по проекту будут под тегом #bgcatalog@eshu_coding

Путем наименьшего сопротивления было бы сваять браузер на React.js, а приложение - на том же реакте, или на котлине. Но я решил попробовать нестандартный путь - шарповый фреймворк Avalonia.UI. Он заявляется как тру кросс-платформенный: единая кодовая база для web, desktop, android и ios.

Пока я потратил часов 7 на утрамбовку браузерной авалонии в докер. Работающих примеров утрамбовки Avalonia в докер я так и не нашёл, пришлось собирать что-то по мотивам обсуждения в сообществе авалонии. Логика примерно такая: подсунуть результаты билда шарпового проекта в WASM в папку для раздачи статического контенда nginx. Пример докерфайла в репозитории. Для запуска надо стартовать docker-compose-avalonia.yml в корне решения.

#avalonia
#front
#проекты

Каталог настолок. Часть 2. Эксперименты для разработки фронта.

Некоторое время поэкспериментировал с Avalonia.UI, первые впечатления.

По сравнению с React.js, на котором начинаешь писать не приходя в сознание, прям тяжко. По ощущениям, тут нужно сначала продумать что делаешь, спроектировать все основные окна и переходы, а потом садиться кодить. Без этого получается какая-то фигня прям сразу.

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

По логике работы все достаточно сильно напоминает React.js: отдельно разметка и стили, отдельно - логика и контент.

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

В общем, для шарписта AvaloniaUI прям обязательный инструмент: возможность сделать mvp сразу для всех платформ - браузер, десктоп Линукс, Мак, Винда, мобильное приложение Андроид и iOS одним махом явно стоит того, чтобы немного помучаться на старте врубаясь в непривычную парадигму.

#avalonia
#bgcatalog@eshu_coding

Каталог настолок. Часть 3. Построение инфраструктуры.

Начал строить инфраструктуру для проекта домашнего каталога настолок (и частично для других будущих проектов).

Базовую площадку - 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 сервера вместо одного.

#bgcatalog@eshu_coding

Совершенно ни к селу ни к городу вспомнил одну особенность RabbitMQ, просто запишу здесь чтобы не забыть.

Получая сообщения из RabbitMQ получатель должен подтвердить получение - ack (получено успешно) или nack (получено, но что-то пошло не так, можно указать, акутально ли еще сообщение). Но велик соблазн запустить какой-то процесс и сообщить кролику ack или nack уже по результатам его завершения.

Пока идёт отладка - всё прекрасно. А стоит поддать нагрузки так, чтобы в неопределенном статусе оказались 50+++ сообщений - начинаются чудеса. Кролика начинает колбасить, лучшего определения тут не подберешь, например сообщение отданное в кролик может дойти до адресата. А может - не дойти:)

Нормального пути решения проблемы я не нашёл, помогало удаление очереди. Ну и профилактика.

#rabbitmq

К своему стыду не осознавал применительно к работе и играм сего подхода: если уверен в успехе - не выпендривайся:

Игра победителя
Давайте сегодня чуть-чуть отвлечемся от процессов, ИТ и всякого. Я вот люблю игры, особенно МОВА, особенно доту. Играю я редко, но постоянно замечаю нюанс: все члены моей команды пытаются победить... И из-за этого проигрывают. Да-да, именно так: люди проигрывают, потому что стараются выиграть. Я не сошел с ума: дайте мне буквально пару минут, и я все объясню.

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

Открытие его поразило. Оказалось, что новички и любители играют в принципиально другой теннис. Если в профессиональном теннисе побеждает игрок, который забил больше мячей, то в играх классом ниже побеждает тот, кто меньше пропустил. Саймон пошел еще дальше и свел все к выводу: "В профессиональном теннисе 80% игр выигрываются, а в любительском те же 80% проигрываются."

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

И под конец еще один парадокс: чем больше любитель старается победить, тем больше он фокусируется на победных действиях и тем больше любительских ошибок допускает, ведь его внимание заключено в победных действиях. Если бы вместо этого он старался бы избегать ошибок, шансов победить у него бы прибавилось.

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

В доте и любых онлайн играх все то же самое. Если вы не профи и не тратите 8 часов в день на теннис или доту, предпочтите игру проигравшего и минимизируйте количество ошибок. Так вы начнете побеждать чаще.

Если интересно прочитать подробнее, вот книга Саймона

А если уверен в неуспехе, но ковыряться надо - можно пробовать любую дичь в рамках УК, хуже не будет:)

Я стараюсь не рекламировать пиратство в паблике, но текущая ситуация - это просто идеальный пример bus factor 1.

https://flibusta.site/node/681117

TLDR. Флибуста походу всё. Единственный ментейнер сейчас в больнице с раком мозга, а хостинг оплачен только на пару недель. А что будет потом - неизвестно. Очередной проект, который определил дух эпохи, лично для меня, скоро канет в лету.