Я хто який HTTP метод використовує, коли стан системи змінювати не треба, але потрібно передати BODY запиту?

У GET body тулити якось не прийнято.

Є баги, що повторюються від продукту до продукту.
Іноді це зумовлено тим що в різних продуктах використовуються одні й ті самі базові технології і цим можна пояснити однаковий баг в різних продуктах.

Іноді є баги, що не залежать від технології: вони повторюються в різних продуктах на різних технологіях. Зазвичай причина їх появи доволі фундаментальна. Часто зрозуміла.

І є от такий баг: майже в усіх плеєрах потокового відео неможливо поставити на паузу, якщо під час відтворення почалась підвантаження(частіше за все ми бачимо "крутілку").
Я би зрозумів якби в цей час був фріз воно UI, але ні: ми навчились виносити IO так щоб він не впливав на UI.
Може там і є щось умовно фундаментальне, але я не розумію, чому не покласти в якусь чергу подій повідомлення про те, що треба поставити плеєр на паузу як тільки дованиажиться наступний кадр/секунда перед тим як його/її відтворювати. Чому так не зроблено і чому ця проблема виникає на мобільних пристроях, в браузерах на натуральних комп'ютерах і на телевізорах мені не зрозуміло.

В когось є відповідь чи хоча б думки?

ref struct - Що це таке і що змінилось у C# 13

В цьому стрімі згадав про ref struct і казав, що він змінився.
Написав невеличку статтю про те що це таке, навіщо треба і як змінилось.

Опублікував його в тому, що колись стане моїм блогом(є одна ідея як це гарно зробити), але поки це просто пара веб-сторінок, що аж ніяк не псує задоволення від перегляду конкретної статті.

https://blog.podkolzin.consulting/#/article/2024-12-12.ref-struct-CSharp13-and-before

Колись дуже давно, ще в 17му році писав статтю де порівнював SQLite з іншою базою (її теж переніс у свій майбтній блог).

Зараз довелось дуже змістовно і багато попрацювати з SQLite, збудувати навколо цієї бази доволі великий продукт, тож захотілось поділитись досвідом.

Буде цікаво і тим, хто ніколи не працював з цією базою і не планує, просто для розуміння а чим так хороші ті СУБД, що працюють мережею.

https://blog.podkolzin.consulting/#/article/2024-11-26.SQLite-Expirience-Short-Article

Доповнив свою статтю про ref struct чудовим коментарем від Дмитра. Раджу ознайомитись.

Єдине доповнення від мене:
List<string> і List<JObject> будуть мати посилання на одні й ті самі тела методів від чарівного List<__Canon> чи якось так, що застосовується для всіх ссилочних типів.

Щодо питання про можливість використання ref struct в якості generic параметру:

Java generics базуються на стиранні типів (type erasure), це означає що наші T існують лише на етапі компіляції, а в рантаймі використовується звичайний object, що в свою чергу має на увазі під собою каст, а для структур ще і боксінг. Ну а як ми зрозуміли зі статті то така операція як розміщення на кучі(боксінг) не вписується в концепцію ref struct.

На відміну від Java, C#: Generics реалізовані через різні версії типів на етапі компіляції та виконання. Це означає, що компілятор створює специфічні реалізації для кожного типу, що використовує generics, з урахуванням їх конкретних параметрів типу. Наприклад, List<int> і List<string> будуть різними типами в пам’яті на етапі виконання.

Таким чином це дає нам можливість уникнути операцій приведення типів в рантаймі ну і звісно використати ref struct у якості generic параметру (звісно з певними обмеженнями).

Для експериментів взяв найдешевший сервачок за 4$: там 512мб оперативної пам'яті і дивуюсь як там працює аж цілий ASP.NET + Nginx + postgres.

А потім згадую, що коли починав займатись розробкою, то в мене і було 512мб оперативної пам'яті: так туди влізла вінда з графічною оболонкою, я міг грати у generals zero hour чи gta vice city, чи програмувати на Visual Studio підіймаючи сайт на ASP в цілому IIS і маючи SqlServer у якості бази даних, ще й бачити результат своєї роботи в браузері.

Яким бісом це все тоді туди влазило, якщо зараз я дивуюсь із кількох процесів без графіки на віддаленому сервері? 🙈🙈🙈

Зрозуміло, що про індекси писали багато. Зрозуміло, що багато чого про них розкаже і ChatGPT, чи аналогічні системи.

Тож чим буде вирізнятись моя стаття?

Вона швидше упорядковує знання про індекси в голові і дозволяє вам швидко навігуватись по ним всередені голови: тобто мати можливість ходити вверх вниз по абстракціям в процесі обдумування проблеми.

https://blog.podkolzin.consulting/article/2024-12-27.base-idea-behind-index

Індекс знань про індекси для вашої голови

P.S. Поширте цю статтю, або будь яку іншу, що знайдете корисною тим, хто може розділити цю думку. Це буде ваш внесок у боротьбу з паршивими статтям і захист статей добрих.

Хто б як вирішував задачу:
В реляційній базі треба зберігати певні сутності.
Вони мають 5-6 спільних властивостей і енам типу.
Типів багато і вони мають 3-30 власних властивостей: іноді якась з них масив, іноді ще один об'єкт за своїми властивостями.

Вигрібати треба потім їх доволі багато (сотні, іноді тисячи, іноді десятки тисяч) і заново будови об'єкти відповідно до ієрархії.

Коротше: подія, тип, аргументи. У кожного типу свої аргументи.

Розвиток best practices в C#:
- Ми кажемо, що треба використовувати string.Empty замість ""

Через 15 років:
- Ми кажемо, що треба використовувати [] замість Array<T>.Empty

Попередня best practice продовжує діяти

Думаю пришло время вернуть канал обратно на русский язык. Документалку переозвучу и снова начну выпускать DevJungles Stories.

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

https://youtu.be/cPqpHgyyHZo

От так треба відноситись і використовувати штучний інтелект, хто не згоден нумо в коменти.

І ще: в чому таки вимірюється кількість софту?

А це завжди так працювало, чи в якийсь момент стало можна?

Інтерфейс IReadOnlySet<T> виглядає як найменш улюблена дитинка в сім'ї дотНет інтерфейсів колекцій.
Було б очікувано, що ISet<T> розширює IReadOnlySet<T>: взяли множину, в котру не можна писати і додали до неї можливість писати.
Але ні, ISet<T> не розширює IReadOnlySet<T>.

IReadOnlySet<T>.Contains(T) - не вміє траслюватись в SQL, на що дякувати, хоч написана інспекція в IDE.

Вчора мігрував великий і складний проект з SQLite на Postgres.
В SQLite сам його вляпав розробив, через набір вимог: щодо можливості як працювати на сервері, так і максимально швидко розгорнути на машині користувача, що буде потім працювати в офлайні.

Проект повністю на .NET (ну майже: з фронтом на Vue і одним сервісом на Node.JS, про котрий колись пізніше), але через брак часу, паттерн репозиторій, чи інші патерни, що абстрагують слой даних від слою бізнес логіки був відкинутий:
- в простих випадках я власноруч інжектив DbContext в обробник MinimalAPI, котрих в цьому файлі налічувалось ще 20+.
- в складніших, або в простих, але потребуючих перевикористання я виділяв сервіси.
- в складніших випадках, що не потребували використання, створював клас, котрому додавав постфікс Feature, котрий і використовував з хендлеру.

Для міграції даних використав pgloader. Дуже задовлений цим інструментом: для нього не склало жодної проблеми міграція таблиць на кількадесят мільйонів рядків. І робив це вражаюче швидко: 0-3 хвилини на базу.
Стало цікаво на чому проект написаний і був приємно здивований, що на LISP. Не тому, що якось нерівно дихаю до нього, хоч і теоретично навіть мав курс по ньому в університеті, з котрим щось не склалось, а тому що люблю реальні корисні впізнавані рішення зроблені впертими чудіками на нішевих технологіях. Мабуть просто притаманна багатьом бажання вболівати за аутсайдерів.

Що огрьоб?
- Мігріція кожної SQLite бази, що жила в окремому DbContext починалась з видалення всіх міграцій (загалом здихався більше ніж 1000 файлів), замини NVARCHAR на VARCHAR і створення нової initial.
- Сама міграція даних бул трохи головняковою, оскільки, і я не знав цього для SQLite немає проблем в колонку з типом NVARCHAR(50) запхати рядок на 70 символів і більше, в той час як Postgres суворий в цьому. Тож підбір типів зайняв певний час. Але Pgloader швидкий, що дозволило мені швидко робити спроби: і тут ідея, що я тягну через весь свій канал - швидкодія може бути важлива, навіть якщо здається що можна і почекати. Швидкодія дозволить відкривати нові сценарії використання програмного забезпечення. Мені дозволило раз за разом локально запускати міграцію даних підбираючи розмірність десятку колонок за раз, без зайвого навантаження на мозок у спробі зробити все за один раз, бо спроба дорога.

- На всі ~70 проектів в солюшені був один запит, написаний руками - його довелось трошки переписати: доставити "" для таблиць і колонок.
- Мав кілька фільтрованих індексів і через особливості їх опису в EF, це теж впало: треба було доставити лапки.

Як я організовував процес міграії:
Я мав один непокірний індекс на еластіку, що не давав мені спокою тим, що іноді час відовіді займав 6-20 секунд замість звичайних 20мс. Швидко розібратись я не міг і мене це дістало, тож я підняв постгрес з їх варіантом повнотекстового пошуку.
Це пропрацювало кілька тижнів.
Дані в індексі не були цінні і могли бути відновленні з інших таблиць автоматично: це був буквально зовнішній індекс над десятком таблиць SQLite.
Коли я задумав перехід, то зрозумів, що буде потрібно підтримати резервне копіювання для postgres. Я відправцював це на цьому індексі з мінімальними ризиками: роблю копію цілого docker volume не спускаючись до рівня інструментів postgres. Перевірив відновлення з бекапу.
Залишив на пару тижнів.
Перевів одну базу шмата функціоналу середньої популярності на postgres: середньої, тому ще мала популярність не переконала б в надійності системи, а популярна могла б бігати в милі і щось виправляти.

Поступово переводив інші бази, розмазуючі ризики в часі і відпрацьовуючи саму механіку процесу.

Висновки:
- pgloader корисний і дуже швидкий інструмент написаний нішевій технології для міграції звідки завгодно на постгрес.
- швидкодія важлива, навіть у тих випадках, коли так не здається: мені б підійшли б і міграції, що виконуються годину, але процес би не пройшов так гладко і можливо я б відмовився від самої ідеї міграції на іншу СУБД

- той рівень абстракції, що дає EF достатньо, щоб без додаткових шарів мати можливість в польоті пересісти з однієї бази на іншу.
(В цьому проекті по суті використовую цю особливість вдруге: бо спершу обрав постгрес, але через певні вимоги до розгортання тоді перейшов на SQLite)

#WrittenInTheJungle #Database #SQLite #Postgres

Не знав чи треба буде перевизначати метод (With) в нащадку, якщо в батьківському класі він працює через with, то чи відпрацює тут поліморфізм...

Як ви очікуєте?

Можете і не вірити, а це нове відео на каналі:
https://youtu.be/klT2axrP6Os?si=JsdFm26yVf_iFHfO

Місяць тому вийшло відео, тож підводжу ітоги конкурсу.
Переможців я назвав і вони знають про це, тож чекаю зв'язку для видачі призів.

А от повна розшиврока відсилок з першої частини відео)

А якщо не бачили, то мерщій дивитись: вгадувати відсидки завжди цікаво.

https://youtu.be/klT2axrP6Os?si=JsdFm26yVf_iFHfO

Чого б ви очікували в теперешню технологічну еру від мого каналу?