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

OPENAI ВИПУСТИЛИ ДВІ OPEN SOURCE МОДЕЛІПоки під постом про збір нашим бійцям у нас іде перепис довбойобів, OpenAI зробили цілу низку анонсів.Для початку випустили дві відкриті моделі GPT OSS, на 120b (5.1 активних) і 20b (3.6 активних) параметрів. Обидві мислячі й підтримують 3 типи «глибини»: low, medium, high. Є виклик інструментів прямо в ланцюжку міркувань (як в o3). На жаль, модельки без мультимодальності, тобто відсутня підтримка картинок, відео і звуку.Судячи з усього, старша модель обходить o4‑mini, а молодша - на рівні o3‑mini. Ліцензія Apache 2.0, по суті їх можна використовувати в стартапах для чого завгодно і як завгодно, а це саме те, за що OpenAI завжди прилітало - що вони, мовляв, Open, але не дуже; схоже, що ця ера вже в минулому.З цікавого: молодшу модель можна запустити на GPU з 16 GB пам’яті, а старшу - на 80 GB. Грубо кажучи, цю радість можна запускати практично вдома на досить простому залізі. Посилання на GitHub додаю.Але й це ще не все. GPT‑5 чекаємо вже 7 серпня, і, за запевненнями - це бомба. Усі функції в одному чаті, якщо нас не обманюють.@Zatishna_Galera

#iOSКомпас 🧭1️⃣1️⃣2️⃣ Завдання 112У чому плюси й мінуси Auto Layout і frame?Доброго здровля мої любі друзі. З вами ваш незмінний ios розробник Сергій з @badlinkschannel. 🤔 В iOS-розробці існує два основних способи керування розташуванням і розміром елементів інтерфейсу: Auto Layout і використання фреймів (frame). Розглянемо переваги й недоліки кожного підходу.🔣 Auto Layout👍 Плюси➖ АдаптивністьAuto Layout дає змогу створювати інтерфейси, які підлаштовуються під різні розміри екранів та орієнтації пристроїв. Це особливо важливо для підтримки iPhone та iPad.➖ Реакція на зміниЛегко змінювати інтерфейс при зміні контенту чи розміру екрана, наприклад, під час повороту пристрою.➖ Зручність локалізаціїАвтоматично враховує зміну розмірів елементів при перекладі додатка різними мовами.➖ Підтримка динамічного шрифтуЛегко адаптується для різних розмірів шрифтів, що важливо для доступності.➖ ГнучкістьДозволяє створювати складні інтерфейси з мінімальними зусиллями завдяки використанню констрейнтів (constraints).😡 Мінуси➖ СкладністьМоже бути складним для вивчення, особливо для початківців.➖ ПродуктивністьУ деяких випадках вимагає більше ресурсів, що може вплинути на продуктивність, особливо при великій кількості констрейнтів.➖ Залежність від версії XcodeПотребує сучасних версій Xcode для повного доступу до всіх можливостей.🔣 Frames👍 Плюси➖ ПростотаЛегко зрозуміти й використовувати, особливо для простих інтерфейсів чи прототипів.➖ ПродуктивністьЧасто це швидший спосіб розташування елементів, бо не потребує обчислень для констрейнтів.➖ КонтрольПовний контроль над розташуванням і розміром кожного елемента.😡 Мінуси➖ Складнощі з адаптивністюВажко пристосувати інтерфейс до різних розмірів екранів і орієнтацій. Потрібне ручне налаштування під кожний пристрій.➖ Підтримка змінПотрібно додатково обробляти зміни, такі як поворот пристрою або зміна контенту.➖ МасштабованістьМенш зручний для масштабованих інтерфейсів і локалізації, адже розміри та позиції потрібно задавати вручну.➖ Складні інтерфейсиСтворення складних інтерфейсів займає більше часу й зусиль.🤓 Приклади використання🔣 Auto Layoutlet button = UIButton()button.translatesAutoresizingMaskIntoConstraints = falseview.addSubview(button)NSLayoutConstraint.activate([ button.centerXAnchor.constraint(equalTo: view.centerXAnchor), button.centerYAnchor.constraint(equalTo: view.centerYAnchor), button.widthAnchor.constraint(equalToConstant: 100), button.heightAnchor.constraint(equalToConstant: 50)]) 🔣 Frameslet button = UIButton()button.frame = CGRect(x: 100, y: 100, width: 100, height: 50)view.addSubview(button) @Zatishna_Galera

#ЧарівнийКомпас 🧭2️⃣0️⃣0️⃣ Завдання 200Що таке Lead Time та Cycle Time в Kanban?Закінчуємо п’ятірку запитань з менеджменту. Сьогодні будемо розглядати Kanban і дві метрики з нього – Lead Time і Cycle Time.🤔 Lead Time і Cycle Time – надзвичайно важливі метрики, які притаманні Kanban і не тільки. Вони показують, наскільки швидко ваша команда приносить користь, і допомагають зрозуміти, чи можна щось оптимізувати для ще більших результатів. Це частково пов’язано з питанням Value Stream Mapping, який ми вже розбирали в цій п’ятірці.🔣 Lead Time (воно ж час від запиту до завершення) – проміжок часу, що пройшов від моменту появи задачі від клієнта або іншого стейкхолдера до її завершення або релізу. До нього входить абсолютно все – очікування вимог, підготовка до початку роботи, сама робота, включно з розробкою і тестуванням, рев’ю і навіть простой у беклозі, коротше – увесь час від появи задачі до її завершення.🔣 Cycle Time (воно ж час активної роботи над задачею) – на відміну від Lead Time, сюди ми включаємо лише час активної роботи над задачею, тобто – тестування, розробку й інші роботи, пов’язані з активною фазою. Ми не включаємо простої задачі в беклозі, очікування вимог та інші речі, які не відповідають реальній роботі над цією задачею.🤓 Для наочності приклад:Клієнт передав нам задачу в беклог 1-го липня. Ми уточнювали якісь деталі і взяли її в роботу тільки 5-го липня, а 20-го включно завершили. Уявімо, що робота кипіла без вихідних для спрощення розрахунків.У такому разі:🔣 Lead Time: 1–20 липня, тобто 20 днів🔣 Cycle Time: 5–20 липня, тобто 16 днів.📌 Грубо кажучи:Lead Time: Backlog 🔣 DoneCycle Time: In Progress 🔣 Done#️⃣ Чим це корисно?Lead Time показує, наскільки довго клієнт реально чекає на виконання задачі з моменту її появи в голові, а Cycle Time – наскільки ефективно команда працює.І тут саме стає важливо Value Stream Mapping, який цілком накладається на ці два показники. Наприклад, якщо клієнт жаліється, що задача виконується занадто довго, тому що він вважає, що вона взята в роботу з моменту появи в беклозі, але ви можете показати, що її Cycle Time значно менше за Lead Time, то це значить, що багато часу витрачається на простій або уточнення деталей – і це саме те місце для оптимізації.@Zatishna_Galera

#ЧарівнийКомпас 🧭1️⃣9️⃣7️⃣ Завдання 197Хто такий Program Manager і чим він відрізняється від Project Manager?🤔 Program Management - це координація кількох взаємопов’язаних проєктів в межах одного акаунта. Зазвичай ці проєкти мають спільну мету, якої неможливо досягти один без одного.Project Manager зазвичай відповідає за окремо взятий проєкт і досягнення його цілей. У свою чергу, Program Manager працює з усіма проєктами, які пов’язані з глобальною метою конкретного акаунта. Наприклад, маємо окремі проєкти в межах акаунта інтернет-магазину: мобільний застосунок для магазину, вебсайт, сервіс для логістики й обліку товарів, складський облік тощо. Якщо це достатньо великий і потужний гравець на ринку, то кожен із цих проєктів може розробляти окрема команда зі своїм Project Manager. Але всі ці проєкти матимуть залежності між собою і переслідуватимуть одну спільну мету. Координацією й роботою з цими залежностями займається Program Manager.Звідси випливає, що важливими рисами Program Manager є робота із залежностями між проєктами, адже без цього неможливо досягти глобальної мети акаунта, а також стратегічне мислення задля досягнення загальної мети, а не цілей окремого проєкту у вакуумі. Можна сказати, що Project Manager - тактик, а Program Manager - стратег.Program Manager може принести велику користь і є цінним тоді, коли в акаунті багато інтеграцій, різних стрімів і підпроектів. Він може:➖ виступати єдиною точкою входу для клієнта й мати глобальне бачення всього продукту➖ знизити ризики дублювання роботи різними командами➖ допомогти з бізнес-вимогами, адже бачить повну картину в цілому@Zatishna_Galera

#ЧарівнийКомпас 🧭1️⃣9️⃣5️⃣ Завдання 195Що таке false positive і false negative в тестах?Один з пасажирів з patreon надіслав у особисті таке питання (до речі, підписуйтесь, якщо хочете підтримати галеру на плаву). Каже, запитали на співбесіді та попросили навести приклади. Давайте розберемося.🤔 Це два типи помилок, які вказують на невідповідність отриманого результату очікуваному. У межах тестування дуже часто пов’язані з криво написаними тестами, особливо це властиво автоматизації.➖ False Positive (він же хибнопозитивний результат) - результат, у якому на перший погляд усе правильно, але насправді ховається помилка.🤓 Для наочності приклад:Ви перевіряєте реєстрацію користувача. На UI отримуєте повідомлення, що ваш користувач успішно зареєстрований. Якщо цей тест більше нічого не перевіряє, то є ймовірність отримати той самий False Positive результат. Наче тест пройшов, повідомлення про реєстрацію є, а от чи справді реєстрація відбулася - ми не перевірили. Тому хороший тест, щоб уникнути цієї проблеми, має ще містити перевірку того, що ми були автоматично залогінені під цим користувачем після реєстрації, або окремий логін під цим користувачем, або ж перевірку, що в базі даних створено відповідний запис про нового користувача.Головна проблема False Positive результатів у тому, що вони створюють впевненість, що у вас усе працює і багів немає, хоча це не відповідає дійсності, і можливо у вас просто тести та перевірки зроблені надто поверхнево.➖ False Negative (він же хибновід’ємний результат) - результат, коли ми отримуємо помилку і вважаємо її дефектом, хоча це очікувана поведінка системи.🤓 І знову приклад для наочності:Дуже часто зустрічається в автоматизації, коли вона написана не надто досвідченими автоматизаторами. Наприклад, ми намагаємося натиснути на кнопку одразу після якоїсь дії, а цей елемент просто ще не підгрузився, відповідно автоматизація не може його знайти й натиснути, тест падає, але через секунду-дві сторінка догружається і кнопка з’являється. В результаті система працює як очікувалося, але тест впав і ми отримали помилку.Головна проблема False Negative результатів у тому, що вони забирають час команди на дослідження тих проблем, яких насправді в системі може й не бути.Обидві проблеми ведуть до того, що користі від такої автоматизації мало і вона підриває довіру до себе. У випадку з False Positives ми просто пропускаємо повз реальні дефекти, у випадку з False Negatives - нам доводиться за такою автоматизацією постійно ще вручну перевіряти результати.Щоб цього не відбувалося, є кілька корисних порад:1️⃣ Тести й тестові дані потрібно підтримувати в актуальному стані, якщо щось змінюється в вимогах, то потрібно адаптувати й тести2️⃣ Синхронізація в тестах має бути налаштована з використанням best practices3️⃣ Тести мають бути максимально ізольовані, а середовище стабільне4️⃣ Перевіряти не лише UI, але й здійснювати перевірки в рамках логів, беку, БД тощо@Zatishna_Galera

#iOSКомпас 🧭1️⃣0️⃣6️⃣ Завдання 106Як зробити клас спостережуваним (починаючи з iOS 17)?З вами знову той самий автор каналу @badlinkschannel. Не забувайте підписатися. А ми продовжуємо наші яблучні історіі.🤔 Починаючи з iOS 17, Apple представила новий спосіб зробити клас спостережуваним за допомогою атрибута @Observable та властивості @Published. Цей підхід спрощує створення спостережуваних об’єктів і покращує інтеграцію зі SwiftUI.🔣 Створення спостережуваного класу з використанням @Observable1️⃣ Імпортуємо необхідні модулі:import SwiftUI 2️⃣ Створюємо клас і додаємо атрибут @Observable:@Observableclass ViewModel { @Published var message: String = "Привіт, світе!"} 3️⃣ Використовуємо спостережуваний об’єкт у SwiftUIТепер ми можемо використовувати наш спостережуваний об’єкт у SwiftUI, і представлення автоматично оновлюватиметься при зміні властивостей, позначених як @Published.struct ContentView: View { @StateObject private var viewModel = ViewModel() var body: some View { VStack { Text(viewModel.message) Button("Змінити повідомлення") { viewModel.message = "Привіт, SwiftUI!" } } }} 🤓 Приклад із поясненням🔣 Повний приклад використання спостережуваного класу в SwiftUI:import SwiftUI@Observableclass ViewModel { @Published var message: String = "Привіт, світе!"}struct ContentView: View { @StateObject private var viewModel = ViewModel() var body: some View { VStack { Text(viewModel.message) Button("Змінити повідомлення") { viewModel.message = "Привіт, SwiftUI!" } } }} 🔣 Приклад використання @EnvironmentObject:import SwiftUI@Observableclass ViewModel { @Published var message: String = "Привіт, світе!"}struct ParentView: View { @StateObject private var viewModel = ViewModel() var body: some View { ChildView() .environmentObject(viewModel) }}struct ChildView: View { @EnvironmentObject var viewModel: ViewModel var body: some View { VStack { Text(viewModel.message) Button("Змінити повідомлення") { viewModel.message = "Привіт, SwiftUI!" } } }} @Zatishna_Galera

Пройшла WWDC від Apple.➖ Apple Intelligence: спочатку я подумав, що це пародія або комедійний стендап, а не справжня WWDC. З такою помпезністю розповідати про роботу функцій, яких вже рік в повному обсязі нема, або які працюють так, що краще б і не працювали - це вміє тільки Apple.➖ Новий єдиний стиль для всіх платформ: Liquid Glass. Дизайн додає прозорості й ефект скла в інтерфейс. Кажуть, що це наймасштабніше оновлення дизайну від Apple. Мабуть, мені, простому Капітану, не дано зрозуміти цю «масштабність». «Теми для Windows 98 завантажити без SMS і реєстрації» видали за якийсь гігантський next step. І так, щось подібне вже було і на Android, і на Windows - в мережі вже мільйон мемів. І так, Apple досі не відповіла на слона в кімнаті - як узагалі з цим жити? Навіть людині без проблем із зором доведеться постаратися, щоб прочитати білий текст у прозорому віконці на світлому фоні. Що робити людям з вадами зору - поки загадка.➖ Як ми й припускали, усі ОС тепер отримають номери року випуску +1. Тобто наступні ОС будуть під номером 26.➖ Перекладач: додали в кілька застосунків і ОС можливість живого перекладу. Наприклад, якщо вам зателефонує дядько з Африки, який хоче залишити спадок, але ви не знаєте його мови - ви зможете в режимі реального часу чути замість тарабарщини зрозумілу мову. Крута штука, якби в Apple щось навколо ШІ працювало так, як очікується. Тому заочно ставимо 5, але в релізі сумніваємось.➖ Оновили CarPlay: сюди теж прикрутили Liquid Glass, зробили компактнішим, додали віджети.➖ iOS 26: усі приколдеси Liquid Glass, оновлення повідомлень, браузера, камери, фото. Загалом, зміни радше «мінорні», на мій погляд. Там кнопочку додали, там місцями поміняли. Оновили застосунок для дзвінків, додали асистента, який до того, як ви візьмете слухавку, може дати інсайти про дзвінок або допомогти з «утриманням на лінії». ➖ watchOS 26: вже згаданий Liquid Glass. Workout Buddy - ШІ-помічник для тренувань. Робитиме висновки після тренування, даватиме поради тощо. Працюватиме англійською з 6 популярними видами спорту. Тепер можна автоматично підібрати плейлист або подкаст під конкретний вид спорту, залежно від ваших вподобань і історії прослуховування.➖ tvOS 26: оновили інтерфейс, звісно ж, Liquid Glass і тут. Зʼявився режим караоке Sing with Apple Music. iPhone можна використовувати як мікрофон і контролер. Навіщо це потрібно - поки не знаю. Додали профілі, як у Netflix.➖ macOS 26 Tahoe: Liquid Glass - ну ви зрозуміли. Більше опцій для налаштувань і кастомізації іконок і папок. Нові фічі для праці з iPhone. Прокачали Spotlight - тепер це частково Raycast на мінімалках. Оновили Shortcuts.Це буде остання ОС з підтримкою Intel-чипів. ➖ iPadOS 26: зʼявиться нова система багатозадачності. Тепер працювати з великою кількістю відкритих вікон стане значно простіше. Ноутбук вам все ще не замінить, але тим, хто не згоден і скаже «та мені вже кілька років як замінює» - страждати й самообманювати себе стане трохи легше. Крім цього, додадуть нові можливості й застосунки для зручності роботи, наприклад Files, Preview та інші. І, звісно ж, Liquid Glass.➖ visionOS 26: додали цікаві віджети, які можна «закріпити» у просторі - наприклад, повісити віджет погоди як картину на стіну. Прокачали віртуальних аватарів, або «персон». Інтегрувались із кількома виробниками 360-камер для перегляду контенту, знятого на них. GoPro є у списку. І ще купа дрібних нововведень.➖ Інше: також трохи прокачали карти, в Apple Music додали функцію зведення треків для безперервного програвання плейлисту (привіт Spotify, дякуємо, що вигадали до нас), додали переклад текстів, трекінг посилок у Wallet, можливість додати цифровий паспорт для внутрішнього використання в США. Додали застосунки для ігор з лідербордами - кіберкотлети на iPhone в захваті.@Zatishna_Galera

#ЧарівнийКомпас 🧭1️⃣9️⃣3️⃣ Завдання 193Що таке flakiness в автотестах🤔 Flakiness - це нестабільність автоматизованих тестів, якщо дати грубе визначення. Наприклад, тест то проходить, то валиться з незрозумілих причин, навіть якщо в фічі нічого не змінювалося. Існує також поняття flaky-тести - ненадійні тести, на результат яких не можна покладатися, бо він може бути хибним. Чим більше у вас таких тестів, тим менш надійною є автоматизація на проєкті.🔣 Причини flakiness:1️⃣ Нестабільні локатори в UI-тестах: елемент не встиг з’явитися на сторінці, а тест уже намагається з ним працювати, або прив’язка не до статичного локатора, який може змінюватися з кожним запуском.2️⃣ Погана синхронізація: затримки при зміні активності елементів тощо.3️⃣ Асинхронні операції: дія ще виконується, а ви вже перевіряєте результат.4️⃣ Залежність від зовнішніх сервісів (наприклад, API): щось змінилося у виклику конкретного API, і тест далі не проходить.5️⃣ Паралельний запуск і конфлікти даних: кілька тестів використовують один і той самий ресурс (наприклад, користувача) і заважають один одному, впливаючи на результати.🔣 Що з цим робити:1️⃣ Покращити синхронізацію: використовувати очікування за умовами, а не «жорсткі» паузи в секундах (це дуже погана практика).2️⃣ Ізолювати тестові дані: використовувати унікальні дані для кожного запуску й не забувайте очищати їх після тесту.3️⃣ Мінімізувати по можливості залежності від зовнішніх нестабільних сервісів: мокати зовнішні API або використовувати стабільні тестові endpoints.4️⃣ Додати логування та діагностику: flaky-тести важко відслідковувати без нормального логування, що взагалі стосується будь-яких тестів. Логування - ваш друг.5️⃣ Впровадити логування flaky-тестів і аналізувати його: аналізуйте тести після прогону, розбирайтесь, чому вони впали і як це пофіксити.#️⃣ Flakiness - велика проблема для автоматизації, і з нею треба, і можна боротися. Не запускайте цей момент, інакше він буде рости як снігова куля, і у вас просто не буде часу зайнятися цим з розумом.@Zatishna_Galera

ДУМКИ ПРО «ВСІ МИ ПОМРЕМО, А ШІ НАС ЗАМІНИТЬ»Такі розмови в моїй бульбашці з’являються постійно і завжди цікаво подискутувати про це з розумними людьми.Нагадаю вам, що кожну ітерацію нових ШІ-інструментів ми чуємо одне й те саме: «Ну все, ось тепер точно програмісти/тестувальники/дизайнери (оберіть своє) більше не потрібні». Чую це вже десь останні 3–4 роки. І що?Усі ці спеціалізації все ще потрібні, вони нікуди не зникли. Що ж змінюється?Змінюється підхід до роботи. Тепер у вас під рукою завжди є інструмент, з яким можна побрейнштормити ідеї, швидко зробити чернетки та ескізи задач, і при бажанні підвищити свою продуктивність на певний відсоток.Все ще потрібні люди, які можуть мислити, міркувати, вигадувати ідеї та солюшени. ШІ не може зробити це за вас - він може допомогти вирішити задачу, але її треба поставити і придумати.Все ще потрібні люди, які можуть зрозуміти проблему або розібратися в технології. Все ще потрібні ті, хто зможе прийти і зрозуміти бізнес-бік задачі, щоб перекласти її на технологічну мову.Все ще є старий легасі, який просто бездумно рефакторити не можна - потрібно сидіти й занурюватися в нього, щоб зрозуміти, що там було 10 років тому і що з цим робити зараз.Тому я повторю фразу, яку люблю казати: «Ні, ШІ не замінить нас як професію в найближчому майбутньому, але якщо ви не будете ним користуватися, то роботодавець замінить вас тим, хто ним користується». Тому бійтеся не ШІ, а своїх страхів його використовувати.@Zatishna_Galera

#ЧарівнийКомпас 🧭1️⃣9️⃣2️⃣ Завдання 192Що таке «code freeze» та його вплив на QA.Code Freeze - це етап у розробці, коли в кодову базу проєкту не вносяться жодні зміни, окрім виправлень критичних дефектів. Зазвичай він використовується командою перед релізом нової версії продукту або ключовим етапом життєвого циклу, наприклад, квартальною демонстрацією для замовника. Це робиться для зменшення ризиків неочікуваних поломок перед цими подіями та зосередження на стабілізації вже готового функціоналу.Для QA Code Freeze означає:1️⃣ Ми виходимо на фінальний етап тестування в рамках цього циклу розробки. Ми можемо бути впевнені, що новий функціонал додаватися більше не буде, і можемо повністю зосередитися на доведенні до ідеалу вже впровадженого. Ідеальний момент для повного регресійного тестування та стабілізації версії продукту.2️⃣ Дуже важливо правильно розставляти пріоритети дефектів. Під час code freeze зміни в коді повинні зводитися до мінімуму, а це означає, що навіть критичні дефекти проходитимуть кілька етапів перевірок, перш ніж буде ухвалено рішення щодо їх подальшої долі.3️⃣ Важливо грамотно розподіляти ресурси та правильно визначати суміжні зони при перевірці критичних багів. Повністю запускати регресію кожного разу вже немає часу, але й залишати потенційні області, які може зачепити виправлення критичного дефекту, без уваги - не варіант.4️⃣ Оскільки проєкт переходить у фазу стабілізації, а не розробки та додавання нового функціоналу - це чудовий момент приділити більше уваги нефункціональному тестуванню. Причини таких дефектів значно легше локалізувати саме у стабільній версії продукту.5️⃣ Імовірно, комунікація між QA-командою та розробниками може трохи ускладнитися, адже інженер з QA команди може не погоджуватися з думкою девелопера щодо пріоритету багів і необхідності їхнього виправлення на цьому етапі.Code Freeze - це дуже корисний інструмент, який за правильної реалізації може суттєво допомогти QA-команді грамотно підійти до тестування та стабілізації. Тут надзвичайно важливо вміти знаходити спільну мову з розробниками, а не тягнути ковдру на себе. Пам’ятайте, що ви працюєте над спільною справою, як одна команда, і якщо кожен буде тягнути в свій бік - результату не буде.@Zatishna_Galera