Telegram statistics channel - @jabascript

Чули про CS Osvita?Я декілька разів чув дуже позитивні відгуки від підписників каналу про ці курси. Мені написав Іван (засновник курсів) й ми вирішили випити кави онлайн. Не так часто зустрінеш настільки професійних й захоплених людей, як Іван. Для підписників каналу ми домовилися про знижку в 15% на всі курси. Також для військових з УБД навчання безкоштовне. ✅ Фішка школи - лінійка фундаментальних дисциплін для мідл/сеньйор інженерів: від написання власної ОС і event loop до алгоритмів у проді та розподілених систем. Багато коду, жорсткі дедлайни по домашках (без них далі не пропускають) і ком'юніті випускників. Я завжди підримую ідею розвитку фундаментальних знань у інженерів. А тут можна написати власну операційну систему. Пробували таке?✅ Зараз йде набір на курс по алгортимам https://www.csosvita.com/courses/algorithms-in-practice ✅ Окрім того CS Osvita активно донатити з власного прибутку на допомогу ЗСУ: вже понад 3 млн грн, з яких 1 млн передали на "Азов", з яким стали офіційними партнерами.Я не знаю, як там інші викладачі (очікую, що добре), але курси, що веде сам Іван точно не розчарують. Пишіть в коментарях, хто вже вчився на CS Osvita й як вам враження? Чи є ще курси, що дають настільки фундаментальні знання, в Україні? САЙТ: https://www.csosvita.com

Інтерв'ю з автором openclaw 🤓Інтерв'ю довге, але дуже цікаве. Багато інсайтів по використанню ШІ й не тільки. ✅ Я ще раз отримав підтвердження, що використання агентів потрібні навички техліда, але ти не тільки задаєш технічне бачення, а даєш певний рівень свободи агентам, задаєш питання типу "а чи зрозуміла тобі мета цього пул-реквесту", "тепер, коли це ти зробив, то робив би ти зараз по інакшому?", також додаєш трохи емпатії. Діалог замість наказів: обговорюйте архітектурні рішення з агентом, питайте його думку та варіанти реалізації перед тим, як давати команду "будуй". Все, як з командою інженерів. ✅ Також цікавий інсайт, що в дешевих підписках за 20 дол моделі повільні й в результаті розробники отримують не той досвід. ✅ Використання голосового програмування. Ніколи навіть про таке не думав.✅ Зазвичай у мене 2-3 агенти працюють, а Пітера 4-7 й він не використовує воркспейси (хоча я більшості випадків теж, а коли використовую, то у мене є 4 заготовлених, які я перевикористовую й ніколи не створюю нові). Хоча підхід до використання у мене сильно співпадає й схожа еволюція - спочатку детальні інстуркції, потім купа інфратсруктури, а потім напрацьовується інтуїція при роботі з певними агенгтами й ти вже просто вказуєш файли й просиш про зміни й знаєш, що вимагає більш детального рев'ю, а що менш детального.✅ Дуже цікаво було слухати про кіберсквотерів. Як під час перейменування проекту буквально за секунди крали його попередня ім'я й відразу рекламували криптотокени й розміщували посилання на малвару.✅ Про душу агентів теж цікавий кейс, треба спробувати буде. ІНТЕРВʼЮ: https://www.youtube.com/watch?v=YFjfBk8HI5o

Як шукати роботу за допомогою ШІ?Ми звикли, що роботодавці можуть використовувати ШІ для аналізу CV кандидатів на відповідність вимог, але ж ШІ може аналізувати й вакансії на відповідність вашому CV.✅ ПідхідБерете ваше CV (має бути якісне й деталізоване) й заливаєте в Gemini, Claude чи іншу LLM (а найкраще відразу на всіх, де є можлиість), включаєте Deep Research або Web Search + Research в Claude й просите знайти всі вакансії, що відповідають вашому CV. В результаті отримуєте список вакасній саме для вас.✅ Приклад звіту від Claude (Web Search + Research) для мого CV з Linkedin. https://gist.github.com/koorchik/a9e580b5b0223563b2b06329ba25acf8✅ Мій промпт для Deep Research для України, (Київ)Але це лише приклад, ви можете сказати, що вас цікавлять інженерні позиції в FinTech по всьмоу світу, наприклад. Тобто варто ітерувати, пробувати різні LLM й так далі.**Роль:** Ти — Senior IT Recruiter та кар'єрний стратег з глибоким розумінням ринку праці.**Завдання:** Проведи глибокий пошук (deep research) актуальних вакансій, які максимально відповідають моєму досвіду, навичкам та профілю, описаному в резюме нижче. Моя головна ціль — знайти роботу.**Мої обмеження та умови:*** **Локація:** Я знаходжуся в Києві (Україна). Розглядаю лише вакансії в Україні (офіс/гібрид у Києві) або повністю віддалену роботу (Remote). Релокацію в інші країни НЕ розглядаю.* **Ресурси для пошуку:** Проскануй популярні платформи (LinkedIn, Djinni, DOU, Work.ua, Robota.ua, Wellfound тощо) та кар'єрні сторінки компаній.* **Актуальність (КРИТИЧНО):** Додавай ТІЛЬКИ відкриті та активні вакансії. Ти ПОВИНЕН ігнорувати результати, де є слова: "неактивна", "закрита", "архів", "closed", "inactive", "archived", "filled". Ігноруй вакансії, які не оновлювалися понад 45 днів.**Формат виводу:**Звіт має бути максимально компактним, без вступних слів та зайвої "води". Мене цікавить лише конкретика.**Крок 1. Зведена таблиця (КРИТИЧНА ВИМОГА ДО ПОСИЛАНЬ ТА СТРУКТУРИ)**Створи Markdown-таблицю. Колонки:1. **Компанія**2. **Позиція** 3. **Формат роботи** 4. **Компенсація** (якщо немає — дай власну оцінку на основі ринку)5. **Фактори метчу** (Коротко: 2-3 ключові навички, технології чи зони відповідальності з мого CV, які ідеально збігаються з вимогою вакансії)6. **Шанси найму** (1-10)7. **Посилання** (*ВАЖЛИВО:* Колонка "Посилання" НЕ МОЖЕ бути порожньою. Ти повинен зберегти та вставити повний прямий URL-адрес на вакансію. Якщо ти не можеш надати пряме посилання, взагалі не додавай цю вакансію до таблиці та звіту).**Крок 2. Аналіз вакансій (ЧІТКА ІЄРАРХІЯ)**Після таблиці надай аналіз. Використовуй сувору структуру з заголовками третього рівня (`###`) для кожної вакансії, щоб текст не зливався у суцільний список.Використовуй ТОЧНО такий шаблон для кожної вакансії:### [Назва компанії] — [Позиція]* **Чому мені це підходить:** [1-2 речення про прямий збіг навичок].* **Мої шанси:** [1-2 речення про мої конкурентні переваги для цієї конкретної ролі].* **Ризики відмови:** [Чесний та критичний аналіз того, чого мені об'єктивно не вистачає за вимогами вакансії, або які інші фактори (наприклад, overqualified/underqualified, відсутність специфічного доменного досвіду) можуть призвести до відмови].**Моє CV в PDF файлі**

Claude code генерує говнокод й що з цим робити.Я використовую Claude Code й на існуючому проекті він генерує дуже крутий код й все добре працює. Також я пробив вайб-кодити додаток на Flutter й вийшло непогано, хоча довелося певну кількість разів змусити Claude рефакторити архітектуру. Зараз я викладаю курс по React в університеті й студенти використовують ШІ (що й в вимагається) й їх проекти з одного боку відповідають формальним вимогам й треба ставити високий бал, а з другого боку - кожен проект це суцільний говнокод, який я би в житті не пропустив на код рев'ю. Оскільки студентів багато, то вчити архітектурі кожного на курсі, де ми вчимо React, не виглядає реалістичним. Тому виникла ідея створити SKILL під Claude Code, який буде робити архітектурне рев'ю й давати конкретні рекомендації по змінам в коді. Я зробив 7 ітерацій A/B тестування скілу й витратив десь 10-15 годин на це. Різниця між скілом й просто промптом з інлайн запитом на архітектурне рев'ю - космічна. Насправді, перші версії скліла могли навіть рекомендувати архітектурні антипатерни. Довелося повичитувати результати його роботи й модифікувати скіл ітарація за ітерацією. Код після впровадження результатів рев'ю просто не впізнати. Звісно на студенському коді результат відразу вічувається, але навіть, якщо добре структурований проект, то рекомендації теж залишаються корисними. PS: мабуть треба планувати продовження стрімів по вайб-кодингу для демонстарції ефекту на моєму пет-проєкті 🤓

TypeScript, AI, технічний боргЯ вже робив пост на цю тему й казав, що AI полегшує використання TypeScript (https://t.me/jabascript/335). Але сьогодні поділюсь ще однією думкою, що є й зворотня залежність - TypeScript полегшує використання AI.Коли використовуєте якогось кодінг агента, то йому треба верифікувати коректність змін, що є критичної складовою його роботи. Запустити все й вручну потестувати в браузері агент повноцінно не може. Тому треба автоматизований спосіб, й тут два варіанти:✅ Статичний аналіз✅ Запустити тестиТести не завжди є на момент написання нового коду. Також виконання тестів вимагає часу. А от TypeScript дає можливості статичного аналізу відразу; також помилки його зрозумілі агенту й вказують на конкретні рядки. Тому, використання TypeScript стає критичним сьогодні, якщо ви використовуєте агентів.Але є ще один важливий аспект - технічний борг й AI. З використанням AI якісний код в проекті стає ще більш важливим, ніж до цього. AI пише умовно як джуніор розробник. Тобто, він дивиться на існуючі приклади в проекті й пише по аналогії. Й чим краще у вас архітектура й якісніші абстракції, тим агенту легшу написати по аналогії код. Але гарної структури у вас немає й в проекті каша - то агент буде генерувати таку саму кашу. Якщо у вас є код, який містить застарівші підходи, то агент буде їх теж копіювати по проекту. Але, якщо у вас є добре структурований код, архітектура, можливо, документація, то агент буде показувати просто неймовірні результати. Де взяти час на якісний код й на якісні абстракції? Насправді, оскільки агент пише за вас весь рутиний код, то у вас залишається весь час для того, щоб створювати йому правильний архітектурний технічний контекст. Бо, як казав Andrej Karpathy, це не prompt engineering, а context engineering. Тобто, наша задача - це менеджмент контексту (бізнесового, продуктового, технічного й тд) й маючи контекст AI може добре й новий код писати й виправляти баги реалізації.Тобто, у нас є можливість бути продуктивнішими й мати більш якісний код. Так, й до AI більш якісний код був дешевшим з точки зору підтримки, але тоді на архітектуру час закладався, а от дрібниці постійно накопичувалися (бо менш критичні, а їх фікс часу може займати багато). Зараз же у нас ситуація така, що розробник відповідає за абстракції й рев'ю, а агент працює над реалізацією кожного компонета. Доречі, принцип "Assemble first" (розповідав на DOU Day минулого року) тут стає ще більш актуальним й важливим, бо потім просто реалізовувати дрібні компоненти агенту буде значно простіше.Що думаєте? Які інсайти у вас при роботі з кодінг-агентами?

Gemini CLI та Claude Code написані на React 🤯Gemini CLI та Claude Code - це інструменти, які працюють у командному рядку, але водночас вони написані на React. Як це можливо?✅ Власні рендерериReact надає зручну абстракцію для побудови інтерфейсів. Netflix була однією з компаній, яка почала використовувати React для рендерингу своїх інтерфейсів не для браузера, а для телевізорів. У той час їм ще доводилося патчити React (пам'ятаю, як мене вразила їхня доповідь). Сьогодні ж рендерери React абстраговані, що надає значну гнучкість. Наприклад, ми маємо окремий рендерер для браузера - ReactDOM, а також рендерер для мобільних платформ - React Native. Але їх значно більше https://github.com/chentsulin/awesome-react-renderer ✅ InkОскільки рендерери тепер абстраговані, можна створити рендерер і під CLI. Існує чудовий проєкт від українського інженера - Ink (https://github.com/vadimdemedes/ink) , який дозволяє писати CLI-інтерфейси на React. Саме його використовують Google, Anthropic, OpenAI та багато інших великих компаній. Але це ще не все: Ink створює адаптивні CLI-інтерфейси й підтримує Flexbox. Але як це працює?✅ YogaКоли Facebook створював React Native, вони хотіли, щоб розробка мобільних застосунків була схожою на створення вебдодатків. Проблема полягала в тому, що візуальні компоненти в iOS та Android за замовчуванням позиціюються абсолютно (position: absolute). Хоча для вирішення цієї проблеми існують різні підходи, у браузері є така зручна річ, як CSS Flexbox, що дозволяє описувати адаптивну верстку в CSS, а браузер уже сам усе робить. Інженери Facebook, а точніше Крістофер Шедо (vjeux), вирішили створити рушій для верстки на C++, який би отримував на вхід Flexbox-макет, а на виході видавав для кожного елемента абсолютну позицію та розміри. Так і з'явилася Yoga (https://yogalayout.dev/). Пам'ятаю доповідь vjeux про те, як вони писали автоматизовані тести для Yoga, порівнюючи результат роботи бібліотеки з тим, що рендерить браузер. Таким чином, Yoga працює під капотом як у React Native, так і в Ink.Я ніби за цим всім стежу дуже давно, але мене все одно вражає, як воно все збирається зі шматочків завдяки гарно спроектованим абстракціям. А як вам?

Як я полюбив TypeScriptКолись я робив пост, в якому розповідав про те, чому ми мало використовували TypeScript в WebbyLab. Всі ті аргументи були дійсні на той час і для тієї ситуації. Ось пост — https://t.me/jabascript/19.Але якщо коротко, то ✴️ Порівнювати треба не TS vs JS, а TS + тести + процеси + тулінг проти JS + тести + процеси + тулінг. І якщо вибирати, що писати — тести чи типи, то ті 20% часу, які були використані на TypeScript, краще витратити на написання тестів. І якщо у вас вже є 80% покриття тестами й багато статичного аналізу (а ми залучали все, що могли для eslint, і використовували багато плагінів, навіть власні), то додавання TypeScript дає лише кілька відсотків в детекції багів, а вартість розробки збільшується значно. Хоча, звісно, завжди були певні проекти, які точно виграли б від використання TS (той самий Excel на JS, про який я робив доповіді).✴️ Також на той час TypeScript був значно обмеженіший, і багато речей з JavaScript не можна було написати нормально в TS (хоча й зараз є нюанси).✴️ Навчити джуна повноцінно TS було дорого й довго (6 місяців, а не 1-2 місяці, як з JS). Окрім обов'язкових тестів на бекенді, на фронті в нас усюди були обов'язкові PropTypes, що додавало рантайм перевірок. І якщо ти запускаєш свій код, то одразу бачиш проблеми.Я сам не раз "залипав" на описах типів на години, а часом можна було й пару днів витратити, якщо це частина якогось фреймворку.✳️ Що змінилося сьогодні?ШІ зробив впровадження TypeScript значно дешевшим. Незрозуміла помилка в коді — спитав LLM, не знаєш, як краще описати інтерфейс — спитав LLM, не знаєш, як переписати складний клас з JS на TS — спитав LLM. Це як кожному джуну (і не тільки) дати експерта з TS, і він буде і допомагати вчитися, і підказувати, як написати, і допомагати дебажити, знати про більшість особливих фіч TS, і багато іншого.Я не джун і пишу на TS вже багато років, але навіть мені LLM сильно спрощує роботу з описом типів. Правда, я помітив, що тепер лінь писати тести, треба також залучати LLM 🙈. TS це ніяк не заміна тестам, але код на TS без тестів все ж таки стабільніший за код на JS без тестів.Сьогодні TS має бути, як вибір по замочуванню для JS проектів, так само як і вміння ефективно користуватися LLM. І якщо ви думаєте, що всі інженери у вашій компанії вміють ефективно користуватися LLM, то ви помиляєтесь.Що думаєте з цього приводу?

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), але йде значно далі - не тільки абстрагує запуск компонента, але цілої системи й внутрішньої взаємодії