Cіпласпластик


Гео и язык канала: не указан, не указан
Категория: не указана


🇺🇦
Зворотній звʼязок: @gooro0

Связанные каналы

Гео и язык канала
не указан, не указан
Категория
не указана
Статистика
Фильтр публикаций


До речі, якщо вже мова зайшла. На останньому The Game Awards, який відбувся в грудні 2023-го, традиційно анонсували багато нових ігор. Цього разу, до речі, кількість тих, хто дивився церемонію в прямому ефірі, була більша, ніж у всіх Оскарів, Золотих Глобусів та інших кіношних заходів разом узятих. Але мова не про те.

Там японка анонсувала свою гру з отаким бадьорим та динамічним трейлером. Зацініть 😉

Хз, що буде за гра, але саундтрек — це ONUKA авжеж. Було дуже приємно почути )) Посилання на повну пісню.


Якщо ви користуєтеся #Spotify, то скоріш за все відчуваєте той самий біль, що і я: щотижня в кляті рекомендації на кшталт Discover Weekly потрапляє росіянське лайно: якесь виття однотипне, надиктовка віршів під музику тощо. Не брехатиму, що раніше не слухав росіянське, але останні роки аж тіпає від нього. У мене вже настільки чутливість розвинена, що я їх навіть англійською одразу розпізнаю в більшості випадків.

Виявляється, проблема загальна. У когось терпець урвався, і він звернувся до Spotify. Якщо є змога, поставте там хоча б 👍, будь ласка. А то можна і коментар лишити, як натхнення прийде.


#Qt 😢

76 0 0 35 10

До речі буквально позавчора #Arc інтегрував #Perplexity до себе в список стандартних пошукових систем. Ті, хто в Perplexity AI домовляються з іншими щодо співпраці, явно не сидять без діла.


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

Інша проблема — стало нудно, ліниво й нецікаво пробувати щось «нове». І нове тут саме в лапках, бо з часом починаєш зауважувати, що більшість «інновацій» ти вже десь бачив. Із софтом ще гірше — навіть оновлюватися нерідко лячно, бо ризик щось поламати давно переважає хвилювання від нової фічі. Тож виходить, що з early adopters я перейшов до majority. Відчуваю себе дідом 👨🏻‍🦳

Проте зрідка ще балую себе. Останніми двома пристроями, що я передзамовив в ту ж мить, коли про них дізнався, були DJI Osmo Pocket та Nintendo Switch. Жодного разу не пожалкував. Цього разу без вагань не обійшлося, але передзамовив собі Rabbit R1.

Про цей пристрій не написав тільки лінивий, але достеменно ніхто не тямить, що воно таке та як працюватиме. Наскільки я розумію ідею: ви створюєте хмарний обліковий запис, підвʼязуєте до нього сервіси, якими користуєтеся, на кшталт Spotify, Uber, YouTube, Airbnb тощо, а потім через пристрій спілкуєтеся з так званою LAM (Large Action Model), яка виконуватиме те, що ви її попросили.

«Ну й шо?» — скажете ви, — «Нащо мені окремий пристрій для ChatGPT?»

Тут річ у тому, що ця LAM на відміну від LLM навчена (як вони кажуть) не тільки відповідати на запитання, але й якісь дії виконувати, причому робити так, як це робила б людина, а не як робить компʼютер. Іншими словами, вони таким чином намагаються розвʼязати проблему (не)доступності або закритості API, що насправді доволі цікаво ідейно. Якщо опустити авжеж той факт, що десь в клауді буде існувати щось залоговане під вашими обліковими записами. (А ще чекаємо на всратіші капчі на сайтах та щоденні релогіни через код з смс «заради нашої безпеки», ага).

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

Тут цікавий момент. Вони пишуть: no subscription required 🤔 А ми з вами знаємо, що зараз всі LLM доволі збиткові, навіть ті, що з передплатою. Бізнес з таким пристроєм не побудуєш короч. А значить, це не є їхній продукт. Я вангую, що Rabbit R1 зробили таким помітно яскравим та взагалі випускають з однією метою: отримати більше користувачів, які навчатимуть їх LAM.

Вони до речі оприлюднили днями інфу про співпрацю з Perplexity. Я про останніх майже нічого не чув. Памʼятаю тільки, в них ніби Безос інвестував (бо Алексу свою проїбав 😂). Але ось як раз десь пару днів користуюся. Непогана штука, коли треба знайти та узагальнити інформацію з якогось питання з декількох джерел. Фактично те, чим мав би стати Bing з їхнім Copilot.

Цікавий момент №2. Як виявилося, передзамовникам R1 з перших 10 батчів (по 10к одиниць, я так розумію) Rabbit дає ваучер на 200$ для #Perplexity 🤑 Тобто фактично річну передплату. Одразу дає — у мене вже є. З розрахунку стандартних 10 місяців + 2 безплатних виходить 20$ на місяць, тобто та ж передплата на ChatGPT Plus. Іншими словами, сам пристрій — «безплатний» 😅

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

І мене так задовбало для будь-чого анлокати телефон, зачиняти останню відкриту прогу, шукати потрібну, запускати її, шукати та робити щось вже в ній — словами не передати! (Хоча чувак на імʼя Golden Krishna зміг у своїй книзі до речі). Тож вирішив я спробувати мати окремий пристрій для цього. Потім розповім вам, чи це скам.


Нікому не треба інвайт на бетку #Arc під вінду? Є пʼять штук. Окей, вже немає.
Вони пишуть, що (тільки) сьогодні можна пропушити, щоб не чекати довго. Під мак хз, чи досі потрібен інвайт, чи воно вже загальнодоступне. Але якщо що, то також можу заінвайтити. Тільки мило ваше треба (краще в приват).

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

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


А які взагалі юзкейси шел-скриптів? Нащо люди їх пишуть?

Для автоматизації, ага, але автоматизації чого?

Наприклад, у мене завжди виникала проблема початкового налаштування операційної системи після установки. Ну, ви знаєте… Поставити потрібні програми, підкинути пару конфігів, створити якісь змінні оточення, прописати шляхи. І я, коли ще був на вінді, почав з простого BAT-файлу, який згодом перетворився на #PowerShell-скрипт. Потім набридло це підтримувати авжеж, бо я вінду з нуля ставив раз на пʼять років.

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

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

Обробка даних? Не можу уявити випадок, коли шел-скрипт став би правильнішим рішенням за написання простої програми на #Python.

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

Які ваші юзкейси?


Хотів, було, розповісти вам, як я успішно перейшов з #zsh остаточно на #fish пару тижнів тому, бо останній значно прикольніший: більш людяний синтаксис, легший для сприйняття, ну й в цілому цікавий чи що. Проте на fish я надовго не затримався, бо виявилося, що є ще крутіші альтернативи. Навіть трохи шкода 😢

Колись давно я дізнався про #PowerShell від Microsoft і був до глибини душі вражений, що вони реалізували передачу структурованих обʼєктів замість тексту через пайп, адже і сам мріяв про таке давно 🙂 Але з павершелом врешті не зайшло, хоча я навіть книгу прочитав. Не тому, що він поганий абощо — ні, він навпаки чудовий, а ті, хто стверджує протилежне, просто жодного разу ним не користувалися, мабуть. Мені, наприклад, дуже подобається їх схема імен а ля Verb-Noun. Не дуже лаконічно, зате зрозуміло. Але в якийсь момент я відчув, що для ефективного використання треба глибше пірнати в .NET, а мені воно було не в тему. Та годі про PowerShell.

Я натрапив на Nushell! Він також передає структуровану інформацію через пайп, але є й інші цікавинки. Наприклад, змінні там по дефолту immutable, що спонукає писати в більш функціональному стилі. Загалом відчувається якась атмосфера Haskell трохи. Синтаксис лямбд при цьому скоріше як в Ruby. Іще цей шел не POSIX-сумісний, що безперечно є додатковою перевагою 😉 Окремо варто згадати, що він не інтерпретує вирази, а компілює: з перевіркою типів, нормальними повідомленнями про помилки — з усіма ніштяками отже.

Той факт, що через пайпи передаються структуровані дані, наприклад той же JSON, також означає, що потенційно нарешті не потрібен jq. Я тут щойно погрався і за пару хвилин зміг порахувати кількість рядків коду та ін., що ми написали в останньому тримісячному проєкті:
> let excludes = [**/3rdparty/** **/node_modules/**]
> glob **/*.{cpp,hpp,qml,js} --exclude $excludes | each { |f|
open $f | str stats
} | math sum
╭───────────┬────────╮
│ lines │ 22169 │
│ words │ 44291 │
│ bytes │ 516740 │
│ chars │ 516714 │
│ graphemes │ 516714 │
╰───────────┴────────╯
Серед читачів безперечно є хтось, хто зараз може вийти зі своїм магічним ванлайнером на баші, седі, перлі та wc, що зробить все швидше та легше, але я в них не тямлю і, головне, не хочу, бо вони навіть між собою не стандартизовані ніфіга. А тут я зміг дещо накалякати без сторонньої допомоги чисто після читання пари сторінок мануала та користування командою help.

Спробую пожити з #Nushell як з дефолтним, бо цікава штука.




А знаєте до речі, як так вийшло, що C# як мова значно приємніша за C++? Та бо її автором є Андерс Гейлсберґ, який за сумісництвом також є автором Turbo Pascal (ну й фактично Delphi також згодом). Просто хлопак щось тямить в зручних та приємних мовах програмування.

TypeScript теж його. Так-так, все одна й та сама людина. Чим він наразі займається хз, але до 2020-го активно котрибʼютив саме в TS.


Щойно дізнався від другана, що 1 січня 2024 року помер Ніклаус Вірт — автор мов програмування Pascal, Modula, Oberon, книги «Algorithms + Data Structures = Programs» тощо. Чувак мав величезний вплив на світ компʼютерів — наш з вами світ — за що я його дуже поважаю.

Я памʼятаю, як із задоволенням переходив з Pascal на C, бо «останній більш популярний», «бо ним користуються професіонали», бо «він значно лаконічніший». Мені знадобилося майже 15 років, щоб усвідомити, що як раз-то на паскалі писати було значно приємніше, адже можна було просто дампати думки в код, а потім, що важливо, приблизно так само відновлювати думки з коду.

В той самий час код на C та багатьох його нащадках — це завжди челендж при написанні + челендж при читанні. Не прикольно ж написати щось по-людськи, значно цікавіше, коли
while (*d++ = *s++);
еге ж? Така собі жуйка для мозку. Коли бізнес-задачі нудні, треба знаходити собі джерело дофаміну.

От і виходить, що довгий час індустрія розвивалася коштом позерів (типу мене), які на рівному місці вигадували собі проблеми, а потім героїчно їх вирішували. Навіть жарт був, памʼятаю: «те, що було насилу написане, і читатися мусить насилу». Згодом, щоправда, виявилося, що це не зовсім і жарт для багатьох.

Отож, пане Вірте, ми все проїбали. Принаймні в боротьбі зі складністю.

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

І дивлячись на софтварні «досягнення» останніх десятиліть, звучить вельми переконливо.

Але не переймайтеся, часи порівнянь C та Pascal позаду. Нині складність з мов програмування перейшла на рівень вище — на рівень архітектури, фреймворків, систем, сервісів, кластерів та клаудів. Тепер заживемо ☺️


На жаль піти на свята з відчуттям відсутності незакритих питань не вийшло все одно. Клієнт, якого я просив десять разів підготувати всі документи заздалегідь і якому я надіслав реліз-кандидат заздалегідь, декілька днів після фінального делівері мовчав, потім в останній день написав «I'll confirm the acceptance today» (замість просто «accepted, bro» — в чому сенс взагалі?!), а потім авжеж не написав, поставив авто-реплай та пішов у відпустку до середини січня 🤡

Врешті надвечір він-таки згадав, написав мені в зовсім інший імейл-тред, мовляв, ось тобі підписаний delivery protocol, та прикріпив до листа старий файл за жовтень 🤡🤦

Повнісінька зневага до праці інших людей. Не робіть так.


Скільки часу треба, щоб побудувати ефективну команду?

У нас на це пішло близько трьох років. (Насправді менше, я думаю, але «докази» у вигляді чітких результатів зʼявилися тільки зараз).

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

Втім нещодавно нам випала нагода зробити ще один новий продукт з нуля у вельми стиснуті терміни — за три місяці. По естімейтах ніби все виходило ок, хоча план і був доволі щільний та амбіційний. Ми почали на тиждень пізніше, бо знов затрималися з попереднім проєктом, а скінчили десь на тиждень раніше! Дуже приємно хоч зрідка щось встигати до дедлайнів 😅 Користуючись нагодою, до вашої уваги найкоротший майстер-клас з естимації:
Домножуйте початкові числа на півтора, а краще на два 😉


Командо, якщо ви це читаєте, то дякую ще раз за чудову роботу та приємне спілкування 😊 Пишаюся вами та всім, чого ми разом досягли!

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


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

На скріншоті вище як раз показано, як хтось позначив «основну частину» в доповіді про C++ довжиною в годину 😂

Користуйтеся короч, але памʼятайте, що якщо вам реально подобається зміст відео, то краще справді хоча б поставити 👍. Бо це реально підтримка. У них там конкуренція по метриках — жах ) (Та й тут уподобайки нікому не завадять до речі!)


Якщо раніше я рекомендував уникати префіксів в назвах класів, то чимдалі переконуюся, що з цього треба робити саме правило. Я про оті всі ваші vstring, CString, TString (хто памʼятає?), QString тощо, але не тільки про них.

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

Отже, на прикладі нашої поточної проги для мультимоніторного слайд-шоу (ну, що замовили…): є, значить, у нас модель дисплеїв, доступних в системі. Як вона називається? DisplayModel авжеж. Нормальна лаконічна та зрозуміла назва. Для цієї моделі є відповідна вьюшка, яка створює для кожного елементу моделі делегат. Вгадайте назви? DisplayView та DisplayDelegate, ага. Нє, ну а шо. Ще є DisplayInfo, DisplayIdentificationOverlay і тому подібне.

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


Якщо мова про C++, то можна зробити namespace, і тоді в найгіршому випадку назви будуть: Display::Model, Display::View, Display::Delegate, тобто всього на два символи : більше — а в найкращому можна зробити по місцю використання using namespace Display, а далі просто писати Model, View та Delegate. Зазвичай в книжках не рекомендують писати using namespace, бо новачкам легко налажати, але при зваженому використанні це дуже корисна конструкція. Наш поточний підхід полягає в тому, що в cpp-файлі з реалізацією класу ми прям одразу пишемо using, або в деяких інших місцях в тій самій бібліотеці, але не в інших місцях використання. Іншими словами, якщо ти в контексті предметної області, то можна писати короткі імена, а якщо зовні — то повні.

В #QML того самого можна досягти за допомогою qualified imports. Наприклад, маючи модуль під назвою display, можна імпортувати його в глобальний скоуп імен через import display і писати всюди Model, View та Delegate, але QML трохи всратий в цьому плані, бо дозволяє… ммм… to shadow (затіняти?) імена з раніше імпортованих модулів і навіть не пише ворнінг. Тож краще одразу імпортувати як import display as Display або навіть import display as D, якщо надто впадлу, і тоді імена компонентів перетворюються на D.Model, D.View та D.Delegate відповідно.

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

В ідеалі авжеж хотілося б мати тулзу, в яку можна зашити всі свої правила іменування та організації коду, причому не тупі банальності на кшталт «змінні з маленької, класи з великої» або «camelCase, а не snake_case», а щось глибше, як-от «короткі назви всередині ліби — повні назви зовні».




Видео недоступно для предпросмотра
Смотреть в Telegram
Інколи навіть в лінуксі можна побачити щось прийнятне на вигляд. На днях натрапив на тайловий композитор під Wayland — Hyprland. На плюсах написаний, до речі.


Видео недоступно для предпросмотра
Смотреть в Telegram
Зробили з друганом лібу на С++ та байндінги для #QML, щоб керувати Elgato Stream Deck напряму без їхньої офіційної апки (ну й емулятор також на випадок, якщо фізичного пристрою немає). Точніше як зробили… Здебільшого він зробив авжеж, але мені як менеджеру теж можна хизуватись, я вважаю 😇

В імплементації протокола надихалися лібою на Python, яка в свою чергу списувала у ліби на Node.js. Так і живемо 🤷‍♂️

Поки що немає, що ще показати, але як буде більш-менш стабільним, скину посилання.


Тру сторі. (Я належу щонайменше трьом категоріям).


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

Вони прям пишуть приклад:

You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use git-stash to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don’t want to risk disturbing any of it. Instead, you create a temporary linked worktree to make the emergency fix, remove it when done, and then resume your earlier refactoring session.


Я бував в подібній ситуації неодноразово. В деяких випадках я навіть просто робив другий клон рєпи, хоча це не завжди зручно, особливо коли вона важить 20+ ГБ 😅

Користуйтеся на здоровʼя.
#TIL

Показано 20 последних публикаций.

70

подписчиков
Статистика канала