Через 5 хвилиночок стартуємо - https://youtu.be/oLWOD3vwX00
У вас все ще є можливість замутити чаю і покликати знайомих теж подивитися :-)

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

Я пішов робити дві банки — за динамічну і за статичну типізацію — щоб вийшло як у збіра ДОУ розробники вс тестувальники (власне мені Юра і дав ідею). То банки я зробив, а потім перероблювати прогрес бар я трохи обламався, бо за 1 день це не дуже реалістично. 😁 Але! Я примудрився зберегти опис відео з цими двома банками, та й забув про це.

То глючило тому, що частина людей скидала на банки в описі, а частина по QR-коду. Другі трекалися, а перші — ні. 🤣

Проте цікаво, що за динамічні мови прислали 1.6к грн, а за статичні - 14к. :-) Не знаю, чи це репрезентативно, але можливо, що в цілому динамічна типізація менше захоплення викликає. Її використовують не тому, що пре, а як інструмент для досягнення мети.

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

Так, ну ви мож підписані, а мож не підписані, але очевидно посилання на третій епізод Startup talk треба запостити. :) Це я вперше публічно розповідаю про те, чим я займаюся зараз.

Не встиг власного анонса зробити, трохи іншими речами займався останні два тижні, але все в процесі. :)

‌Замітки

Панове, я поламана людина. Я використовую епловські замітки, бо в них кльово зберігати всілякі документи, щось надовго, малювати й взагалі вони нікуди не подінуться (це не точно, але все не точно).

Я використовую Bear.app, бо він швидкий, має шорткати та маркдаун. Ну і виглядає кльово.

Я використовую Ulysses, бо він вміє перевіряти граматику і публікувати в Ghost API — а я написав собі його імплементацію і так шлю пости сюди в телеграм.

Я використовую Notion, бо його просто шарити з іншими людьми, яких немає в екосистемі Епла.

Ну й авжеж трохи заміток валяються просто файлами, які я редагую Імаксом, але зазвичай це за програмування чи ще щось таке.

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

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

P.S. Фоточка згенерована у https://z.lexica.art

‌Драма з Твіттером мені так подобається, не можу навіть слова підібрати. Більшою частиною тим, що там абсолютно кошмарні обидві сторони. 😁

З однієї сторони є неймовірно неефективний Твіттер:

• Неефективно використовують залізо
• Мають неймовірну кількість неефективних людей (уявляю, що б сказав Кармак про Твіттер, хехех)
• Розкидуються грошима на всіляку фігню (типу тої історії, що їжу готувало більше людей, ніж приходило їсти)
• Має дуже поганий менеджмент (а що наколупав там Мадж — це взагалі 🤯)
• Розповідають, які вони круті технологічно, а потім з репорту Маджа і відгуками "та ми взагалі не наймали людей після Твіттеру" я прозріваю з їх хуцпи

З іншої сторони є абсолютно неадекватний Маск:

• Звільняє людей рандомом і намагається взяти їх на роботу назад через тиждень 🤣
• Видає взаємосуперечливі параграфи в найкращих традиціях Дональда Трампа (всім свободу слова, тільки забанимо тих, хто мене бісить, але разбанимо, якщо за них будуть волати, а ще забанимо всіх, хто згадує мастодон, але ні, вже не будемо)
• Приймає найефективніші продуктові рішення (типу галочки за 8 баксів)

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

Маск там запостив голосування, чи потрібно йому залишити пост CEO. Хтось дуже проникливий пише: якщо всі будуть за, скаже що за кілька місяців знайде заміну; а якщо будуть проти, то каже що кілька місяців точно ще побуде, допоки почне шукати заміну. А чутки вже ширяться, що саудіти сказали йому знайти заміну собі для Твіттера і за допомогою опитувань він просто зберігає собі обличчя. 🧌

Не знаю, чи взагалі здатний Маск бути CEO, чи у SpaceX та Tesla йому пощастило з менеджерами, але зіткнення з іншою культурою йому дається максимально складно. Може тому, що він просто-напросто мудак.

А ми новий випуск Startup Talk ще вчора опублікували, обговорили, як ми фейлили стартапні ідеї. :)

Автоінкремент — відстій

Будь ласка, припинить виставляти автоінкрементні ідентифікатори назовні. В урлах, в API, будь-де. З ними погано все:

• Ти видаєш назовні дані про те, скільки в тебе цих сутностей. Можливо тобі взагалі це фіолетово, особливо під час розробки, але бізнес-сторона не скаже тобі дякую потім за те, що всі конкуренти в курсі, як добре йде твій бізнес.
• Ти даєш дуже простий інтерфейс для парсингу всіх даних від тебе: звичайним циклом можна забрати абсолютно все.
• Вони виглядають однаково. Коли в тебе багато сутностей і багато айдішників, в якийсь момент ти в них заплутаєшся. :)
• Жодної семантики в них нема. Коли починається якийсь дебаг з 10-20 різними типами сутностей і айдішників — голова закипає.
• Ти їх видаси у своєму JSON'і як числа і тоді шансів щось змінити в тебе буде обмаль. Трохи нижче про це напишу.

То що ж робити?

• Найкраще — то коли ти можеш виставити назовні щось семантичне, slug. Перетворити у латинку нижнім регістром заголовок поста, назву фільтра чи його значення — це все нескладно, і якщо кількість сутностей дозволяє, нормально працює унікальним ідентифікатором.
• Якщо назва не дозволяє унікальності, можна додати до неї айдішник. Так, першу проблему ти не закриваєш, але всі інші закриваєш.
• Нема якоїсь конкретної назви або треба щось коротке? Візьми hashids, вони закодують твої циферки і якусь сіль у не дуже довгий рядок, і імплементація настільки проста, що є фактично для всього. На додаток, якщо з імплементації вирізати можливість мати списки, то результат ще й трошки коротшим стає IIRC. Плюс можна дати власну абетку, щоб не було схожих літер і простіше було людям прочитати це (для нас цей кейс важливий був, коли люди дзвонили у кол-центр з номерами замовлень).
• Комбінація назви та hashids, щоб таки не палити айдішник назовні.
• Проблему з однаковим виглядом можна, для найважливіших кейсів, вирішити префіксом, або якимось форматом. В Амазона формат номера замовлення \d{3}-\d+-\d+ (вчіть регекспи), в Касти K[\d\w]+, різне можна зробити. Це, до речі, дуже корисно для кількох найважливіших сутностей, коли вони регулярно вилазять в різних місцях, особливо у спілкуванні нетехнічних людей.
• Якщо фантазії взагалі не вистачає, візьми UUID4. Так, він довгий, це неможливо сказати вголос іншій людині, ти їх не будеш розрізняти між собою, але ти хоча б закриєш перші дві проблеми та не будеш видавати зайвих даних на волю.

Про числа. Всі фронтендери поділяються на два типи: тих, кому пофіг на типізацію (жс), і тих, хто робить життя людей нестерпним (всі інші). Уявімо, що ви писали першу реалізацію якомога швидше і всюди повидавали айдішники. А потім захотіли з них переїхати на що завгодно: на префікси, на base64, на UUID. Але не можете, бо всі клієнтські апки ваші айдішники розбирають як число і строку туди не підкласти ніколи. Для міграції залишається дві опції — від'ємні числа і якась хитра арифметика (додайте трильйон і сподівайтеся що ваші клієнти розумініші за int32 🤣).

Тому ніколи — чуєте, ніколи — не віддавайте ідентифікатори як число. Зробіть {"id": str(id)}, тоді у вас будуть шанси у майбутньому. Тим паче якщо ви віддасте їх як число, якийсь дуже розумний™ фронтендер десь помітить закономірність і щось оптимізує. Чи то швиденько пагінацію свою намутить (до речі, використовуйте курсори), чи ще якоюсь арифметикою займеться (деякі події зі свого життя я навіть не хочу розповідати 😅).

Найголовніше. Який би ти айдішник не згенерував, обов'язково запиши його в базу. Не треба оцих муток "я в апі розберу hashid назад у цифру і зроблю запит по ній", це, по-перше, довше, а, по-друге, ти задовбешся шукати руками в базі, логах та обмінах повідомленнями. Просто консистентно ідентифікуй всюди цю сутність її айдішником. Може і FK на цей айдішник варто робити, тут вже я не певен. :)

Оце я розумію! Хоча здається трійки попереду не вистачає, а? :) Було б як у Back Orifice (я тоді в 99 перший раз це зустрів).

Пс сорі за повторні нотіфікашки, шарити в канал не можна, бо телеграм бо зна шо робить.

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'ом всю ту двіжуху.