leopard

github.com/le0pard/json_m… JsonMend is a robust Ruby gem designed to repair broken or malformed JSON strings. It is specifically optimized to handle common errors found in JSON generated by Large Language Models (LLMs), such as missing quotes, trailing commas, etc #ruby #rails #json

@Danko007 @pik_cah4e3?si=tM6pcKWWDC9qhCNu" target="_blank" rel="nofollow noopener">youtube.com/@pik_cah4e3?si… - цікаво, що ж я оді слухаю тут ...

Хотів почитати другу книгу Silo, але, як з'ясувалося, українського перекладу ще немає. Знайшов собі російській... Знаєте як вони наш "Бункер" переклали? "Укрытие"... повбивав би. Видалив нафіг...

@AndriyVandych @YouSysAdmin @jeanosis_ef Ну якщо копати вже так глибоко, то баланси буде зберігатися як подвійний запис - це не одне число, а похідне від усіх операцій + снепшот/зріз операцій. В кожній транзакції може бути балансуючи й запис, куди і потрапить округлення, щоб наприклад транзакція була математично закрита

@leopard_me @YouSysAdmin @jeanosis_ef Якщо ви зберігаєте свій баланс як децімал, при операціях децімал сам буде округлювати його до експоненти яку ви використовуєте. Це округлення буде накопичуватися на всіх операціях які ви з балансом будете робити.

Читаю посібник (не офф) по расту, з старту у лице кидають приклад. От чого в прикладах, вічно юзають флоат для грошей? "Beginner-Friendly Example with Variables" назва приклада, цього не виправдовує :)

@AndriyVandych @YouSysAdmin @jeanosis_ef Не буде ніякого дрифту, якщо робити округлення тільки в кінці операцій. Тобто використовуємо "Keep it Raw" для зберігання данних (цей самий тип decimal у базах) і "Round Half to Even" для кінцевих результатів

Ви знущаєтесь? Відрізання і заокруглення підкапотне і є дрифтом, це і є проблемою. Ви втрачаєте детерміністичність коли одна операція поповнення на 30 центів збільшує баланс на 14,01 гривні, а інша на 14,02 при тих самих рейтах. А акаунтінг системах з «гарячими» леджерами той дрифт стає сильно помітним.

@AndriyVandych @YouSysAdmin @jeanosis_ef Фінансові системи зазвичай використовують від 4 до 8 знаків після коми, бо заокруглення до двох знаків веде до "rounding error". Курси валют, податки, складні відсотки та подібне з передчасним заокруглення призведе до того, що підсумковий баланс не зійдеться

@leopard_me @YouSysAdmin @jeanosis_ef І я чесно не зрозумів що значить «зберігати більше знаків бо конвертації», рейти звісно можуть самі по собі мати більше знаків, але це не значить що сума після конвертації має

@AndriyVandych @YouSysAdmin @jeanosis_ef З мінусів роботи з decimal типу - він буде повільніший ніж інші, тобто операції будуть їсти більше cpu і займає багато місця (16 байт)

@leopard_me @YouSysAdmin @jeanosis_ef Все ж краще зберігати в чистому лонгу, особливо якщо це система мультивалютна. Якщо треба то калькуляція в децімал тоді заокруглення і в лонг. В децімала є rounding drift, звісно це не флоат, але на великих кількостях операцій він накопичується.

@YouSysAdmin @jeanosis_ef Decimal. Бо в копійках працює поки виявиться, що треба сумами зберігати з 6 чи 8 знаків (наприклад конвертації валют потребують більше, ніж 2 знаки після)

@jeanosis_ef Чистий int - в копійках

@ygnatyuk_ Глянув - краще вже гуглова книга - більш повна і покриває навіть тюнінг параметрів і інші аспекти, такі як structured output

OpenAI виклали офіційний гайд з промптингу для GPT-5.2. Практичний документ з готовими прикладами, порадами для точнішої взаємодії та реальними use-case: cookbook.openai.com/examples/gpt-5… - приклади готових промптів; - гайди для найефективнішою взаємодії з моделлю; - сценарії використання з практичними порадами та інсайтами.

@ygnatyuk_ Google давно має по цьому книгу (хоча скоріше гайд на 68 сторінок) - kaggle.com/whitepaper-pro…

@ChShersh Parquet, avro, apache iceberg, etc

Here’s a real task from my job. I have a 100GB binary file. Produced daily. I can’t grep it. But I can decode it. However, I can’t store the decoded version either. It’s too big. How do I efficiently query it? Decoding piped to grep takes 2 minutes. I want 2 seconds.

@DoberGroup @YouSysAdmin Чим Вас не влаштовує bcrypt?

@YouSysAdmin Для початку, я не хочу бачити bcrypt в банківському секторі вже 10 років. Враховуючи ланцюг з BankID - тим більше. По-друге, так, блядь, скидувати - ви їх за цей строк двічи втратили і двічи змінювали бек шматками

Є ще 4 пункт. Архітектор/CISO - вигадав ці правила тому, що він митець, він так бачить. І от я навіть не знаю, що мене більше лякає

@YouSysAdmin @privatbankua "змушують усіх поміняти" - от тут як і кажу часто вибирають "костиль" (не дозволяти довгі паролі), бо "ще подумають що ми щось робили не сек'юрно після цих листів" ))))

@leopard_me @privatbankua Ну роблять нову локонку у базі "normal_password" й змушуються всіх поміняти, видаляють колонку "fignya_yakas" :D

@privatbankua wif? Я розумію оюмеження мінімальної довжини, але обмеження максимальної та ще й набору спецсимволів... це викликає питання.

@YouSysAdmin @privatbankua Я ж кажу - може sha256 чи подібне не роблять, а зразу в bcrypt (чи в подібне). А потім розробники ознайомлюються з документацією бібліотеки і такі "упс, ну не будемо ж ми скидувати всі паролі (бо треба міняти метод хешування) - просто обмежимо довжину ))))"

@leopard_me @privatbankua Ну от тому я не розумію фінта ПБ з паролем, щоб що як то кажуть, хоча я за passwordless взагалі але мене меньшість :)

@YouSysAdmin @privatbankua Дуже правильно. У вас пароль спочатку проходить sha256, тобто на будь якої довжини - хеш 64 байти, що безпечно для bcrypt (не буде проблем з 72 max). Обмеження треба щоб хеш для величезної строки довго не рахувався. Salt дає bcrypt, його буде видно використання в compare функції

@leopard_me @privatbankua Пішов заскринив те що юзаю у своєму проекті, обмеження у модельці у макс 100 символів, просто щоб ніхто не думав думав мегабайт залити, а так вводи що хоч :)

@YouSysAdmin @privatbankua Те що ви описали просто deterministic salt generation (наприклад на основі введеного паролю), що в деяких хеш алгоритмах прямо заборонено (. Сіль це чисто боротьба з однаковим хешом на однаковий контент, щоб не було атак по словнику. Більше він ні для чого не потрібен

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

@YouSysAdmin @privatbankua Може буде виправдано, тому що злиту базу не перебереш через rainbow tables. Але це не відміняє проблем що база злита і треба всім міняти пароль. Це як пароль на ssh key - такий злитий ключ просто дає фору в часі в його заміні, це не відміняє що з його використанням покінчено

@leopard_me @privatbankua Я про статичну соль яку вічно люблять пихати деякі розробники, типу такого. При чому деякі ту соль роблять статичною в конфігу а деякі рандомно але зберігають у туж саму базу прям в юзера окремою колонкою

@YouSysAdmin @privatbankua У bcrypt вбудована сіль (salt), це треба щоб для однакових паролей хеш не збігався, інакше простіше тобі в злитій базі знаючи пароль одного акаунта знати що цей самий пароль і в інших акаунтах, де такий самий хеш

@leopard_me @privatbankua Сама по собі ідея солі то хрінь. :)