Жабаскрипт (веде Віктор Турський)

Blackmagic Camera для iPhone вбиває бізнеси Нещодавно я робив пост про те, що колись ліцензія на Davinci Resolve коштувала від 200 тис до 800 тис дол, але зараз максимальна версія коштує 300 дол й при цьому безкоштовна версія не має ніяких вотермарків й дозволяє працювати з 4к. В цей раз історія про ще один продукт, який вийшов зовсім нещодавно. Стандартна камера в iOS практично не дає ручного контролю над параметрами відео (місяць тому тільки зʼявилася можливість зафіксувати баланс білого, а то взагалі треш був). Але є крута апка - FiLMiC Pro, яка була стандартом, якщо хочеш знімати щось професійне на айфон. Ця апка була платна й не так давно на неї взагалі зробили потижневу підписку, що виходило 250 дол в рік. Потім трохи прийшли в себе й зробили типу 50-60 дол в рік. По суті, монопольне становище FiLMiC Pro дозволяло ставити такі ціни. Й тут Blackmagic Design випускає Blackmagic Camera, яка повністю безкоштовна й має майже все, що має Filmic Pro. Остання презентація Apple знімалася на iPhone 15 й вони для запису використовували саме цю апку, а не власну й не FiLMiC Pro. FiLMiC Pro був супер успішним бізнесом, був стандартом для зйомки відео багато років й в один день все змінилося - бізнес можна закривати. Це той випадок, коли ми можемо казати, що "Blackmagic Camera це вбивця FiLMiC Pro". Єдине, FiLMiC Pro є ще під Android

2 роки в GoogleСьогодні 2 роки, як я працюю в команді Google Cloud. Можу сказати, що тільки зараз я починаю по трохи розуміти, як все працює в Гуглі в контексті технологій й в контексті процесів. Не очікував, що це вимагає стільки часу, але інфраструктура Гугла величезна. Також можу сказати, що кількість всього з чим доводиться працювати достатня велика, тому навіть пишучи 2 роки на TypeScript й Angular я все ще не можу назвати себе експертом в цих технологіях (хоча до цього я багато років працював з React й вважаю себе експертом в ньому, з версії 0.4 він у мене був вже продакшені). Які основні висновки можна зробити:1. В Гуглі дуже крута команда й рівень всіх Гуглерів дуже високий (інженери, менеджмент, продакти, UX й так далі).2. Те, що за межами Гугла, ви звикли робити за пару місяців, в Гуглі ви будете робити півроку. Й причина не в бюрократії (її практично немає), а в масштабі - величезна кількість різних підсистем, які треба між собою узгодити. Також інший підхід, бо на базі Google Cloud побудована величезна кількість інших продуктів клієнтів й краще вам не ламати Google Cloud. 3. Повний овнершип за фічу добре працює, але підходить не всім. Я вже 2-3 тижні не заходив на віртуалку, де пишу код, бо весь цей час я пишу й читаю гугл доки. Моя задача (як сеніор інженера) разпланувати роботу до кінця року, оцінити й узгодити її з усіма іншими (менеджерами, продактами, іншими інженерними командами й так далі). Ну, й звісно разом з моєю командю все це релізнути до кінця. Оскільки в Гуглі немає проджект менеджерів (але є engineering managers), то кожен інженер сам відповідає за менеджмент свого міні-проекту (фічі). В результаті в Гуглі інженеру доводиться розвивати скіли вшир (й в контексті технологій теж).4. Навіть з бюджетами Гугла роботи завжди більше, ніж є людей на неї. 5. Чи ідеальний код в Гуглі? Ні. Технічний борг існує практично в кожному проекті. Але технічний борг не ігнорується й його менеджмент це частина процесу розробки.Спочатку я звертав увагу на різні аспекти роботи, які відрізняються від того, що я бачив за межами Гугла. Але потім перестаєш помічати й зараз навіть складно це побачити, оскільки вже довгий час знаходишся всередені іншої системи.

Service Weaver - концепція модульного моноліту від GoogleВ продовження теми моноліти чи мікросервіси хотів поділитися новиною про новий фреймворк від Гугл. Фреймворк для Go, але нас в першу чергу цікавить сам підхід. Основна ідея, що він розділяє процес деплойменту й процес написання коду. Тобто ми пишемо моноліт, який можно задеплоїти як мікросервіси. Я в Гуглі теж використовую схожий фреймворк.Що Гугл думає про моноліти й мікросервіси:While writing microservices-based applications, we found that the overhead of maintaining multiple different microservice binaries—with their own configuration files, network endpoints, and serializable data formats—significantly slowed our development velocity. More importantly, microservices severely impacted our ability to make cross-binary changes.As a result, we wished we had a single monolithic binary to work with. Monolithic binaries are easy to write: they use only language-native types and method calls. They are also easy to update: just edit the source code and re-deploy. They are easy to run locally or in a VM: simply execute the binary.Тобто хочеться писати моноліт й мати можливість його легко рефакторити (в мікросервісах переміщувати код між сервісами складно, а міняти API ще складніше), релізити цілим бінарем (в мікросервісах треба думати про сумісність сервісів), менеджерити один конфіг (а не для кожного мікросервісу окремо), не паритися з сервіс дісковері, трейсебіліті, не мати оверхеду на RPC поки це не стано реально потрібне та великою кількістю інших проблем.Service Weaver якраз намагається розідлити те, як ми пишем код й як він потім запускається. Пост про фреймворк - https://opensource.googleblog.com/2023/03/introducing-service-weaver-framework-for-writing-distributed-applications.htmlPS: в цьому контексті він мені дещо нагадує підходи в Python WSGI, Perl PSGI, Ruby Rack (дивно, що такого не зробили в NodeJS), але йде значно далі - не тільки абстрагує запуск компонента, але цілої системи й внутрішньої взаємодії

"One React mistake that's slowing you down"Натрапив на цікавий пост про проектування API компнентів. Часто бувають ситуації, коли необхідні дані для компонента знаходяться десь вгорі по ієрархії компонентів. Й для того, щоб передати щось вниз, дані мають пройти декілька слоїв. Що з цим роботи?Давайте здалеку.Це одна із проблем, яка виникає, коли ви працюєте з React. Насправді, така проблема виникає в принципі в програмуванні. Наприклад, коли нам необхідно передати колбек в функцію, й нам потрібен доступ до стейту(змінних), то нам допомогають замикання. Якщо ж замикання не підтримуються мовою (Java чи інше), то ми тут можна обрати інше рішення:1. Міняти API колбека, щоб він приймав стейт зовні й передавати його від викликаючої функції. В React це схоже на випадок, коли ми передаєм пропси через дерево компонентів. 2. Зберігати стейт в глобальних змінних. В React це схоже на випадок з контекстом.3. Інкапсулювати стейт в ООП-ному об'єкті й передавати об'єкт з внутрішнім стейтом й зробити метод call/execute/run/handle/whatever. Й це буде аналог замикання. Навіть є такий патерн - "команда", або функтори (ті, що callable objects) в Python. В React це схоже на передачу children.4. ІншеЩо обрати? Як кажуть - "it depends". Автор статті радить передавати children й, в контексті його прикладу з лейаутом, я з ним згоден. Але завжди зважуйте на свій конкретний випадок. Загальна ідея, коли ви проектуєте API React компонента така сама, як й проектування будь-якого іншого API. API компонента залежить від його відповідальності. Припустимо, що у нас є TweetsFeed й всередені є дві колонки твітів. Ієрархія може виглядята так:TweetsFeed => RightContent => TweetDetails Це не відповідальність RightContent зібрати дані для якогось TweetDetails, який ми вирішили розмістити з правого боку, але й можливо це й не відповідальність TweetDetails збирати дані (оскільки він тільки візуалізує). Тоді можна зробити врапер навколо TweetDetails, який вятигне дані, але можливо взагалі відповідальність всього TweetsFeed тільки в візуалізації й ніхто в TweetsFeed не має тягнути дані зовні самостійно. Всі ці "можливо" це про відповідальність компонента й коли ми проектуємо, ми спочатку думаємо про відповідальність компонента, а потім вже думаємо про API й як передати дані.СТАТТЯ: https://epicreact.dev/one-react-mistake-thats-slowing-you-down/