Затишна Галера

#iOSКомпас 🧭1️⃣4️⃣8️⃣ Завдання 148Що таке м’ютекс (mutex)?Починаємо мобільну середу! З вами знову той самий автор каналу @badlinkschannel. Сподіваюсь вам ще не набридла ця ідея капітана галери про iOS розробника.🤔 М’ютекс (від англ. «mutex» - mutual exclusion, взаємне виключення) - це механізм синхронізації, який використовується у багатопотоковому програмуванні для запобігання одночасному доступу кількох потоків до спільних ресурсів, таких як змінні, структури даних або файли. Він допомагає уникнути стану гонки (race condition), коли результат виконання програми залежить від невизначеного порядку доступу потоків до ресурсу.🔣 Основні концепції м’ютекса🔣 Взаємне виключенняМ’ютекс забезпечує доступ до спільного ресурсу лише одному потоку в кожен момент часу. Коли один потік захоплює м’ютекс, інші потоки повинні чекати, поки м’ютекс не буде звільнений.🔣 Захоплення і звільненняПотік захоплює м’ютекс перед доступом до спільного ресурсу і звільняє його після завершення роботи з цим ресурсом. Якщо м’ютекс уже захоплений іншим потоком, поточний потік буде заблокований доти, поки м’ютекс не буде звільнений.🤓 Приклад використання м’ютекса в Swiftimport Foundationclass SafeCounter { private var value = 0 private let lock = NSLock() func increment() { lock.lock() value += 1 lock.unlock() } func getValue() -> Int { lock.lock() let currentValue = value lock.unlock() return currentValue }}let counter = SafeCounter()let group = DispatchGroup()for _ in 0..<2 { DispatchQueue.global().async(group: group) { for _ in 0..<1000 { counter.increment() } }}group.wait()print("Final counter value: \(counter.getValue())") 🔣 Плюси і мінуси👍 Безпека данихМ’ютекси захищають спільні ресурси від одночасного доступу, запобігаючи пошкодженню даних.👍 ПередбачуваністьКод стає більш передбачуваним і стабільним, оскільки виключаються стани гонки.😡 Мертві блокування (Deadlocks)Якщо м’ютекси захоплюються у неправильному порядку, це може призвести до ситуації, коли два або більше потоків блокують один одного, очікуючи звільнення м’ютексів.😡 ПродуктивністьНадмірне використання м’ютексів може призвести до зниження продуктивності через збільшення часу очікування потоків.@Zatishna_Galera

GOOGLE І TURBOQUANT - ПОРЯТУНОК ЧИ НІ?Інтернет уже шумить кілька днів з приводу TurboQuant, алгоритму, який, за заявою багатьох авторів, може скоротити в 6 разів використання пам’яті для нейронок і збільшити швидкість у 8 разів, але чи так це?Я не буду вдаватися в подробиці, як це працює технічно дуже глибоко, скажу лише, що головна штука цього алгоритму в тому, що він результат, дуже грубо кажучи, розмазує й округляє для кожної частини вхідних значень, а потім цей «апроксимований результат» з великого обсягу даних видає як кінцевий. І загалом ідея здорова, коли точність вам не важлива.Проблема тільки в тому, що якраз для LLM точність важлива, інакше що ми отримаємо на виході? Правильно - безліч галюцинацій. І хоч алгоритм має право на існування й може зробити свій внесок, ось тільки він був опублікований ще 28 квітня 2025 року, а зараз просто з цього роздули новину. Тобто його вже точно застосовують, якщо він може бути десь корисним, а значить, і так уся можлива на сьогодні економія використана, і це ніяк не вплине на пам’ять.При цьому десяток каналів, тільки в мене в підписках, уже радісно видають цю новину як «прорив». Ну так, прорив, який, по-перше, не завжди допоможе, а по-друге, вже старуватий. Ну лох не мамонт, як то кажуть, підписники таких каналів схавають.А ми з командою наших пасажирів такими не вважаємо, тому читайте перевірені новини й робіть висновки самі.Акції компаній, що виробляють пам’ять, на тлі новини все одно впали на 10-15% (зокрема Samsung і Micron).@Zatishna_Galera

OPENAI ЗАКРИВАЮТЬ SORAПри цьому компанія втрачає $1 млрд, який фігурував у переговорах з Disney. Мабуть, перекидання ресурсів на бізнес-сегмент справді сильно припікає, раз ухвалюються такі кроки.При цьому, буквально днями ми обговорювали з друзями, що Anthropic дедалі більше виглядає потенційним лідером на ринку, ніж OpenAI.Щоправда, я з цим не згоден. На цей момент, на думку Капітана, OpenAI далеко попереду планети всієї у сфері ШІ для «домогосподарок» (або звичайного обивателя, нікого не хочу образити), тобто міцно тримають нішу звичайного повсякденного чат-бота, з яким простіше за все початитися і поріг входу мінімальний. А ось Anthropic точно обганяє в плані бізнес-сегмента.Якщо говорити про голі цифри, то у OpenAI вливань куди більше капіталу, ніж у Anthropic, а значить і можливостей для розвитку за правильного застосування всіх цих грошей більше. Плюс показники на цей момент за виручкою - OpenAI приблизно $25 млрд (з них на бізнес припадає близько $10 млрд), а у Anthropic із $19 млрд - близько 80% припадає на бізнес-сегмент (більше $15 млрд). Це показує, що OpenAI дешевими підписками може генерувати купу грошей, має більшу базу користувачів, але дуже погано розвивала бізнес-сегмент, а ось Anthropic навпаки. А далі у OpenAI підуть гроші з реклами, тому що саме «обивательський» сектор реклама і буде таргетувати, а ось Anthropic рано чи пізно упреться в межу професійного ринку, який за кількістю юзерів точно менший, ніж «обивательський».Тому в довгу я особисто бачу два сценарії: перший, де OpenAI займає нішу повсякденного використання ШІ для звичайної людини, а Anthropic домінує у професійному, або ж, у що я більше вірю, OpenAI нас ще здивує і зуміє перебити карти Anthropic, нагадаю про перехід засновника OpenClaw до OpenAI, про який поки новин ми не чули.Час покаже, але я майже впевнений, що OpenAI готує якусь бомбу вже найближчим часом.@Zatishna_Galera

#iOSКомпас 🧭1️⃣4️⃣7️⃣ Завдання 147Для чого потрібен prepareThumbnail?Доброго здровля мої любі друзі. З вами ваш незмінний ios розробник Сергій з @badlinkschannel.UIImage.prepareThumbnail(of:completionHandler:) - це той самий маленький UIKit-хелпер, про який легко забути, а потім знову винаходити велосипед через CGImageSource, ресайз і зайві танці з декодуванням. Метод асинхронно готує thumbnail заданого розміру у фоновому потоці й повертає UIImage? у completion handler. І важливий нюанс - сам completion теж викликається не на головному потоці. Тобто будь-яке оновлення UI після цього треба явно перекидати на main thread. 🔣 Практичний сенс простий: коли у вас список карток, галерея, прев’ю файлів або стрічка з картинками, немає жодного сенсу тягнути повнорозмірне зображення в інтерфейс, якщо на екрані все одно потрібна мініатюра. Apple прямо підводить до того, що підготовка thumbnail знижує накладні витрати порівняно з роботою з повним розміром зображення. Для цього в UIImage є і синхронний варіант preparingThumbnail(of:), і асинхронний prepareThumbnail(of:completionHandler:). Другий - куди здоровіший вибір для скролів, списків і будь-якого місця, де не хочеться блокувати потік рендерингу. По суті, це API про одну дуже приземлену річ: не мучити інтерфейс великими картинками там, де вистачить маленької. Менше зайвої роботи, менше шансів спіймати фризи, більш передбачуваний скрол. А ще це хороший приклад старої доброї UIKit-логіки: важку роботу - у фон, UI - окремо й акуратно. 🤓 Можна навіть дати мікроприклад:image.prepareThumbnail(of: CGSize(width: 120, height: 120)) { thumbnail in DispatchQueue.main.async { imageView.image = thumbnail }} #️⃣ Якщо вам для інтерфейсу потрібна саме мініатюра - готуйте мініатюру, а не тягніть у UI повну JPEG-цеглину й не сподівайтеся, що система все якось сама розрулить.@Zatishna_Galera

ЕКСПЕРИМЕНТ ВІД ANTHROPIC НАД ДЖУНАМИКомпанія взяла 52 джуна для розв’язання задачки і проходження невеликого опитувальника по темі цієї задачі. Основні питання були спрямовані на розуміння коду, дебагінг та інші основи програмування. Усіх джунів розділили на 2 групи – використання ШІ дозволено і заборонено.Висновки вийшли цікаві. Група без ШІ краще впоралася з тестом після задачі, хоч і частіше помилялися і гірше вирішили саму задачу. А от учасники з використанням ШІ виконали саму задачу швидше, а от тест після неї пройти нормально не зуміли. Що загалом очевидно – якщо ти намагаєшся методом проб і помилок зробити задачу, ти краще будеш розбиратися в тому матеріалі, який за нею стоїть.Але, була невелика група джунів, яка задачу навіть з використанням ШІ розв’язувала у взаємодії та намагаючись зрозуміти усі деталі. Тобто багато спілкувалися з чатом, намагалися розібратися в задачі і зрозуміти те, що їм ШІ генерував. Такі впоралися відмінно і з задачею і з тестом.Висновок простий – навіть якщо ви використовуєте ШІ, то не забувайте пробувати розбиратися, а що саме і чому вам генерується.@Zatishna_Galera

DLSS 5 ЦЕ НЕЙРОСЛОП, ЯКИЙ КОРИСТІ ПРИНІС ЛИШЕ В МЕМАХНезважаючи на те, що Дженсен Хуанг заявив зі сцени, що їхня технологія - це не просто постобробка поверх кадру, а що це нейрорендеринг, який працює на рівні геометрії та гри, і що технологія підлаштовується під стилістику розробників, але люди йому не дуже вірять.Навіть Тодд Говард, який виступив і розповів, наскільки він у захваті від технології, не зміг нікого переконати.За фактом і розслідуваннями користувачів DLSS 5 виявилася реально нейро-слопом. Так технічний євангеліст NVIDIA, Джейкоб Фріман, сам же й спростував слова СEO NVIDIA і підтвердив, що DLSS 5 бере просто фінальний 2D кадр і вектори руху, це все, на чому базується перемальоване зображення. Технологія абсолютно ніяк не враховує геометрію, глибину та інші параметри 3D оточення і сцен.Виходить, і Тодд Говард, і Дженсен Хуанг трошки напіздюнкули.А Капітан з командою не обманює своїх читачів і впевнено заявляє, що сьогодні п'ятниця, саме час привести моральку і фізичний стан у норму перед новим робочим тижнем.@Zatishna_Galera

#iOSКомпас 🧭1️⃣4️⃣6️⃣ Завдання 146Чим відрізняється garbage collector і підрахунок посилань?Доброго здровля мої любі друзі. З вами ваш незмінний ios розробник Сергій з @badlinkschannel.🤔 Garbage Collector (GC) і Automatic Reference Counting (ARC) - це два різних підходи до управління пам’яттю в програмуванні. Вони вирішують одну задачу: автоматичне звільнення невикористовуваної пам’яті, але роблять це по-різному.🔣 Garbage Collector (GC)Java, Kotlin, C#, Python, JavaScript➖ GC використовує алгоритми трасування (наприклад mark-and-sweep) і визначає, які об’єкти доступні з кореневих посилань, а які вже недосяжні.➖ Об’єкти, до яких немає досяжних посилань, вважаються «сміттям» і видаляються, а пам’ять звільняється.➖ Це автоматичний процес, який запускається рантаймом за потреби.🔣 Підрахунок посилань (ARC - Automatic Reference Counting)Де використовується: Swift, Objective-C➖ Кожен об’єкт має лічильник strong посилань (reference count).➖ Коли змінна створює strong посилання на об’єкт, лічильник збільшується.➖ Коли посилання зникає, лічильник зменшується.➖ Коли лічильник досягає нуля, об’єкт деініціалізується і пам’ять звільняється.class Person {var pet: Pet?}class Pet {var owner: Person?}let person = Person()let pet = Pet()person.pet = petpet.owner = person // Тепер обидва об’єкти тримають один одного, і ARC їх не видалить 🔣 Рішення - використовувати weak або unowned:class Pet { weak var owner: Person? // Тепер витоку пам’яті не буде} @Zatishna_Galera

#ЧарівнийКомпас 🧭2️⃣3️⃣2️⃣ Завдання 232Що таке «ідемпотентність» для HTTP PUT - наведіть практичний приклад перевірки.🤔 Ідемпотентність означає, що якщо один і той самий запит виконати кілька разів поспіль, результат на сервері буде таким самим, як після одного виконання. Тобто повторний запит не повинен далі змінювати стан ресурсу.Для HTTP PUT це означає, що ми не додаємо щось щоразу, а встановлюємо ресурс у конкретний стан.Наприклад, якщо є запит до API для сутності користувача PUT /users/123 і ми надсилаємо тіло запиту з новим ім’ям і обов’язковими деталями користувача, то перший запит оновить/створить користувача. Якщо я надішлю абсолютно такий самий PUT ще раз, стан користувача не повинен змінитися ще раз - ім’я залишиться тим самим, жодних додаткових дій відбуватися не повинно.На практиці, рекомендую перевіряти так: спочатку робимо PUT-запит із певним тілом, наприклад змінюємо поле email у користувача. Перевіряємо відповідь сервера і потім робимо GET, щоб переконатися, що дані справді оновилися. Після цього надсилаємо той самий PUT вдруге і втретє (про всяк випадок) з тим самим тілом запиту. Потім знову роблю GET і перевіряю, що стан ресурсу не змінився і залишається таким самим, як після першого запиту. Тобто дані не дублюються, не створюються додаткові записи, а сама операція не має додатково змінювати стан ресурсу. Це і підтверджує ідемпотентність операції.@Zatishna_Galera

На злобу дня.Випадок з Monobank і Гороховським, звісно, дуже сильно гримить на просторах інтернету. Я не буду заглиблюватися, вірити дівчині, що це все-таки прапор не тієї країни, про яку всі подумали, чи ні.Реакція Гороховського мені більше цікава. Навіть якщо ми згодні, що це прапор рф, то його дії були б зрозумілі, якби він був звичайним обивателем, який хотів зловити лайків і порофлити, але це не та реакція, яку ти очікуєш від глави одного з достатньо розповсюджених і великих банків, який просто заради хайпу зливає дані своїх клієнтів. Особливо беручи до уваги, що це емоційний сплеск, не підкріплений реальними перевірками і доказами. Що на мій погляд було потрібно зробити - сказати дівчині, що поки розблокувати аккаунт не можемо і треба зробити додаткові перевірки, звернутися в правильні структури з таким запитом і після перевірки, вже вирішувати, що з цим робити. Ну що ж, думаю, справа погримить ще, але чомусь я впевнений, що далі срачів в інтернеті і номінальних перевірок нічого не станеться.А я вам нагадую, що сьогодні п'ятниця, саме час привести моральку і фізичний стан до норми. Але нагадаю, що сьогодні ще й 13 число.@Zatishna_Galera

#iOSКомпас 🧭1️⃣4️⃣5️⃣ Завдання 145Яка різниця між some View і AnyView, про яку важливо знати в SwiftUI?Доброго здоровля мої любі друзі. З вами ваш незмінний iOS розробник Сергій з @badlinkschannel.У SwiftUI постійно зустрічаються два схожі, але такі, що працюють по-різному, підходи: some View і AnyView. Для новачка різниця непомітна: і там і там повертається View. Але для SwiftUI це дві абсолютно різні історії, які впливають на те, як фреймворк буде оновлювати інтерфейс і споживати ресурси.🔣 Що ховається за some View:Коли ви оголошуєте var body: some View, відбувається щось на кшталт контракту з компілятором. Ви обіцяєте, що властивість повертатиме значення конкретного типу, який відповідає протоколу View, але сам тип залишається неназваним. Компілятор це влаштовує, він самостійно визначить тип на основі того, що ви написали всередині.Далі вступає SwiftUI. Отримавши від компілятора точну інформацію про типи всіх вкладених елементів, фреймворк вибудовує статичне представлення інтерфейсу. Це ніби SwiftUI заздалегідь знав повну схему екрану з усіма комірками, текстами та зображеннями. Завдяки цьому при зміні даних він може швидко зрозуміти, яка саме частина екрану потребує перемальовування, і оновити лише її.🔣 Як працює AnyView:AnyView працює інакше. Він стирає тип і залишає від конкретної в’юшки лише факт, що вона відповідає протоколу View. Для SwiftUI це означає втрату інформації: він більше не знає, що всередині - текст, зображення чи цілий стек. Усе, що залишається - чорна скринька.Типова ситуація, коли хочеться використати AnyView - повернення різних типів залежно від умови:func content(isLoggedIn: Bool) -> some View { if isLoggedIn { return HomeView() } else { return LoginView() }} Компілятору це не сподобається: типи різні, а some View вимагає один конкретний. Найпростіший, але неправильний спосіб полагодити - обгорнути обидва варіанти в AnyView. Код скомпілюється, але SwiftUI втратить інформацію про структуру і не зможе нормально оптимізувати оновлення.🔣 Правильний підхід - ViewBuilder:Замість ручного повернення і стирання типів SwiftUI пропонує використовувати @ViewBuilder. Цей атрибут перетворює набір View в єдиний вираз із типом ConditionalContent:@ViewBuilderfunc content(isLoggedIn: Bool) -> some View { if isLoggedIn { HomeView() } else { LoginView() }} Тип залишається конкретним і відомим компілятору, просто він уміє описувати умовну структуру. Усі переваги оптимізації зберігаються.🔣 Коли AnyView все-таки потрібен:Є ситуації, де без стирання типу не обійтися:➖ Масив в’юшок різного типу.➖ Інʼєкція в’юшки під час виконання, коли тип заздалегідь невідомий.➖ API, де не можна використати дженеріки.Наприклад, список різнорідних комірок, які приходять із конфігурації:let cells: [AnyView] = [ AnyView(ProfileCell()), AnyView(SettingsCell()), AnyView(NotificationCell())] Але навіть тут варто подумати: можливо, можна обійтися переліком з associated value або якимось іншим дизайном, що зберігає типи.🔣 Просте правило:Якщо SwiftUI може дізнатися тип на етапі компіляції - використовуйте some View. Якщо тип стає відомим лише під час виконання - використовуйте AnyView.AnyView сам по собі не зло. Зло - використовувати його як костиль, щоб швидко полагодити помилку компіляції, не замислюючись про наслідки для продуктивності.#️⃣ Різниця між some View і AnyView - це різниця між статичною типізацією з можливістю оптимізації та динамічною диспетчеризацією з потенційною втратою продуктивності. SwiftUI спроєктований так, щоб максимально використовувати інформацію про типи на етапі компіляції. Будь-яке стирання типів змушує фреймворк працювати всліпу, що рано чи пізно може позначитися на плавності інтерфейсу. Хороша звичка - завжди спочатку пробувати some View і лише в крайньому разі опускатися до AnyView, чітко розуміючи ціну такого рішення.@Zatishna_Galera