Technology
Bite the Byte
Technology
01.04.202506:00
Панове, як ви, готуєтеся, поки вас штучка-інтелект замінить? Мені здається, що нікуди діватися, тре роздупляти курсор чи там хоча б aider який, щоби не стати раптом “нещодавним минулим”. 🤷♂️ Я вже іноді користуюся aidermacs’ом (вже хтось написав мод для айдера під імакс, цікаво, чи юзав він при тому сам айдер? 😁) — ну воно зручніше трохи, аніж ото руками копипастити, коли ліньки самому код писати.
Але до вайб-кодінга мені ще далеко, оце відпустити і “пох шо там в коді” я не можу: трохи нагадує, як в кінці 90-х мій дядя із співробітниками починали писати на Дельфі і постійно розглядали, що воно там в бінарному коді генерує, чи не шмарклі собачі!
Але оце наткнувся на цікаве дослідження, що взагалі-то треба просто розслабитися і не паритися зайвий раз, і результати виходять значно ефективніші. Звучить, авжеж, як “британські вчені встановили” (чи те шо це німці спасає ситуацію чи нє?), але загалом ситуація така: через те шо люди напрягаються зрозуміти, чи згенерований код нормальний, і взагалі емоційно реагують на тупняк від AI-агента, вони витрачають купу часу впусту. І невеликі дози алкоголя дозволяють розслабитися і не переживать — і це економить час! Причому пиво (не кажучи вже про більш міцні алкоголі) натупляє занадто сильно, і вони встановили, шо трохи радлера — це саме воно.
Ну ви дивіться дослідження, кароч, а я поки шо дитину в школу відвезу і заодно куплю баночку, тре ж експериментувати, нові часи йдуть. А ви якщо прочитали, поділиться із ближнім своїм, індустрію тре спасать. 😁
Але до вайб-кодінга мені ще далеко, оце відпустити і “пох шо там в коді” я не можу: трохи нагадує, як в кінці 90-х мій дядя із співробітниками починали писати на Дельфі і постійно розглядали, що воно там в бінарному коді генерує, чи не шмарклі собачі!
Але оце наткнувся на цікаве дослідження, що взагалі-то треба просто розслабитися і не паритися зайвий раз, і результати виходять значно ефективніші. Звучить, авжеж, як “британські вчені встановили” (чи те шо це німці спасає ситуацію чи нє?), але загалом ситуація така: через те шо люди напрягаються зрозуміти, чи згенерований код нормальний, і взагалі емоційно реагують на тупняк від AI-агента, вони витрачають купу часу впусту. І невеликі дози алкоголя дозволяють розслабитися і не переживать — і це економить час! Причому пиво (не кажучи вже про більш міцні алкоголі) натупляє занадто сильно, і вони встановили, шо трохи радлера — це саме воно.
Ну ви дивіться дослідження, кароч, а я поки шо дитину в школу відвезу і заодно куплю баночку, тре ж експериментувати, нові часи йдуть. А ви якщо прочитали, поділиться із ближнім своїм, індустрію тре спасать. 😁
29.01.202509:11
Нам треба про це поговорити: українські програмісти не вміють проходити співбесіди. В середньому, авжеж, виключення бувають — але загалом ви, панове, занадто розслаблені.
Ринок розробки в Україні ріс шо дурний — і в людях, і в грошах — так багато років поспіль, що вже більшість людей вважає цю ситуацію нормальною. І від співбесід очікує шось типу “ось моє резюме — а шо складно було на попередньому місці? — ой старався дуже! — ви прийняті!” Відповідно, вважає лайв-кодінг червоним прапорцем.
Але ж це тупня! Знаєте, хто хороший програміст? Той, хто добре програмує! Вміння поговорити за верхньорівневі речі це, авжеж, добре, але доки тобі заважає швидкість написання коду — хороший програміст не ти. 😁 Це, доречі, ще помітно зараз буде вилазити, у епоху ллмів: вони генерують код, який провтикує у нюансах. І час на виправлення у людини, яка бачить код наскрізь і може швидко руками виправити, значно менший, аніж воювання із запитом до ЛЛМа, щоб він знайшов сам в себе баг.
Більше того, лайв-кодінг на співбесіді кльовий ще тим, що він показує, що з тобою буде, коли помре прод: чи ти попливеш від стресу, чи мобілізуєшся?..
Коли мені прийшов інвайт від Метабейза, де написано було “лайв-кодінг”, знаєте, що я зробив? Пішов і витратив години 4 на літкод, просто щоби натренувати пальці. І інтро-задачу (яку ті з вас, хто подавався в Метабейз, бачили) зробив за 7 хвилин.
Так що хочеш бути хорошим програмістом — точи свої скіли, а не жалійся, що рекурсія то складно. 😁
Ринок розробки в Україні ріс шо дурний — і в людях, і в грошах — так багато років поспіль, що вже більшість людей вважає цю ситуацію нормальною. І від співбесід очікує шось типу “ось моє резюме — а шо складно було на попередньому місці? — ой старався дуже! — ви прийняті!” Відповідно, вважає лайв-кодінг червоним прапорцем.
Але ж це тупня! Знаєте, хто хороший програміст? Той, хто добре програмує! Вміння поговорити за верхньорівневі речі це, авжеж, добре, але доки тобі заважає швидкість написання коду — хороший програміст не ти. 😁 Це, доречі, ще помітно зараз буде вилазити, у епоху ллмів: вони генерують код, який провтикує у нюансах. І час на виправлення у людини, яка бачить код наскрізь і може швидко руками виправити, значно менший, аніж воювання із запитом до ЛЛМа, щоб він знайшов сам в себе баг.
Більше того, лайв-кодінг на співбесіді кльовий ще тим, що він показує, що з тобою буде, коли помре прод: чи ти попливеш від стресу, чи мобілізуєшся?..
Коли мені прийшов інвайт від Метабейза, де написано було “лайв-кодінг”, знаєте, що я зробив? Пішов і витратив години 4 на літкод, просто щоби натренувати пальці. І інтро-задачу (яку ті з вас, хто подавався в Метабейз, бачили) зробив за 7 хвилин.
Так що хочеш бути хорошим програмістом — точи свої скіли, а не жалійся, що рекурсія то складно. 😁
23.10.202406:00
Монобанк релізнув (тільки у новому інтерфейсі, правда) маркетплейс. Поки що дуже рудіментарний — три магазини, мало товарів, не дуже кльовий пошук, каталогу поки що нема, але вже рапортують більше 20к замовлень (це я так інтерполюю, ггг). Що заважало стільки замовлень людям приносити напряму до того самого Moyo? Напевно, відсутність Живчика. 😁
Цікаво, що зовнішньо виглядає абсолютно по тому самому рецепту, що й маркетплейс у Приваті — наче і зрозуміло, але якось і різноманіття хочеться, придумайте щось нове? 😁
Я наразі бачу дві серйозні різниці — Монобанк значно менше захаращений фічами відносно Привата і тому “Маркет” буквально легше побачити, плюс — він (Монобанк) банально модний. Не варто, авжеж, недооцінювати дистрибуцію, і на модності самого Монобанку якась аудиторія скоріш за все складеться і в їх маркетплейса. Але треба щось цікаве робити, бо ринок-то не пустий. 😁
Цікаво, що зовнішньо виглядає абсолютно по тому самому рецепту, що й маркетплейс у Приваті — наче і зрозуміло, але якось і різноманіття хочеться, придумайте щось нове? 😁
Я наразі бачу дві серйозні різниці — Монобанк значно менше захаращений фічами відносно Привата і тому “Маркет” буквально легше побачити, плюс — він (Монобанк) банально модний. Не варто, авжеж, недооцінювати дистрибуцію, і на модності самого Монобанку якась аудиторія скоріш за все складеться і в їх маркетплейса. Але треба щось цікаве робити, бо ринок-то не пустий. 😁
14.09.202406:00
Premature Optimization
Ця цитата мене дратує вже десятиріччями, бо її використовують як “виняток підтверджує правило” — не розуміючи оригінальної думки. Повна цитата (по лінку — повна стаття) звучить так:
Small efficiencies, comprendo, amigos? Питання не про перформанс, а про мікро-оптимізації, бо вони дуже пов’язують код, зроблять тобі big hairy mess. Вся ідея в тому, що потурбуйся спочатку про алгоритм, про архітектуру, щоб вона була вдала — а потім будеш займатися оптимізаціями.
Тобто дядько Кнут, до якого посилаються всі люди, яким впадляк очехлитися, як не писати код з N+1, буквально прямо казав — спочатку зроби нормальний алгоритм. О(1) зроби замість О(N), будь ласка, так?
Хороший приклад (кльово шо співробітники не україномовні 🤣): в Метабейзі вирішили зробити зберігання вибраних фільтрів на дешборді для кожного користувача окремо. Технічну доку про це написав фронтендщик, якому очевидно впадляк було щось робити, і він спланував, що зберігання повинно відбуватися під час виконання запиту карточки.
Але на 1 дешборді може бути з 20 карточок, і кожна з них зберігає фільтри. Ще краще, що чувак, який на бекенді це зробив, зробив цикл зі зберігання кожного фільтра. В тебе 10 фільтрів? Вітаю, це 10 запитів в базу.
І ладно б нормально написать було довше, аніж оцю херню зробить, так ні ж, взагалі ні. 1 додатковий новий дуже простий API vs ковиряння у дуже стрьомному місці… Я навіть не знаю, що з цього швидше було б зробити. Так само і N+1, зробити без зайвої сотні запитів при написанні коду — коштує рівно стільки ж часу, але от при пошуку і виправленні в залежності від того які шмарклі піднакопичилися може з’їсти пару днів.
Кайф, що дізнався я (ну й всі інші) про це, бо великі кастомери почали попадати в deadlock’и. Ми, авжеж, зробимо postmortem, і я там теж збираюся виступити з промовою, що адекватна архітектура і увага до перформансу — це взагалі не передчасна оптимізація.
Але і вам шось захотілося розповісти, бо для того щоб шльопати говнокод вже є О1 та Клавдій, а хороший програміст одразу думає про наслідки.
Ця цитата мене дратує вже десятиріччями, бо її використовують як “виняток підтверджує правило” — не розуміючи оригінальної думки. Повна цитата (по лінку — повна стаття) звучить так:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Small efficiencies, comprendo, amigos? Питання не про перформанс, а про мікро-оптимізації, бо вони дуже пов’язують код, зроблять тобі big hairy mess. Вся ідея в тому, що потурбуйся спочатку про алгоритм, про архітектуру, щоб вона була вдала — а потім будеш займатися оптимізаціями.
Тобто дядько Кнут, до якого посилаються всі люди, яким впадляк очехлитися, як не писати код з N+1, буквально прямо казав — спочатку зроби нормальний алгоритм. О(1) зроби замість О(N), будь ласка, так?
Хороший приклад (кльово шо співробітники не україномовні 🤣): в Метабейзі вирішили зробити зберігання вибраних фільтрів на дешборді для кожного користувача окремо. Технічну доку про це написав фронтендщик, якому очевидно впадляк було щось робити, і він спланував, що зберігання повинно відбуватися під час виконання запиту карточки.
Але на 1 дешборді може бути з 20 карточок, і кожна з них зберігає фільтри. Ще краще, що чувак, який на бекенді це зробив, зробив цикл зі зберігання кожного фільтра. В тебе 10 фільтрів? Вітаю, це 10 запитів в базу.
І ладно б нормально написать було довше, аніж оцю херню зробить, так ні ж, взагалі ні. 1 додатковий новий дуже простий API vs ковиряння у дуже стрьомному місці… Я навіть не знаю, що з цього швидше було б зробити. Так само і N+1, зробити без зайвої сотні запитів при написанні коду — коштує рівно стільки ж часу, але от при пошуку і виправленні в залежності від того які шмарклі піднакопичилися може з’їсти пару днів.
Кайф, що дізнався я (ну й всі інші) про це, бо великі кастомери почали попадати в deadlock’и. Ми, авжеж, зробимо postmortem, і я там теж збираюся виступити з промовою, що адекватна архітектура і увага до перформансу — це взагалі не передчасна оптимізація.
Але і вам шось захотілося розповісти, бо для того щоб шльопати говнокод вже є О1 та Клавдій, а хороший програміст одразу думає про наслідки.
15.08.202407:49
Оу, завтикав вчора написати, але ж новий випуск 1-2-3 Techno, з Юрою Ткаченко! Трохи про те, як технарі прозрівають з того що реальний світ працює ще менш надійно, аніж компи, трохи про нормальні технічні теми, не буду спойлити. 😁
24.05.202412:33
Дякуючи Насті ми перервали півроку суто пацанського 1-2-3 Техно, хехе. Біжіть дивитися випуск з нею. :)
20.03.202508:19
Київстар купляє Уклон за 155 млн доларів (97% уклона лиш, але нашо це крохоборство 😁). Це, мені здається, більш цікава покупка, аніж Хелсі — враховуючи, що Уклон вже працює в Узбекістані, то здається що його можна розповсюджувати у всі інші країни присутності Veon’а. Короч, раз все одно КСу гроші нема куди дівати, то здається хорошим ходом.
Цікаво, як воно фінансово виглядає. Вони кажуть що загалом сталося 100 млн поїздок за 2024 рік, а стаття за 2022 рік згадує про 2 млн за місяць. Якщо це екстраполювати до 24 млн за 2022 рік, виходить що вони двічі подвоїлися кожного року. Дуже круто для таких масштабів! Якщо пошукати в інтернеті, то поїздки коштують від 160 до 400 грн (disclaimer: я заюзав діпсьорч Грока, ліньки самому шукать, але якщо є кращі дані, то давайте), вони з цього забирають відсотків 20, враховуючи бонуси, то давайте уявімо щось типу в середньому 50 центів доходу з 1 поїздки.
Тоді ціна здається не дуже високою: компанія росте 2х, має непогані доходи, але мультиплікатор 3х? З іншого боку, вони ж купу грошей вливають в маркетинг (бонуси, власне) і якщо я дико промазав, і доход з поїздки 20 центів — тоді мультиплікатор 10х і це прям огого. 😁
От думаю десь між цими двома крайностями знаходиться реальність. 😁 Якщо хтось захоче розповісти інсайт (без зовнішніх посилань), обіцяю не публікувати. 😁
Цікаво, як воно фінансово виглядає. Вони кажуть що загалом сталося 100 млн поїздок за 2024 рік, а стаття за 2022 рік згадує про 2 млн за місяць. Якщо це екстраполювати до 24 млн за 2022 рік, виходить що вони двічі подвоїлися кожного року. Дуже круто для таких масштабів! Якщо пошукати в інтернеті, то поїздки коштують від 160 до 400 грн (disclaimer: я заюзав діпсьорч Грока, ліньки самому шукать, але якщо є кращі дані, то давайте), вони з цього забирають відсотків 20, враховуючи бонуси, то давайте уявімо щось типу в середньому 50 центів доходу з 1 поїздки.
Тоді ціна здається не дуже високою: компанія росте 2х, має непогані доходи, але мультиплікатор 3х? З іншого боку, вони ж купу грошей вливають в маркетинг (бонуси, власне) і якщо я дико промазав, і доход з поїздки 20 центів — тоді мультиплікатор 10х і це прям огого. 😁
От думаю десь між цими двома крайностями знаходиться реальність. 😁 Якщо хтось захоче розповісти інсайт (без зовнішніх посилань), обіцяю не публікувати. 😁
21.12.202416:16
Я закругляю свій забіг по Advent of Code, але всі відео залишилися на ютубі (окрім першого на твічі, яке загинуло від твічових гнусних налаштувань), і я їх всі зібрав у плейліст. Окрім того, два шматка я вирізав окремо: в одному я пояснюю, як ми порішали другу частину 17 дня — та що про інтерпретацію кода, дуже цікава задача, прям раджу подивитися. А в іншому експромтом трохи розповідаю про свій сетап Emacs’а — але я частини передивлявся, поки вирізав, і воно нажаль доволі сумбурне. :-)
Доречі, якщо вам цікаво ще щось почитати на тему, пан Сергій у своєму каналі Сіпласпластик намагався вирішити кожну задачу новою мовою, ледве не на кожну задачу окрему. :-)
P.S. Робити нормальні тамбнейли ніяких сил нема. 😁
Доречі, якщо вам цікаво ще щось почитати на тему, пан Сергій у своєму каналі Сіпласпластик намагався вирішити кожну задачу новою мовою, ледве не на кожну задачу окрему. :-)
P.S. Робити нормальні тамбнейли ніяких сил нема. 😁
11.10.202407:08
Я шось думав над інтро і якась фігня виходить, тому просто йдіть дивіться новий 1-2-3 Techno, із Сергієм Ковалем. Інтро, як ми познайомилися 22 роки тому, є всередині, не буду повторюватися. 😁
По назві відео і позавчорашньому посту може здатися, що це заплановано, але ні, це неймовірний збіг обставин. Або просто консистентність у підходах. 🤣
По назві відео і позавчорашньому посту може здатися, що це заплановано, але ні, це неймовірний збіг обставин. Або просто консистентність у підходах. 🤣
06.09.202408:02
Забувсі написать, але я тут сходив на подкаст fwdays! Теми відносно для мене звичайні, мікросервіси/моноліти, AWS vs залізо, я думаю що мою думку ви всі знаєте, але обговорення вийшло непоганим. :)
P.S. Куди б ще сходити? Покличьте мене! 😁
P.S. Куди б ще сходити? Покличьте мене! 😁
13.08.202408:00
Не можу перестати думати за статтю “The best, worst codebase” — вона починається як звичайна розповідь людини, яка попала в страшнющу, але живу і прибуткову, кодову базу: скінчилися колонки в таблиці, якийсь там календар, який заповнюють руками інтерни, ну кароч, читати дуже смішно. :)
Але одна думка зачепила мене дуже, процитую:
Типу незрозуміла кодова база призвела до того, що вони всі релевантні шматочки розвели і колупалися в них, і працювали в них фактично індивідуально — через це менше синхронізації, переживань про майбутні покоління і як результат продуктивність.
З іншого боку, недавно тут слухав історії, як великі українські компанії використовують Node-RED як платформу для автоматизації бізнесу, і це ж трохи схожий кейс, де ти кожен крок та/або кожен бізнес-процес можеш сидіти вилизувати скіки завгодно не пересікаючись із іншими людьми взагалі.
Aside: Node-RED, n8n та інші схожі продукти (якщо у вас є улюблений — розкажіть, чому, в коментах) — це коли окремо пишеш шматочки коду, а окремо потім, у візуальному інтерфейсі, будуєш із них ланцюжок, який і робить якийсь бізнес-процес. Воно почалося як спосіб автоматизації IoT, бо там багато маленьких непов’язаних процесів, але ось, як бачимо, область використання розростається.
Так от, про що я думаю — наскільки це живий підхід? Які взагалі проблеми? Дуже б цікаво було послухать людину, яка будувала велику систему із таких наносервісів — що вдалося перемогти, а що ні? Бо ця думка про “будуй собі окремо частинку будинка” дуже привабливо звучить, очевидно швидкість незалежної від інших людини може бути неймовірною.
Плюс, здається, що у ніші автоматизації бізнесу — умовно 1C — UI можна стандартизувати і зробити автогенерованим, щоб не треба були окремі фронтендщики.
Кароооч, давайте свій досвід або хоча б роздуми на тему. :)
Але одна думка зачепила мене дуже, процитую:
But it was remarkably enjoyable to work in. Gone were the concerns of code duplication. Gone were the concerns of consistency. Gone were the concerns of extensibility. Code was written to serve a use, to touch as little of the area around it as possible, and to be easily replaceable. Our code was decoupled, because coupling it was simply harder.
Типу незрозуміла кодова база призвела до того, що вони всі релевантні шматочки розвели і колупалися в них, і працювали в них фактично індивідуально — через це менше синхронізації, переживань про майбутні покоління і як результат продуктивність.
З іншого боку, недавно тут слухав історії, як великі українські компанії використовують Node-RED як платформу для автоматизації бізнесу, і це ж трохи схожий кейс, де ти кожен крок та/або кожен бізнес-процес можеш сидіти вилизувати скіки завгодно не пересікаючись із іншими людьми взагалі.
Aside: Node-RED, n8n та інші схожі продукти (якщо у вас є улюблений — розкажіть, чому, в коментах) — це коли окремо пишеш шматочки коду, а окремо потім, у візуальному інтерфейсі, будуєш із них ланцюжок, який і робить якийсь бізнес-процес. Воно почалося як спосіб автоматизації IoT, бо там багато маленьких непов’язаних процесів, але ось, як бачимо, область використання розростається.
Так от, про що я думаю — наскільки це живий підхід? Які взагалі проблеми? Дуже б цікаво було послухать людину, яка будувала велику систему із таких наносервісів — що вдалося перемогти, а що ні? Бо ця думка про “будуй собі окремо частинку будинка” дуже привабливо звучить, очевидно швидкість незалежної від інших людини може бути неймовірною.
Плюс, здається, що у ніші автоматизації бізнесу — умовно 1C — UI можна стандартизувати і зробити автогенерованим, щоб не треба були окремі фронтендщики.
Кароооч, давайте свій досвід або хоча б роздуми на тему. :)
17.01.202415:13
A/B тести
А/Б тести — дуже зручний інструмент, аби подивитися, які в зробленої зміни будуть ефекти першого порядку. У сенсі на що ця зміна повпливає прямо. Дуже їх зручно використовувати, коли не можеш зформулювати власну думку, або коли є дві конкуруючі, або коли хочеш перевірити, що основні показники не просідають від твоєї зміни.
Але відноситися до них як до святих тек^Hстів — це здається шляхом в продукт для нікого. Або ні для кого, як вам більше подобається?
Це хороший інструмент для пошуку локального максимуму, тобто для покращення існуючих рішень. Коли існуючі рішення перестають відповідати реальності, А/Б тести, на жаль, не допоможуть знайти рішення — занадто великі шанси, що якийсь з прямих показників провисне.
Більше того, вони взагалі не показують ефекти другого порядку. Як ті попапи про “все пропало швидше букай” в букінга, які напряму покращували конверсію в букінг прямо тут і зараз, а через рік випалили користувачів, які взагалі перестали на них реагувати і по можливості уникали букінг через такі сірі паттерни взагалі.
Врешті-решти, тестована зміна чи ні — рішення про її випуск на совісті конкретної людини. Просто з ростом компаній в якийсь момент її менеджмент починає боятися, що розуміння напрямку розвитку у працівників може бути в дуже різному стані, наказує всі зміни пропускати через A/B тести, це потроху стає релігією… І в якийсь момент ми наблюдаємо сторінку товара в Амазона, яку хотілося б якось освіжити, але не можна — святий аб-тест забороняє.
Мораль: A/B тест — не панацея, хоч і хороший інструмент.
07.03.202513:47
Якось думав, що з часом завдяки тому, що в машинах все більше і більше софта, вони повинні ставати все більш схожими: не так вже й складно в дешевих моделях повторювать софтварні фічі дорогих машин, правда? Типу фізичні матеріали авжеж не заміниш, але стеження за полосою може працювати однаково що в машині за 80к, що в машині за 15к. Тим більше що весь інфотеймент заміняє Карплей з айфоном.
Але довелося мені посидіти за кермом новесенького Citroën C4, і шось він мені відкрив очі (база для порівняння: XC60 2017-го року). Скажімо, в ньому є стеження за полосою — тільки верещить воно не в момент, коли наїжджаєш на розмітку, а коли просто починаєш наближатися до неї, за півметра рілі. 😁 І пищить прям неприємно!
Зате адаптивний круїз вміє підрулювати. Тільки він на деяких різких поворотах відмовляється це робити і тоді ти повинен швидко очехлитися і повернути сам. 🤣 Трошки налякав мене, чесно кажучи.
І багато ще таких дрібниць, авжеж (треба було одразу писать, а то зараз в голові тільки думка “та все таке”) — правда, wireless Carplay хапає швидко і достатньо надійно. Це, авжеж, я не згадую фізичну зручність машини, тут мене нове покоління навіть відносно попередніх С4 засмутило.
Так от про шо це я. Так, бренди у мас-маркеті мають змогу найняти більше спеціалістів, аніж дорожчі і менші компанії. Але, схоже, смак в них розвивати не вдається. 🤷♂️
Але довелося мені посидіти за кермом новесенького Citroën C4, і шось він мені відкрив очі (база для порівняння: XC60 2017-го року). Скажімо, в ньому є стеження за полосою — тільки верещить воно не в момент, коли наїжджаєш на розмітку, а коли просто починаєш наближатися до неї, за півметра рілі. 😁 І пищить прям неприємно!
Зате адаптивний круїз вміє підрулювати. Тільки він на деяких різких поворотах відмовляється це робити і тоді ти повинен швидко очехлитися і повернути сам. 🤣 Трошки налякав мене, чесно кажучи.
І багато ще таких дрібниць, авжеж (треба було одразу писать, а то зараз в голові тільки думка “та все таке”) — правда, wireless Carplay хапає швидко і достатньо надійно. Це, авжеж, я не згадую фізичну зручність машини, тут мене нове покоління навіть відносно попередніх С4 засмутило.
Так от про шо це я. Так, бренди у мас-маркеті мають змогу найняти більше спеціалістів, аніж дорожчі і менші компанії. Але, схоже, смак в них розвивати не вдається. 🤷♂️
31.10.202413:21
Подивився тут фантастичну абсолютно демку, де пан Альберт демонструє, які неймовірні можливості можна мати з інтерактивним оточенням розробника. Він у кінці відео каже, що в нього жодних оригінальних ідей в демці нема (ну, може окрім їх комбінування), але це взагалі неважливо: для мене більшість з них була новою і доволі свіжою, а їх комбінація — це взагалі.
Нажаль, що воно — просто демка, але яка ж красива!
Нажаль, що воно — просто демка, але яка ж красива!
09.10.202410:11
Вчора прогулювався по вулиці і натрапив на випуск “Опівночних Балачок” про Golang Madness, про те, як в Го погано. Я люблю пнути Го як і будь-який інший свідомий не-луддит (вибачте, панове гограмісти, ви самі обрали своє життя), але… претензії якось такі поверхневі, що я образився за мову.
Чесне слово,
Короч, більшість претензій рівня “в пайтоні індентація впливає на виконання” або “в ліспах скобка перед назвою функції”, дуже поверхнево. Соромно, пацани! І трохи смішно за переживання, що масив — обмеженої довжини. А як інакше, якщо ти хоч бути ефективною не-високорівневою мовою програмування?
Ладно, за згадку про абсолютно тупий підхід до форматування дат — не соромно. Я пам’ятаю в мене був іспанський сором за цю херню ще коли я перший раз з кимось Го обговорював в 2010 році, і нікуди воно не поділося. Замість використати сішну
От спосіб хендлити помилки нікуди не дівся і він досі абсолютно кончаний. Погано в ньому і те, що
Але є більша проблема, а саме — неструктурована конкаренсі. Коли ти відкриваєш новий проєкт, в якому насобачили каналів і обробки цих каналів, а канали передають кудись невідомо куди (найкращий варіант — канал каналів), то знайти, хто тобі прислав ці дані — іноді дуже важко. Авжеж, можна тримати себе в руках і не передавати канали занадто глибоко (або робити очевидним, що ти робиш), але хто це себе в руках буде тримати?
Короч, те що конкаренсі в Го дуже легко робиться — це плюс, на відміну від інших мов — змушує всіх навчитися цим користуватися. Те, як воно зроблене, і те, що нічого ніхто не змінює і не покращує — це мінус. Ви можете спитати, а де краще? В Джаві краще, авжеж, всі ці ThreadPoolExecutor’и — це і є структурна конкаренсі. Писать не дуже зручно, трохи багатословно, але для того і придумали Кложу, щоб JVM було приємніше користуватися.
Висновки які взагалі? Го — прекрасна мова для написання невеликих програм, де не треба особливої бізнес-логіки, бо вона губиться за всіма
Чесне слово,
fmt - погане скорочення? Ви взагалі C бачили? Чи очікуєте від старих сішників (буквально старих, наймолодшому із лідів проєкта — Робу Пайку — на момент релізу було 55 років), що вони почнуть давати назви на кшталт SingletonBuilderFactory та beginGeneratingDeviceOrientationNotifications? Чи може ти просто любиш Пайтон, який прям “золота середина”, за .format(), що не помічаєш import sys? 😁Короч, більшість претензій рівня “в пайтоні індентація впливає на виконання” або “в ліспах скобка перед назвою функції”, дуже поверхнево. Соромно, пацани! І трохи смішно за переживання, що масив — обмеженої довжини. А як інакше, якщо ти хоч бути ефективною не-високорівневою мовою програмування?
Ладно, за згадку про абсолютно тупий підхід до форматування дат — не соромно. Я пам’ятаю в мене був іспанський сором за цю херню ще коли я перший раз з кимось Го обговорював в 2010 році, і нікуди воно не поділося. Замість використати сішну
%d.%m.%y або джавну dd.MM.yy, вони вигадали нову неймовірну схему із використанням реальної дати як приклада (Jan 1 03:04:05 2006 GMT+7). Про це можна сказати дві речі: по-перше, використання реальних даних як мови для опису даних - відстій. Помилися в тих даних і напиши там 2024 — і не помітиш, і всюди буде 2024. По-друге, це теж поверхнева проблема, тому що strftime є як ліба і все, забудь про свої проблеми.От спосіб хендлити помилки нікуди не дівся і він досі абсолютно кончаний. Погано в ньому і те, що
if err ≠ nil захламляє код, і те, що він абсолютно неструктурний: errors.New(string) приймає рядок, який потім шо, як в коді визначити, яка це саме помилка? Так, ти сам собі можеш організувати структурні помилки, але в бібліотеках, які ти використовуєш, їх не буде, бо це не системна тема, і знач треба шо, в рядок дивитися? Як гограмісти вирішують як хендлити помилку — я не знаю. В джаві є різні типи в помилок, в кложі кожна помилка — несе структуровані дані, всі інструменти для роботи з цим є. Го? такоє…Але є більша проблема, а саме — неструктурована конкаренсі. Коли ти відкриваєш новий проєкт, в якому насобачили каналів і обробки цих каналів, а канали передають кудись невідомо куди (найкращий варіант — канал каналів), то знайти, хто тобі прислав ці дані — іноді дуже важко. Авжеж, можна тримати себе в руках і не передавати канали занадто глибоко (або робити очевидним, що ти робиш), але хто це себе в руках буде тримати?
Короч, те що конкаренсі в Го дуже легко робиться — це плюс, на відміну від інших мов — змушує всіх навчитися цим користуватися. Те, як воно зроблене, і те, що нічого ніхто не змінює і не покращує — це мінус. Ви можете спитати, а де краще? В Джаві краще, авжеж, всі ці ThreadPoolExecutor’и — це і є структурна конкаренсі. Писать не дуже зручно, трохи багатословно, але для того і придумали Кложу, щоб JVM було приємніше користуватися.
Висновки які взагалі? Го — прекрасна мова для написання невеликих програм, де не треба особливої бізнес-логіки, бо вона губиться за всіма
if err'ами: консольні утіліти там, якісь невеличкі мікросервіси тощо. А для серйозної роботи є Clojure. ☝️30.08.202410:44
Прочитав кльову статтю про величезні преси, супер-цікаво. Історія про те, як німцям прийшлося робити преси на 20000 тон тиску і більше, через це в них були кращі можливості будувати літачки. А коли США після війни витратили майже 4 млрд доларів (в теперішніх грошах) на програму по їх побудові, вони одразу окупилися на здешевінні при виробництві B-52.
Більше того, пишуть, що якби не такі неймовірні преси (а вони висотою по кілька десятків метрів), то літаків із баками в крилах просто фізично не було б.
А тема продовжилася, коли Тесла замість збирання підрамників побудувала собі гіга-машину для відливання цілого підрамника за раз — економлячі на цьому купу грошей.
Короч, цікава стаття. І змушує в черговий раз задуматися, як же ж заплетена (будь-яка) індустрія — уряд (ну, військові) США ледве вмовив компанії будувати ці преси, бо боялися, що не буде достатньо попиту.
Більше того, пишуть, що якби не такі неймовірні преси (а вони висотою по кілька десятків метрів), то літаків із баками в крилах просто фізично не було б.
А тема продовжилася, коли Тесла замість збирання підрамників побудувала собі гіга-машину для відливання цілого підрамника за раз — економлячі на цьому купу грошей.
Короч, цікава стаття. І змушує в черговий раз задуматися, як же ж заплетена (будь-яка) індустрія — уряд (ну, військові) США ледве вмовив компанії будувати ці преси, бо боялися, що не буде достатньо попиту.
21.06.202408:08
Як ви там, чекали новий випуск 1-2-3 Techno? 😁 Дмитро дуже крутий чувак, вражає сфокусованістю і різноплановістю, тому і поговорити цікаво було. :)
15.01.202408:40
Кому ютуб ще в п’ятницю не показав, вийшов новий випуск 1-2-3 Techno, більшою частиною про діджиталізацію у нашій державі. В мене було 0 знань, що там у нас відбувається, і тим цікавіше було послухати, тож велкам! :)
17.02.202514:27
Прочитав тут у Вікіпедії, що переклад російською «Кінця Вічності», який я читав у дитинстві — дуже поредагований, щоби прибрати інтимні сцени — звісна річ, тре берегти від цього розуми радянських громадян!
Ці знання мене змотивували і я швиденько запхав собі на телефон оригінал. 😁 Чесно кажучи, розчарований: сцени нічим не краще, аніж у мене в пам’яті, але! Ендрю — головний герой — використовує диктофон із 55 сторіччя. І от це передбачення — чим диктофон з майбутнього краще диктофонів із 50-х (коли книга була написана) — якось ну дуже показовим вийшло.
Диктофон цей вміє записувати на три дорожки по 20 мільйонів слов. Це, уявімо, дуже високоякісний звук, по мегабайту-два на хвилину, то це 200-300 гб на доріжку (якщо брати ~140 слов на хвилину). Найбільша SD-картка зараз — 8 терабайт, але навіть цікавіше про 3 дорожки: очевидно уявлення пана Айзека грає в обмеженнях механічних апаратів, де множення сутностей дається дорого.
Тобто нескінчена кількість файлів в голову не прийшла. :) Зате якість запису неймовірна: можна окремо почути, що кажуть різні люди. Цього в нашому житті і близько немає, якщо тіки не роздати кожному по мікрофону. :)
Де твоя фантазія грає — обмеження фізики заважають, а де реально інновації відбуваються — то обмеження свідомості. :)
Ці знання мене змотивували і я швиденько запхав собі на телефон оригінал. 😁 Чесно кажучи, розчарований: сцени нічим не краще, аніж у мене в пам’яті, але! Ендрю — головний герой — використовує диктофон із 55 сторіччя. І от це передбачення — чим диктофон з майбутнього краще диктофонів із 50-х (коли книга була написана) — якось ну дуже показовим вийшло.
Диктофон цей вміє записувати на три дорожки по 20 мільйонів слов. Це, уявімо, дуже високоякісний звук, по мегабайту-два на хвилину, то це 200-300 гб на доріжку (якщо брати ~140 слов на хвилину). Найбільша SD-картка зараз — 8 терабайт, але навіть цікавіше про 3 дорожки: очевидно уявлення пана Айзека грає в обмеженнях механічних апаратів, де множення сутностей дається дорого.
Тобто нескінчена кількість файлів в голову не прийшла. :) Зате якість запису неймовірна: можна окремо почути, що кажуть різні люди. Цього в нашому житті і близько немає, якщо тіки не роздати кожному по мікрофону. :)
Де твоя фантазія грає — обмеження фізики заважають, а де реально інновації відбуваються — то обмеження свідомості. :)
24.10.202408:24
Панове, ви шось сидите на своїх 5 точках рівно, а Метабейз несамовито наймає. Ми чергу резюме бекендщиків вже привели в нормальний стан, а у фронтендщиків майже, тому будь ласка, якщо ви шукаєте роботу, або думали шукати — велкам. Воно складне — що співбесіда непроста, що код теж буде челленджити (не стільки завдяки легасі, скільки через доменну область), але ж це й треба, вірно?
Для бекенду досвід на кложі не вимагається, але очевидно треба мати хоча б бажання, бо бекенд весь повністю на кложі. Для фронтенду, я думаю, досвід із Реактом потрібен, бо це простіше вимагати.
Одразу попереджаю, якщо ви пару років як почали програмувати і нема як продемонструвати, шо результати розривають, то шансів не дуже багато, нажаль. І загалом співбесіди нетривіальні, хоча й фанові — через це середній вік розробників в Метабейзі помітно за 30 років. 😁 Це я не відпугнути намагаюся, а заманити, насправді. 🤣
Комунікація більше орієнтована на писемний стиль, аніж на зустрічі, ментально переїжджати в часову зону США не треба, зустрічей в тиждень у програміста зазвичай мало, продакти дуже круті і дуже технічні. І весь продукт - open source! Велкам. :)
Для бекенду досвід на кложі не вимагається, але очевидно треба мати хоча б бажання, бо бекенд весь повністю на кложі. Для фронтенду, я думаю, досвід із Реактом потрібен, бо це простіше вимагати.
Одразу попереджаю, якщо ви пару років як почали програмувати і нема як продемонструвати, шо результати розривають, то шансів не дуже багато, нажаль. І загалом співбесіди нетривіальні, хоча й фанові — через це середній вік розробників в Метабейзі помітно за 30 років. 😁 Це я не відпугнути намагаюся, а заманити, насправді. 🤣
Комунікація більше орієнтована на писемний стиль, аніж на зустрічі, ментально переїжджати в часову зону США не треба, зустрічей в тиждень у програміста зазвичай мало, продакти дуже круті і дуже технічні. І весь продукт - open source! Велкам. :)
04.10.202408:06
Дірява телега
Телеграм ламають як дурний. Приходить тобі лінка від когось з контактів “проголосуй за мою донечку” чи ще якась лабудень, клацаєш — і в тебе крадуть аккаунт. Викидають всі твої сесії, і навіть якщо ти логінишся з підтвердженням телефону — телеграм вважає, що сессія нова і не дає викинути взломщиків. А вони через секунду-другу, схоже, в циклі перевіряють, які є сесії, і викидають тебе. Дочекатися поки твоя сессія “подорослішає” не виходить.
А через кілька днів, напевно коли вони всім твоїм контактам відправлять спаму, вони забивають на цей акаунт, то можна залогінитися, дочекатися “дорослішання” і викинуть їх сесію.
Фантастичний юзкейс, правда? Телеграм, очевидно, робить з цим абсолютно нічого — сапорта ніякого нема, зробити нічого не можливо, твій акаунт не твій і взагалі йди в дупу. Встановлення пароля, я так розумію, допомагає від цього, але хто з людей, які клацають на раптову “проголосуй” його встановив?.. Хоча я оце думаю, що я б на якийсь bitly без передперегляду і з описом “блін, заціни шо постгрес творить” і сам би натиснув без проблем 🤣
Що в цій всій історії цікаво — це власне як вони акаунт крадуть? Я не розумію, яким чином натиснення на посилання дозволяє забрати акаунт в телеграмі? Ну це якось тупо, що це взагалі можливо? Візьміть може та й закрийте цю діру?
Ладно б це було щось супер-нове, так ні ж, кілька місяців вже відбувається. Пане Павєл, ну що за бардак у вас тут? 🙄
Телеграм ламають як дурний. Приходить тобі лінка від когось з контактів “проголосуй за мою донечку” чи ще якась лабудень, клацаєш — і в тебе крадуть аккаунт. Викидають всі твої сесії, і навіть якщо ти логінишся з підтвердженням телефону — телеграм вважає, що сессія нова і не дає викинути взломщиків. А вони через секунду-другу, схоже, в циклі перевіряють, які є сесії, і викидають тебе. Дочекатися поки твоя сессія “подорослішає” не виходить.
А через кілька днів, напевно коли вони всім твоїм контактам відправлять спаму, вони забивають на цей акаунт, то можна залогінитися, дочекатися “дорослішання” і викинуть їх сесію.
Фантастичний юзкейс, правда? Телеграм, очевидно, робить з цим абсолютно нічого — сапорта ніякого нема, зробити нічого не можливо, твій акаунт не твій і взагалі йди в дупу. Встановлення пароля, я так розумію, допомагає від цього, але хто з людей, які клацають на раптову “проголосуй” його встановив?.. Хоча я оце думаю, що я б на якийсь bitly без передперегляду і з описом “блін, заціни шо постгрес творить” і сам би натиснув без проблем 🤣
Що в цій всій історії цікаво — це власне як вони акаунт крадуть? Я не розумію, яким чином натиснення на посилання дозволяє забрати акаунт в телеграмі? Ну це якось тупо, що це взагалі можливо? Візьміть може та й закрийте цю діру?
Ладно б це було щось супер-нове, так ні ж, кілька місяців вже відбувається. Пане Павєл, ну що за бардак у вас тут? 🙄
29.08.202407:23
Лок-файли (
Не логічно тільки те, що він існує. Чому жаба змогла 20 років назад просто написати версії в
Ладно
P.S. Всіх хто не вважає що існування лок-файлу — тупня, оголошую носіями стокгольмського синдрому. 😁
yarn.lock, poetry.lock тощо) виглядають такою зайвою ідеєю, просто не можу змиритися з їх існуванням. Треба оновити пакет, редагую package.json, пишу туди ”@slack/web-api”: “^6.12.1”, відправляю на CI, все здихає. Здихає, авжеж, бо там yarn --frozen-lockfile використовується, тобто типу “не оновлюй локфайл під час CI”. Логічно, логічно.Не логічно тільки те, що він існує. Чому жаба змогла 20 років назад просто написати версії в
pom.xml, а всі інші не змогли і тепер придумують файли з версіями залежностей поруч з файлом з приблизними версіями залежностей? Всі ці системи (жс, пайтон, го як мінімум) з’явилися після Мавена, що їм заважало просто вивчити prior art?Ладно
.deb стрьомний всередині, так він перший був, фактично — і RPM вже значно простіший, об’єктивно: вочевидь люди вчилися одне в одного. А з системами залежностей в програмувані якийсь кошмар. Не знаю, чи новий підхід до пайтона (маю на увазі uv etc) виправить ситуацію, бо вона найгірша з усіх… але не заздрю всім користувачам поцоватих рішень (десятиріччями поцоватих, доречі, ось що вражає).P.S. Всіх хто не вважає що існування лок-файлу — тупня, оголошую носіями стокгольмського синдрому. 😁
14.06.202407:39
Apple PCC
Я тут розгриз блог-пост про епловський Private Cloud Compute, і, чесно кажучи, підхід до проблеми вражає. Якщо ви не в темі — Епл робить сервіс для свого Apple Intelligence (отут я ржу капець), і щоб все було дуже приватно і сек'юрно. Але ж якщо просто зробити сек’юрний та приватний сервіс, як це довести? Є кілька проблем з доведенням цього факту:
• Конфігурацію сервера складно верифікувати зовні
• Визначити, який софт відповідає в якості сервісу, складно
• Що робити з адмінами, які можуть все споганити?
Вони використовують купу рішень, і вже існуючих, і нових, для того, щоб це забезпечити. Напишу все списком, бо так багато, що в тексті я сам почав заплутуватися:
1. Сильно звужений ланцюжок постачальників, щоби влізти в нього було дорожче і це було легше поміти.
2. Кожен сервер перед закриванням фоткається з високою роздільністю.
3. Коли сервер прибуває в датацентр, “we perform extensive revalidation” перед встановленням.
4. Для завантаження використовується Secure Boot, який завантажує тільки підписаний софт.
5. Інсталяція софта залишає записи десь? Це я так зрозумів фразу “approved for that specific PCC node”.
6. Що цікавіше, використовується Secure Enclave — так само як в айфонах. Забезпечує сек’юрність і незмінність розділу, де зберігається ОС та моделі. Стежить, щоби завантажений код неможливо було змінити чи підмінити під час виконання. Забороняє JIT, щоб новий код не виникав сам по собі.
7. Операційна система — це власне обрізана iOS/macOS, зі значно зменшеною поверхнею для атаки: наприклад, там немає ні ssh, ні будь-яких інших засобів віддаленого керування.
8. Увесь (новий) код написан на Swift’і, щоби не було питань із безпекою доступу до пам’яті.
9. Під час кожного завантаження Secure Enclave генерує новий випадковий ключ для шифрування диску (на який попадають користувацькі дані) і не зберігає цей ключ нікуди. Таким чином можна бути певним, що після перезавантаження дані на диску прочитати буде неможливо.
10. Окрім цього, кожен процес виконується у sandbox’і, з увімкненим Pointer Authentication Codes — це система, яка заважає підмінювати адреси функцій і адреси повернення (тобто крек для фотошопу в такому середовищі не спрацює 😁).
11. Після виконання дані стираються, а пам’ять, яка використовувалася для їх обробки, періодично очищається — щоб не залишалося якихось обривків тих самих даних.
12. Очевидно, e2e шифрування зробити неможливо — бо сервісу потрібно мати доступ до власне даних. Але кожен запис шифрується публічними (верифікованими під час виконання айфоном) ключами ноди PCC — таким чином жодна прокся/балансувальник їх прочитати не можуть. [Це вони https описали чи шо? Трохи не вистачає порівнянь із загально прийнятими практиками]
13. Всі запити проходять через незалежну OHTTP проксю, щоби епловські ноди не знали, від кого цей запит.
14. Ключі, доречі, не одні на всіх — перед власне запитом клієнт отримує від балансувальника вказівку, куди робити запит. Балансувальник при тому нічого не знає ні про клієнта, ні про характер його запиту — тому не може направляти упереджено.
15. Нагадаю, немає ssh чи ще чогось типу RDP — підписування коду і Secure Enclave теж завадили би запуску зайвого коду, але інтерактивний шел давав би значно більшу поверхню для атак на систему.
16. Інструментарій для спостереження за системою теж дуже обмежений. Скажімо, логи, які покидають машину, задаються заздалегідь, і проходять кілька рівнів незалежного рев’ю для апруву — де стежать, щоби в них не попадали користувацькі дані.
17. Кожен реліз софта для PCC публічний! Бінарна збірка мається на увазі, не джерельний код.
18. Клієнти шифрують свої запити за допомогою тільки тих сертифікатів, наявність яких можна перевірити у спеціальному публічному реєстрі релізів PCC.
Доповнюйте, якщо щось забув (або формулювання невдале) — пост трохи перенасичений повторенням одного і того самого з різних боків, тому я вже почав губитися і не певен, чи все цікаве перерахував. Але, як я вже сказав, масштабність підходу вражає.
Я тут розгриз блог-пост про епловський Private Cloud Compute, і, чесно кажучи, підхід до проблеми вражає. Якщо ви не в темі — Епл робить сервіс для свого Apple Intelligence (отут я ржу капець), і щоб все було дуже приватно і сек'юрно. Але ж якщо просто зробити сек’юрний та приватний сервіс, як це довести? Є кілька проблем з доведенням цього факту:
• Конфігурацію сервера складно верифікувати зовні
• Визначити, який софт відповідає в якості сервісу, складно
• Що робити з адмінами, які можуть все споганити?
Вони використовують купу рішень, і вже існуючих, і нових, для того, щоб це забезпечити. Напишу все списком, бо так багато, що в тексті я сам почав заплутуватися:
1. Сильно звужений ланцюжок постачальників, щоби влізти в нього було дорожче і це було легше поміти.
2. Кожен сервер перед закриванням фоткається з високою роздільністю.
3. Коли сервер прибуває в датацентр, “we perform extensive revalidation” перед встановленням.
4. Для завантаження використовується Secure Boot, який завантажує тільки підписаний софт.
5. Інсталяція софта залишає записи десь? Це я так зрозумів фразу “approved for that specific PCC node”.
6. Що цікавіше, використовується Secure Enclave — так само як в айфонах. Забезпечує сек’юрність і незмінність розділу, де зберігається ОС та моделі. Стежить, щоби завантажений код неможливо було змінити чи підмінити під час виконання. Забороняє JIT, щоб новий код не виникав сам по собі.
7. Операційна система — це власне обрізана iOS/macOS, зі значно зменшеною поверхнею для атаки: наприклад, там немає ні ssh, ні будь-яких інших засобів віддаленого керування.
8. Увесь (новий) код написан на Swift’і, щоби не було питань із безпекою доступу до пам’яті.
9. Під час кожного завантаження Secure Enclave генерує новий випадковий ключ для шифрування диску (на який попадають користувацькі дані) і не зберігає цей ключ нікуди. Таким чином можна бути певним, що після перезавантаження дані на диску прочитати буде неможливо.
10. Окрім цього, кожен процес виконується у sandbox’і, з увімкненим Pointer Authentication Codes — це система, яка заважає підмінювати адреси функцій і адреси повернення (тобто крек для фотошопу в такому середовищі не спрацює 😁).
11. Після виконання дані стираються, а пам’ять, яка використовувалася для їх обробки, періодично очищається — щоб не залишалося якихось обривків тих самих даних.
12. Очевидно, e2e шифрування зробити неможливо — бо сервісу потрібно мати доступ до власне даних. Але кожен запис шифрується публічними (верифікованими під час виконання айфоном) ключами ноди PCC — таким чином жодна прокся/балансувальник їх прочитати не можуть. [Це вони https описали чи шо? Трохи не вистачає порівнянь із загально прийнятими практиками]
13. Всі запити проходять через незалежну OHTTP проксю, щоби епловські ноди не знали, від кого цей запит.
14. Ключі, доречі, не одні на всіх — перед власне запитом клієнт отримує від балансувальника вказівку, куди робити запит. Балансувальник при тому нічого не знає ні про клієнта, ні про характер його запиту — тому не може направляти упереджено.
15. Нагадаю, немає ssh чи ще чогось типу RDP — підписування коду і Secure Enclave теж завадили би запуску зайвого коду, але інтерактивний шел давав би значно більшу поверхню для атак на систему.
16. Інструментарій для спостереження за системою теж дуже обмежений. Скажімо, логи, які покидають машину, задаються заздалегідь, і проходять кілька рівнів незалежного рев’ю для апруву — де стежать, щоби в них не попадали користувацькі дані.
17. Кожен реліз софта для PCC публічний! Бінарна збірка мається на увазі, не джерельний код.
18. Клієнти шифрують свої запити за допомогою тільки тих сертифікатів, наявність яких можна перевірити у спеціальному публічному реєстрі релізів PCC.
Доповнюйте, якщо щось забув (або формулювання невдале) — пост трохи перенасичений повторенням одного і того самого з різних боків, тому я вже почав губитися і не певен, чи все цікаве перерахував. Але, як я вже сказав, масштабність підходу вражає.
12.01.202407:00
В чатіку про стартапи написали за історію з реального світу про бізнес по доставці посилок через кордон. Я так розумію, що ідея була в тому, щоб наявний хаотичний рух організувати і зробити зручним одночасно і для клієнтів, і для перевізників/водіїв — забрати інтерфейсами тертя спілкування, коли тре з водієм домовитися, що, коли, куди, як, де віддати і все таке інше. Ну короч, розумно все. Але:
> Було дивно закриватися, маючи product-market fit. Проблема була в тому, що перевізники не хотіли або ж не могли працювати 100% в білу.
Імхо, це результат зіткнення “програмістського” (for the lack of better word) світогляду з реальним світом. Ну типу цей бізнес побудований на такій кількості перетинів різних проблем, що працювати вбілу не тільки дорого, це ще й аналог італійської забастовки.
Це дуже сумний стан речей, але це наша реальність. Я трошки здаля наблюдав єкомерс середніх (для України) розмірів, який був повністю чорним — їх навіть ніколи не чіпала податкова, бо не знала про їх існування. Тільки вони (на вимогу інвестора) хоч трохи показали потік грошей, як податкова не забарилася нагадати про себе у самий гнусний спосіб.
І, очевидно, стати повністю білими в них варіантів нема — бо їх найближчий (і більший) конкурент просто таки vantablack і тому може дозволити собі бути дешевшим. І все, їм хана.
Найгірше у всій цій історії те, що чесна робота вбілу стає все більш і більш накладною, дякуючи нашим реформаторам з податкового комітету, і тому… не знаю шо тому, тому дуже сумно, от шо. Здається очевидним, що спрощення ведення бізнесу вбілу — і в ідеалі так, щоб ризики ведення вчорну були значно вищими за доходність — було б значно ефективнішою в плані зборів податків стратегією…
Такоє.
Shown 1 - 24 of 62
Log in to unlock more functionality.