LLMs заходять у нашу реальність просто як шквал і ютуб завалений враженнями людей, які спробували ChatGPT. Було б непогано поговорити трошки глибше за перші враження?

Тож ми з Олексієм Орєшко обговоримо, як воно працює, чому раптово так круто, і які можуть бути наслідки. Олексій працює над LLMs (Large Language Models) у Google і загалом займається ML вже скоро 10 років — так що буде цікаво. :)

Так що готуйте вільний вечір на завтра (3 січня) о 19:00 за Києвом, ми чекаємо вас і ваші питання. І не забудьте відправити лінку друзям. :)

Ми через 10 хвилин починаємо, тож не провтикайте: https://youtu.be/P66ktl4ScxA

UPD. Наче прям дуже цікаво вийшло :) Як вам? :)

Вчора натрапив на пост у фейсбуці, де автор іронізує над забороною ChatGPT у школах Нью-Йорка. Дуже по ділу іронізує — нащо вчити синуси та факти про війни, коли це все легко можна знайти в інтернеті.

Та мало того, я сам пару місяців тому написав пост про теж саме — що в нас освіта про знання, а не про освіченість. Але хочу тут зіграти роль адвоката з іншої сторони.

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

Видай 3-річній дитині калькулятор — і вона не навчиться рахувати сама, бо, так би мовити, навички калькулятора настільки перевищують навички дитини, що їй навіть в голову не прийде, що це можливо. Знаєте історію про те, що друга дитина зазвичай швидше роздупляється, ніж перша? Це ж воно, у першої дитини як приклад — недосяжні дорослі, а у другої — відносно близька по можливостях і розмірам перша. Це питання не тільки тренування, а й усвідомлення досяжності.

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

Це ж найголовніше, що повинна вміти людина — формулювати свої думки так, щоб їх можна було усвідомити. І до того як сісти за кермо, було б непогано навчитися ходити — щоб не було як у Wall-E, так?

Це рівно такі самі переживання, як я наблюдаю у Твіттері: схоже що МЛ зможе допомагати програмістам-експертам стати більш продуктивними, але так знизить попит на джунів, що нові експерти перестануть вироблятися.

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

Читав, як чуваки 10 років сапортять одну й ту саму апку (з бекендом) — і які висновки вони з того можуть зробити. Ну і частково ті висновки очевидні, про те що PostgreSQL дуже кльовий, або що інтеграційні тести дуже допомагають бути впевненим у великих змінах.

Але звернуло мою увагу трохи інше: згадка про інтеграції та 3rd-party SDK. Очевидно, що інтеграції — це біль, бо розбіжність моделей даних часто ламає мізки, бо чуваки з тієї сторони забивають на зворотню сумісність і все ламають.

А от про SDK хотілося б зупитися окремо. Він там наводить приклади, як Google SDK стало Google+, а потім Google Sign-In, як Crashlytics туди-сюди стрибав (і перейменовував все), і "I had to rewrite the entire login flow due to all the new third party SDKs". Типу фреймворки епла дозволяють старий код не викидати (молодці), але от всі ці сервіси із SDK — козли.

Років 5 тому мені написав Owox із пропозицією заюзати їх солюшен перекладання даних гугл аналітики в BigQuery. Коли я зрозумів, в чому пропозиція, я зреагував як справжній програміст — я ж зроблю це за два дні! Жаба задавила платити гроші — і ще й додавати додаткову зовнішню залежність.

Кожен раз, як я розповідаю цю історію, люди сміються, бо зі вступу очевидно, що за два дні не вийшло. Але цікаво те, чому ж не вийшло! Я відкрив документацію, і там пропонують взяти com.google.cloud/google-cloud-bigquery як залежність і все з нею зробити. І я втратив понад тиждень на те, щоб авторизуватися та зробити хоч якийсь запис до того драного бігквері!

Зараз от згадую — здавалося б, ну що там таке може бути? Глянув на код, наче нічого такого, але незрозумілі помилки, поцоватий апі зі схованими класами, конфлікти різних гуав — ну все як треба.

А потім же ж ще треба звідти якісь дані дістати? Як зараз пам'ятаю, два тижні не міг змусити себе до того підійти — перевірив навіть по історії гіта. 😁 Сів і через HTTP API Гугла — ну теж не подарок, але зовсім інший рівень зла — написав за половину дня сто рядків коду, які ще й нормально працюють!

Як ви можете здогадатися, у реалізації запису ми навіть ні разу не оновлювали версію сдк Гугла з 0.18.0-beta, поки не видалили, бо воно з кожним оновленням палає наче дурне все (теперішня версія 26.1.5). А хттпшний апі, на щастя, гугл не поганить так швидко, як фейсбук (хоча й поганить все одно). Тому все досі працює, і юзається не стільки для BigQuery (яким Каста вже не користується), а для інших апі гугла (типу звітів о рекламі).

Мораль: SDK, особливо великі та заплутані — гнусність, і їх треба уникати. А особливо сдк великих компаній, бо там багато людей, яким нема чим займатися, окрім як створювати зайву роботу іншим людям. :)

P.S. Він там ще згадує Apple Sign-in, в якого типу мало доків — але це фактично звичайний OAuth із додатковим викликом в апках. Думаю, що вони всередині мають якийсь django-oauth, який теж дуже поганий і закриває від тебе розуміння, що відбувається. Коли Apple реджектнули нам реліз апки через його відсутність, воно все поїхало за якусь годинку-дві, бо в нас нормально зроблений оаус. :)

ОРМи на смітник!

Автоінкремент зайшов добре — давайте і по ОРМам пройдемося? 😝

Нащо вони нам? ОРМи існують для розв'язання двох проблем: композиції та того, що реляційні дані формою відрізняються від об‘єктів. З другим наче інтуітивно зрозуміло, а з композицією історія в тому, що SQL сам по собі компонується погано, а у більшості мов це ще й просто рядочки тексту – то взагалі гаплик.

Якби дизайнери SQL'ю думали не тільки за читаємість, а ще й за компонування кусочків без змін, куди б менше проблем ми зараз мали... З іншої сторони маємо Elasticsearch, там думали за композицію і не думали за читаємість — не так щоб результат критично кращим був. 😁

Повернемося до наших баранів! Здалеку ця ідея здається розумною. Скомпонував знач з кількох частин запит, отримав на виході свої об'єкти, фантастіка ж! Чи погано? ДуЖе пОгАнО! 😡

• Кожен ORM вирішує N+1 по-своєму, і треба бути дуже обережним пупсіком, щоби не налажати. Якщо ваші руки тягнуться написати "а я от навіть не напружуюсь", то у вас стокгольмский синдром, як у мене з динамічною типізацією. 💯
• Мало не всі ОРМи дають легкий спосіб добратися від даних в пам'яті до даних в базі. book.author — і маємо ще один запит в базу. Програміст щасливий, бо коду не писав, замовник щасливий, бо автор показується, база щаслива, бо про неї не забувають. В поганих випадках не забувають по 300-400 раз на сторінку.
• Реляційні дані дійсно не дуже лягають на об'єктні моделі, особливо їх динамічність. Попри те, що всякі Пайтони — динамічні, ормівські моделі доволі-таки статичні. Тому звичайний програміст уникає агрегацій і підрахунків в базі. Є кльова відмазка — це ж не web-scale, краще ми заведемо собі кілька реплік і розмажемо по них навантаження. Нічого, що сетап складніше став, комп'ютери залізні, не плачуться.
• Не концептуальна проблема, але зазвичай ORM — це дуже багато коду. HoneySQL — це 3 тисячі рядків, django.db — 32k, sqlalchemy.orm — 36k (увесь sqla — 137k!), і так далі. Можете подивитися на свій. Так от, для відносно простих сторінок ОРМи можуть займати 30-60% часу виконання. Я колись пришвидшив сайт в два рази тим, що апгрейднув алхімію з 0.8 до 1.0.

Підсумовуючи, я маю дві претензії до ОРМів:

• Погані практики на них реалізовувати дуже легко і програмісти до того тяжіють (читай: пишуть погано), а будь-яке покращення запитів ускладнюється: всякі .select_related чи .prefetch_related (знаєте в чому різниця, га?) в Джанзі, .options(...) в sqla. Я не хочу навіть знати, що там на Джаві.
• Реляційна модель заходить програмістам на ОРМах дуже так непевно і потім їх треба перевчати. Замість того дати розібратися у базових принципах і дати ними користуватися, ОРМи закривають їх собою, як Франкейнштейн з дахом^W абстрацією, що протікає.

То що робити біднесенькому програмісту? По-перше, змиритися, що найкращий спосіб робити запити в БД це що? Авжеж, це HoneySQL на Clojure, а що ви очікували. :-) Це гарний спосіб отримати композицію, якої нема, коли використовуєш строки, але не відриватися від базового SQL занадто сильно — і всі можливості SQL на місці, і болі в сідницях від конкатенації нема.

У SQLAlchemy є базова алгебра функціями, а не тільки ORM, наприклад, але воно не ергономічно. Не знаю, як покращити, щоб ним приємно було користуватися — може в когось є корисні думки?

Ну а по-друге, коли всі покрови зірвані, треба думати й експериментувати. Я впевнений що всюди можна зробити краще, ніж статус-кво (except you know where, ha-ha).

P.S. Тільки не згадуйте монги в коментах, будь ласка.

Даю 💯, що мої думки про ОРМи, фреймворки та й таку іншу потороч натякають на те, що я полюбляю ручні КПП в автомобілів. Або не натякають, але можна було б таку паралель провести.

І дійсно, я раніше був строго прихильником РКПП — ти все одно ведеш машину, чом би й не поклацати руками (і ногою). Тим більше, що АКПП — мотлох: вони або жруть зайві літр-два палива, або смикають машину, і регулярно вмикають не ту передачу, яку б варто було, і взагалі, хто тут хазяїн, я краще знаю, що робити.

Але АКПП покращувалися і покращувалися, і дійшли до стану, коли не має сенсу у загальному випадку користуватися ручною коробкою. Я продав свою останню машину на ручці у 16-му році та не бачу сенсу повертатися (ну, може для розваги колись, не знаю). Точно як збірники сміття у мовах з автоматичним керуванням пам'яттю.

Бо це файна абстракція, не те що ORM!ヽ༼ ಠ益ಠ ༽ﾉ

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

І тому вчитися треба на адекватній машині, і з АКПП, бо на дорозі достатньо притаманної складності (для людей, які не вміють українську: inherent complexity) — відриватися на мішалку це зайве, коли ти ще взагалі нічого не шариш. Тому, напевно, починати програмування з мов із GC краще, ніж із ручним керуванням пам'яттю.

Знаєте Barnes & Noble? Це книжкова мережа така в штатах, яку сильно підкосило поява Амазону ну і взагалі розвиток екомерса. Аж тут виявилося, що вони торік (у 22-му, якщо у вас в голові час теж не дуже адекватно трекається) вони відкрили 16 нових магазинів.

Я щось думав, що вони йдуть дорогою Блокбастеру, там і продажі Nook'а (їх е-інкової читалки) падали з року в рік, а тут така історія. Виявляється, їх викупили з біржі, знайшли на посаду CEO чувака, який любить книжки, і раптом виявилося, що компанія може ще попрацювати.

Він перестав продавати всіляку чухню в магазинах (Укрпошто, можливо, це натяк? 😁), припинив брати маркетингові гроші від видавців 🤯 — бо це призводить до того, що на найкращих місцях стоять не кльові книжки, а ті, за які занесли, дав працівникам магазинів свободу у розкладках — ставте на видне місце те, що люблять люди, і взагалі, стаття про цей розворот достатньо цікава.

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

P.S. Є ще один прикольний нюанс, який та стаття не згадує: з біржі B&N викупили та знайшли кльового CEO компанія Elliott Management, ті самі чуваки, що провернули з Dell'ом всю ту двіжуху.

Гугл вчора звільнив 12 тисяч співробітників тим самим гнусним способом, що й Маск у Твіттері до того: просто заблокувавши доступ до всього на роботі. Пишуть, що спочатку був доступен сайт, який розповідав про додаткові коммунікації, які відбудуться — але потім і до нього доступ пропав.

Навіть менеджери звільнених людей виявлялися здивованими. А Пічай в інтерв'ю каже "ну ми ж не могли інакше, в нас цілих 30 тисяч менеджерів". Звучить наче як відмазка першокурсника, чому він не зробив цю лабораторку: їх так багато, що я заплутався, і вирішив жодної не робити.

Люди понад 10 років у компанії працюють, а їх звільняють блокуванням доступу. Дегуманізація на марші, чи що. Цікаво, чи це вплине помітно на відношення до компанії тих, хто залишився?

Я десятиріччями для тестів бібліотек на джаваскрипті юзав маленький фреймворк під назвою WRU. Не жартую про десятиріччя, перша згадка — в грудні 2012 року. Сам в шоку, так.

Ну і для Твінспарку я тоді взяв його ж, але він зламався на промісах. Нічого не ясно, але я створив issue на гітхабі, та автор відповів "давно вже не юзаю, не сапорчу і не шарю" і заархівував проєкт. 🤣 Я все переробив на таймаути та й на тому заспокоївся на пару років, аж на минулому тижні мені стрельнуло дописати трохи функціональності у Твінспарк (це окрема історія), і для тестів знов знадобилися проміси.

Я пішов глянути код WRU, а там жах. wru.async робить страшне, функції звуться isGonnaBeLegen та Dary — супер, що ти такий жартівник, дуже зручно. Я пішов шукати заміни, але jest на 300 кб та mocha на 2 мб мене щось не приваблювали. Я хочу 1 маленький файл, який я кину у теку vendor і не буду мати справ із NPM'ом з цього приводу.

Після години розглядання купи джаваскриптових ліб, які або абсолютно дурних розмірів і складності, або репортять через console.log замість намалювати прогрес у браузері, я взяв і написав власну. Вийшло реально менше сотні рядочків, з асинхронністю (await test.func() та й рибка в сітці, якийсь прогрес все ж-таки є!), кайф.

А тільки що дописав ще запускалку тестів у HTML'і у headless Хромі, і тепер в мене є повноцінний CI для Твінспарка. :-) Тут, правда, не обійшлося без NPM, бо якось з консолі отримати якийсь фідбек із Хрому фактично неможливо. Шкода. 😁

Мораль: не завжди найприємніша дорога недоречна. 🤣

‌Я ще у листопаді спробував записати відео англійською і від акценту мені стало важко. :) Зі словниковим запасом все окей, а з вимовою у мене і рідною мовою не ідеально. :))

Тож я на преплі знайшов собі препода, і прям серйозно так засів. Щось дуже важко це, якщо чесно, при чому по-різному для різних звуків: æ та h мені якось навіть важко усвідомити, за light l я забуваю стежити, діфтонги я впевнений, що кажу, але схоже занадто швидко прожовую. Найкращий результат, коли не поспішаєш, але це стільки сили волі потребує, жах просто. :)

Так от, до чого це я. Одне з останніх занять чувак показував, як люди розмовляють (без звуку) — і треба вгадати, яка мова. І на одній зі сценок дві дівчини десь у театрі щось обговорюють, майже не відкриваючи рота. Едвард (мій препод) каже, що це через велику кількість звуків «нагорі», тобто коли язик до піднебіння торкається.

Я спробував — і дійсно, я стартую наче нормально, а потім перестаю відкривати рота й англійська стає дуже зажована. :) Тому стежте за ротом! :)

Друга річ, про яку хотів розповісти, це голосні звуки. Вікіпедія англійською про англійську: "has a particularly large number of vowel phonemes". Картиночка "позиція язика, коли робиш звук" має 12 звуків, Вікіпедія ще згадує діалекти...

Натомість українською про українську там пишуть: "спрощення системи вокалізму до 6 голосних". Ну так, нам же ж ще у школі розповідали, яка українська мова проста і взагалі все пишеться як чується, які проблеми, бла-бла-бла. Але, на щастя, є і картиночка, як для англійської мови — дивися нижче.

Все в нас нормально, нічого простого у наших "6 голосних" немає. 🤣 Просто не вчить українську мову 1 млрд не-індоєвропейців, тому ми ще у стадії заперечення. 😁

P.S. Якщо комусь із вас теж захочеться британського акценту потренуватися, то чувак мені попався кльовий, можу порекомендувати: Едвард (реферал лінка). Їх по такому напрямку за адекватні гроші не дуже багато, і з відгуками не густо.

Вчорашні обшуки в MacPaw та в Саші вдома — неймовірна ганьба. В обговореннях цього люблять підкинути посилання на розслідування, що "це насправді все по ділу", та не можна будувати так близько до Дніпра єтц.

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

Нікого не звільняють за те, що він підписує контракт із Cisco, і нікого не саджають за зупинку роботи компанії. І це проблема наша, авжеж: воно вбиває інвестиційну привабливість країни, а разом з тим ще й вбиває привабливість країни загалом. :(

UPD: Саша написав багато тексту про цю ситуацію.

Ви уявляєте, я примудрився провтичить анонсувати перший випуск, тож, якщо ви не бачили, там вийшло вже два випуски Right Tool For The Job у партнерстві з Luxoft.

Останній — про моніторінг, а перед ним — про Java, і про БД, і Еластік зачепили, в цілому такий загальний вийшов. Enjoy!

core-js

Минулого тижня автор проєкта core-js написав довжелезний пост про те, який світ несправедливий, і замість того щоб платити йому дуже багато грошей, натомість платить небагато грошей.

Пост там такий, шо важко взагалі челюсть з полу підібрати, поки його читаєш: як приклад нестачі грошей — потреба купити дружині новий айфон, victim-blaming дівчини, яку він вбив своїм мотоциклом, згадка про війну (тут я взагалі гублюся, що тобі заважало мовчати?) у вигляді "two evils", і багато іншої дурі.

Ну я почитав, подумав "ото козел", і закрив. А натомість відкрив Hacker News, де в топі висить ця історія, і всі верхі коментарі в стилі "біднесенький програміст, підняв важливу тему!" А всі спроби вказати, що він трошки не зовсім біднесенький, і насправді і з грошима там місцями навіть все не дуже погано (і пожертв на 2.5 тисячі на місяць, і десь там контракти на 10к зелених) — задаунвочені.

Ну я з того вразився дуже сильно, і написав твіт англійською, щоб мож хоч хтось з-за кордону прочитав та увімкнув трохи критичного мислення. Аж тут виявилося, що в нас на ДОУ коментатори такі ж недалекоглядні:

> як це відноситься до коду в опенсорсній лібі?))

І от що я з цього приводу хочу сказати: напряму відноситься. Політичні погляди людини не можна відділити від людини. Чи можна відділити від коду? Хз, але мене це питання зараз не цікавить. Питання таке: чи треба підтримувати фінансово чувака, який підтримує війну? В жодному разі! Це сприяння поганій поведінці, поганий прецедент і все таке. Ганьба адекватності.

Тим більше, що адекватністю там і не пахне. Він у свій код натащив коду інших людей, при тому порушуючи ліцензію. Очевидно, таким чином зробивши все-в-одному пакет для вирішення питання з поліфілами і пробився у залежності до Babel'я (цікаво ще, як). Ніколи не додавав інших мейнтейнерів, навіть коли попав у тюрму — job security в повний зріст. Ну і тепер цим всім шантажує ком'юніті. 🤦‍♂️

А ще двіжуха апологетів придумала порівнювати core-js із OpenSSL, якому "теж не доставалося грошей і подивіться до чого це призвело". Вражає хуцпа, порівнювати власне відносно простий код polyfill'ів (бо там, де складно, він код спіонерив, хаха) із серйозно складним проєктом, завдяки якому працює увесь-увесь інтернет. 🤯

Михайло ще непогано розклав цю історію, з подробицями.

P.S. Завдяки Максу Кавалері я перестав слухати Soulfly у 14-му році. Кілька разів вмикав, музика подобається, але не можу забути про те, що він мудак. Та ж сама історія.

Я тіки що використав ChatGPT для того, щоб написати плагін для ProseMirror. Це просто сюрреалістичний досвід.

Плагін — це коментування. Не питайте, нащо мені, якщо зараз все нормально зрощу, то покажу скоро. :)

Історія починається так: я написав сам першу версію за допомогою гуглу, існуючих прикладів, обговорень на форумах — ну все як звичайно. І зрозумів, що підхід дуже привабливий, але в спільному (collaborative) редагуванні все ламається. Коментарі зберігаються окремо від документу і синхронизувати їх — гемор.

Зранку подивився на Notion, а вони коментарі зберігають у верстці назавжди, навіть якщо їх зарезолвили. Ну, думаю, супер, зробив якусь першу версію розширення по прикладах, вона працює, але встановлення коментаря за допомогою стандартного API (setMark) просто затирає існуючі коментарі. Ну можна було б це очікувати.

Я собі подумав, що треба зібрати вже існуючі мітки (mark — це термінологія ProseMirror'а для розмітки тексту), і руками змержити, де треба. Типу є мітка такого типу — об'єдную, нема — просто ставлю.

Пішов читати API проузміррора, а воно величезне і я не дуже його шарю. Піду, думаю, спитаю в ChatGPT, цікаво що він зробить. Спитав як знайти всі мітки якогось типу, спитав як їх позиції знайти, а потім думаю — ну до чого оці всі полуміри? Питаю:

> How would I add mark of some type (say comment) to a selection in ProseMirror, appending some identifier if such mark already is set on a part of selection, rather than replacing it?

Не так щоб забагато контексту, да? Ну і він відповідає, з поясненнями, все таке, але зміст зводиться до оцього шматочку кода:

// update the document state with the new mark
const tr = editor.state.tr.addMark(start, end, commentMark);

// preserve any existing comment marks in the selection
doc.nodesBetween(start, end, (node, pos) => {
  const commentMarks = node.marks.filter((mark) => mark.type.name === 'comment');
  for (const mark of commentMarks) {
    if (!mark.attrs.id.includes(uniqueId)) {
      tr.addMark(pos, pos + node.nodeSize, mark);
    }
  }
});

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

І шо ви думаєте? Працює!

Дивні відчуття з того приводу, не можу зформулювати. Код доволі ефективний, здається. Круто, круто. Висловлюйте свої думки. 😁

UPD. Походив тут, подумав:

0. В деталях воно провтикує. У сенсі що я переписав майже увесь код, що воно згенерувало. Ну ми й так вже всі знаємо, що ML — це не про те, коли тобі важливі деталі.
1. Але основні моменти — doc.nodesBetween, node.marks та tr.addMark — це і є головна користь. Напевно десь в інтернеті є оця комбінація, але знайти пошуком мені її не вдалося. Я тому і пішов спочатку інший спосіб реалізовувати, бо ідей, що робити з мітками — не було.
2. Без мого розуміння, що робити, з нечіткими запитами — згенерований код теж був фуфлом беззмістовним. Постановка задачі потрібна, короче. Та сама історія, що з програмуванням: від ідеї до реалізації прірва роботи. А ChatGPT тут допомагає частинку прірви засипати.

Напевно, я excited з приводу того, куди рухається професія. Думати над ідеями мені подобається більше, ніж долбатися з розбиранням, який апі як треба використати. 😁

Панове, потребую вашої допомоги, бо я зі своїм стартапом якось забуксував. Хочу знайти когось, в кого болить — читайте далі для подробиць.

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

Це генерує багато невеличких, термінових, не дуже інтелектуально навантажених завдань. Термінових, бо розпродаж через тиждень, а з нативними апками ще треба релізнути і дочекатися, поки вона оновиться. Всі спрінти і недороблені задачі коту під хвіст. Ну й плюс зміни ці зазвичай у місці, якого майже не торкається основна розробка — лендінги, онбордінги, пейволи тощо.

Я навіть знаю команду, де "задачі монетизації" використовувалися, як покарання — бо ніхто не хоче цим займатися. Воно одноманітне, нудне, і зазвичай йде у смітник через кілька тижнів.

Маркетингу теж не так щоб солодко. За кожну ідею треба воювати, затримка на реалізацію не 15 хвилин, а тиждень, стосунки з розробниками не фантастіка і вмовити їх на щось цікаве — біль.

Я хочу зробити для того рішення — у вигляді ліби/фреймворку, адмінки, і чого там ще потрібно буде — яке дасть змогу керувати верхньорівневими компонентами. У сенсі компонентами конкретної апки, а не абстрактними кнопки/картинки (як мінімум для початку). Ну й всім сумісним — А/Б тестами, прев'ю змін, що там ще прийде в голову.

Тож я шукаю проєкт, де є така проблема. Якщо ви б не проти її вирішити, проте ніколи немає на те часу — зв'яжіться зі мною, поговоримо, га? :) Або може у ваших знайомих такі трабли, направте їх в мою сторону. Англійська мова ок, якщо шо. 😁

Тисячоліттями диктатури знаходилися в кращому становищі під час конфліктів та війн. У Римський республіці, наприклад, самі собі призначали диктатора під час кризисних ситуацій. І наш випадок — яскравий тому приклад останні 400 років. Можна ще поглянути на історію стосунків Москви та Новгорода, а також почитати про розділи Речі Посполитої.

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

І тому в перший раз за 4 сторіччя в нас є не просто шанс, а мало не шлях. Складний, болючий, засмічений ворожою пропагандою, але все одно зрозумілий.

Бажаю нам всім перемоги, а росії згоріти в історії.

Moskovia delenda est. 🔥

Я не планую використовувати канал у якості джоб-борди, але за мною невеличкий борг, тому тримайте. :)

В мене є знайомий iOS-ник, який шукає роботу. В нього вже десь близько 20 років досвіду (руки чухаються дописати "з айосом", ггг) — а він досі не кинув цю справу, тож точно ненормальний і точно треба брати. 😁 Мені пощастило з ним працювати на початку кар'єри (моєї), а потім я його вмовив прийти до Касти — і це був супервдалий хід. Я йому того ніколи не казав, але мені його підхід до роботи допоміг зовсім інакше подивитися на мобільну розробку, на аналітику і на взаємодію з маркетингом.

Тож якщо вам треба не просто робочі руки, а робочі руки з головою, це ваш шанс. 😁 Каже, що цікаві різні варіанти співпраці, не тільки фултайм, так що не соромтесь, пишіть. Звати Зореслав, пишіть на me@zoreslav.com.

P.S. Більш формальну історію можна подивитися на Лінкедині коли є охота.

TwinSpark.Morph

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

Таке буває, коли тобі треба вже проблему вирішити, а не архітектуру будувати, ти ногами якось запинуєш — головне, щоб працювало. Worse is better.

На моє щастя, це була не мій біль, тому я міг дозволити собі маринацію. 🤣 Короч, прийшло натхнення, і я пішов будувати солюшен.

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

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

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

Тобто у мене при змінах у формі валідація, а при сабміті — і валідація, і сабміт. Запит для сабміту вже полетів, але приходить назад — а його рідна форма десь вже просто в замиканні зависла і гудбай. Uphill battle. Абсолютне відчуття, що ти в дитинстві йдеш у школу і назад у завірюху вгору в обидві сторони. 😡

Піду, думаю, подивлюся ще раз на idiomorph. Не зря ж його чувак написав, повинен вирішувати всі трабли. А він наче й вирішує, але розміром більш ніж половина ТвінСпарку. 🐸 очевидно придавила мене, і я в найкращих традиціях NIH взяв і написав заново. 🎉

І вийшла чверть. Без жартів, 250 рядочків, і це навіть з деякими доробками. Мабуть, чувак джавіст, бо деякі місця ну дуже розлаписті (я йому навіть пул реквест заслав, хехе). Ну і я пару довгих, але нерелевантних, моментів пропустив — типу парсінгу хтмлю (в мене вже готовий елемент), чи оновлення тегу head (ну здається що вже зроби повний релоад, та й все).

І я щось так пройнявся результатом, що зняв відео про те, як працює алгоритм морфінгу (і про прикольні анімації). 😁 Enjoy!

‌Пару років тому — після десятиріччя погроз — Google нарешті почав враховувати Core Web Vitals у ранжуванні. В них, якщо ви пам'ятаєте, сайт PageSpeed займався тим, що підказував "найкращі практики", як YSlow колись: зроби менше джаваскриптів, збери в один файл цсс, дуже все базове.

А потім вони його навчили більш серйозним речам і придумали три метрики перформансу сайту:

• LCP — скільки часу до того, як на екрані з'явиться більшість фінального результату
• FID — затримка від кліка до того, як браузер почне щось робити
• CLS — % зміщення контента (під час завантаження)

У останньому вони може хотіли б і загалом міряти, на web.dev дуже кльова іллюстрація того, як зміщення контенту бісить, але це трохи складнувато повторювати.

Метріки доволі непогані насправді, і були однією з причин, чому я наважився Касту з реакту на твінспарк перероблювати — гугл її і так пеналізує за бізнес-модель, а ми ще й додаткові проблеми створюємо. Міряти це все, правда, гемор — спеціальна тулза під назвою Lighthouse (яка наче бекенд для PageSpeed) дуже широкий розброс дає, прям важко щось зрозуміти.

Натомість ми зробили собі CI, який раз на тиждень важливі нам сторінки кілька разів проходить Lighthouse'ом, і постить зранку інтегральний бал і посилання на подробиці у Слак. Що важливо, воно не десь в дешборді, який звичайні програмісти ніколи не відкриють — воно прям в них очевидно на очах прилітає, і коли значення того балу значно змінилося, то в кожного виникне питання, що там. Але треба стежити, щоб не зламалося, коли ти ламаєш перформанс — бо буде як на скріні Касти в грудні. 🤣

Продаж цієї історії бізнесу прямолінійна: конверсія, SEO-трафік, приємність для клієнта (вище шанси попасти у звички), новий сегмент клієнтів із повільними девайсами. Ну короч, перформанс — штука важлива.

Ну і є ще кльові чуваки treo.sh, які фактично продають отой CI, що я описав. І ще на шару дають симпатичний інтерфейс до бази вимірювань Гугла, тож можна легко подивитися, що робиться із сайтом останній рік. Дуже цікаво, ось подивіться скріншот. :-)

Люди антикрихкі

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

Якщо задуматися, це дуже логічно: треба навантажувати м‘язи, щоб вони не атрофувалися, треба навантажувати мізки, і треба навантажувати силу волі.

Що дивно — м‘язи це загальновідома історія, мізки так собі, десь на рівні «після 60 хоча б треба кросворди розгадувати», а все інше взагалі вважається іншим.

Про силу волі я багато разів читав думки, що вона як ресурс: витрать більше на те, щоб не валятися у ліжку зранку, і тобі не вистачить потім її, щоби втриматися від солодкого ввечері.

При тому всьому згадайте оточуючих — найбільш жаліються на «не можу стриматися від булочки» ті, хто і так не сильно напрягається.

А з енергією є цікаве підтвердження у думці, що «найкращий відпочинок — зміна заняття». Бо тупити в екран і нічого не робити не призводить до бажання щось різко почати робити через тиждень. І навпаки, коли напружено працюєш, то через кілька днів відпочинку в отпуску вилазить бажання кудись бігти.