Так сталося, що я вже другий тиждень пишу бекенд системи на Java 💻 . До того писав фронтенд на 🕸 + React ⚛️ — це не QML, звісно, але загалом жити можна. А тут в мене тепер дефолтний набір зі Spring Boot та Hibernate. І шо я хочу сказати…
Тяжко! По-перше, Java як мова не альо — прям тухлувато якось. Вона явно стала краща відтоді, як я нею писав востаннє 15 років тому, але на цьому ґрунті нічого хорошого вже не виросте. По-друге, надлишкова інженерія в джаві відчувається явно інакше, аніж в💻 . Я впевнений, що це все не зʼявилося без причини. Певно хтось колись писав систему, набив собі купу синців і сказав: «Треба більше рівнів абстракції». І стало більше рівнів. Ну тобто ми показуємо табличку з БД майже один до одного, але тут repositories, entities, DTOs, mappers й оце все — дуже швидко відчуваєш на собі слово enterprise. Мабуть, і в книжках так радять робити.
Але біс із ним. Справжня ж проблема — це анотації! О-о-о, тут цілий окремий світ. Джаву вивчити легко, але її самої замало. Тут на анотаціях фактично свій eDSL, а точніше навіть декілька — по одному на бібліотеку: всі ці
Річ у тім, що взагалі-то я люблю eDSL! (Якщо хтось не знає: eDSL — це фактично якась зазвичай вузькоспрямована мова, побудована засобами іншої). І люблю мови, в котрих їх можна робити: Ruby♦️ той же, REBOL звісно, та навіть у Python 💻 я декораторами різне цікаве мутив. Це все чудово працює в одному з трьох випадків:
1. Ти створюєш це сам просто зараз.
2. Хтось поряд із тобою створює eDSL просто зараз, а ти його використовуєш.
3. Це стандарт де-факто.
У решті ж випадків це суцільний біль. Мало знати хостову мову: ти дивишся на конструкцію і розумієш, що вона значить синтаксично, але не семантично. Доводиться вчити ще декілька вбудованих мов. Я вочевидь цього поки не зробив, тому відкриваю файл, бачу там один порожній інтерфейс з пачкою анотацій — і нічого не розумію. Відкриваю інший — там те саме. Просто купа напівпорожніх файлів, їй-богу.
А компілятор з цього генерує цілі класи з методами, сам автоматично розрулює звʼязки між ними, щось там ще робить. Ти потім це запускаєш, а воно і до бази якось конектиться, і обʼєкти один в одного переганяє. Жодних конструкторів тобі з прокиданням чогось кудись. Чистенько. Але забагато магії⚡️
Класно, коли магії є трошки — додає цікавинку в розробку. Але не коли ти з 20-річним досвідом не можеш збагнути звʼязки між класами😅 Ну, воно-то зрозуміло, що я це не тямлю, бо я ніколи з цим не працював досі. А от коли сіньор-джавісти кажуть, що не знають, як воно працює, то це трохи підозріло.
Цікаво, чи станеться щось подібне з C++, враховуючи, що в цій мові тепер є reflection. На мою думку, навряд чи. Піду, короч, пірнати у ваш Spring, а ви поки можете глянути на чиюсь стару бібліотеку для C++, яка дозволяє писати отак (так-так, це eDSL):
Тяжко! По-перше, Java як мова не альо — прям тухлувато якось. Вона явно стала краща відтоді, як я нею писав востаннє 15 років тому, але на цьому ґрунті нічого хорошого вже не виросте. По-друге, надлишкова інженерія в джаві відчувається явно інакше, аніж в
Але біс із ним. Справжня ж проблема — це анотації! О-о-о, тут цілий окремий світ. Джаву вивчити легко, але її самої замало. Тут на анотаціях фактично свій eDSL, а точніше навіть декілька — по одному на бібліотеку: всі ці
@Autowired, @Retention, @OneToMany, @JoinTable, @Mapper, @MappingTarget і ще три десятки. Нарешті я втямив, що мали на увазі люди, з якими я спілкувався про недоліки предметно-орієнтованих мов.Річ у тім, що взагалі-то я люблю eDSL! (Якщо хтось не знає: eDSL — це фактично якась зазвичай вузькоспрямована мова, побудована засобами іншої). І люблю мови, в котрих їх можна робити: Ruby
1. Ти створюєш це сам просто зараз.
2. Хтось поряд із тобою створює eDSL просто зараз, а ти його використовуєш.
3. Це стандарт де-факто.
У решті ж випадків це суцільний біль. Мало знати хостову мову: ти дивишся на конструкцію і розумієш, що вона значить синтаксично, але не семантично. Доводиться вчити ще декілька вбудованих мов. Я вочевидь цього поки не зробив, тому відкриваю файл, бачу там один порожній інтерфейс з пачкою анотацій — і нічого не розумію. Відкриваю інший — там те саме. Просто купа напівпорожніх файлів, їй-богу.
А компілятор з цього генерує цілі класи з методами, сам автоматично розрулює звʼязки між ними, щось там ще робить. Ти потім це запускаєш, а воно і до бази якось конектиться, і обʼєкти один в одного переганяє. Жодних конструкторів тобі з прокиданням чогось кудись. Чистенько. Але забагато магії
Класно, коли магії є трошки — додає цікавинку в розробку. Але не коли ти з 20-річним досвідом не можеш збагнути звʼязки між класами
Цікаво, чи станеться щось подібне з C++, враховуючи, що в цій мові тепер є reflection. На мою думку, навряд чи. Піду, короч, пірнати у ваш Spring, а ви поки можете глянути на чиюсь стару бібліотеку для C++, яка дозволяє писати отак (так-так, це eDSL):
using namespace xsmell;
document doc =
_
<html>_
<head>_
<title>"XSMELL demo"<!title>_
<!head>_
<body>_
<p>"Yesssssssssssssssss!"<!p>_
<img .src("chucknorris.png") .alt("sneezing eyes open")>_ <!img>_
<!body>_
<!html>
_;
std::cout << doc << '\n';
Please open Telegram to view this post
VIEW IN TELEGRAM
😁12💯8💊1
Telegram
Мамкін Архітектор
Буває таке: розробник ставить оцінку на тиждень, зникає на чотири дні, і повертається з пул-ріквестом, де коду на три години з перекурами. Потім дуже ображається, коли у нього запитують пояснення, розказує, шо там було складно, він багато думав, і взагалі…
Пан К. у своєму каналі «Мамкін Архітектор» написав днями про довіру в команді, зокрема довіру керівника до виконавця. Історія там така, що гіпотетичний(?) чувак заестимейтив та зробив задачу, але в керівника лишився осад. «Телефон чорно-бєлий, а довжен буть цвітний. Шо мені робить?»
Ну й висновок автора, що варто будувати «zero trust», де кожен завжди під ковпаком (причому так, щоб ніхто цьому не дивувався й не ображався), хоча конкретних методів не дає. Я з певними твердженнями погоджуюся, але загалом маю альтернативний погляд на все це, про який і напишу.
Значить ситуація:
У мене тут картинка якось не склалася. Якщо манагер оцінив, що «коду на три години», то він, певно, тямить. Тоді як він прийняв початкову оцінку в тиждень? А якщо не тямить, то чому зараз береться оцінювати самотужки?🧐 (До речі, статистично доведено, що люди значно більше поважають керівників, якщо думають, що ті здатні виконувати їхню роботу.)
Як хтось написав у коментарях — скрам уже всі ці проблеми розвʼязав, і в чомусь це правда. Інша розмова, що скрам у всіх різний, і мало хто бачив його в канонічній формі, та ще й щоб працював. Принаймні стосовно оцінювання я виніс з однієї з контор чудову пораду.
Оцінювати задачу мусить не той, хто її імовірно робитиме, а вся команда. Якщо команда не пристріляна, то естимейти зазвичай мають нормальний розподіл. Тоді ті, хто дали найнижчу та найвищу оцінки, мають пояснити чому. Це корисно з усіх боків: по-перше, шариться досвід, по-друге, випливають раптові нюанси, про які подумав лише хтось один, по-третє, члени команди вчаться працювати один з одним.
Ідемо далі. «Розробник зникає на тиждень» — це очевидна дурня. Ті ж дейліки винайшли саме для того, щоб такого не було. Взагалі даю пораду програмістам: менеджери завжди мають значно більше задач, ніж фізично можна виконувати. І єдине, про що вони мріють з боку команди — щоб усе йшло за планом. А значить ви як виконавці маєте два обовʼязки: робити все можливе, щоб виконувався план, і повідомляти одразу, щойно він перестав. Тоді керівник має більше простору для маневрів з вищими менеджерами або замовником, а отже відносно задоволений.
Додаткова порада, як уникати зайвих питань «чим займався?»: робіть більше комітів!💡 Почали робити задачу — одразу створили гілку, запушили на ремоут і створили чернетку PR; далі щовечора докидаєте туди те, що встигли зробити. Перший раз манагер спитає, а на другий — піде й сам гляне. Всі задоволені.
Ну й нарешті дійшли до теми про zero trust. Якщо ваша команда — це циферки на дашборді, то може воно й норм, але загалом вважаю такий підхід украй шкідливим. Навіть девіз щойно вигадав: zero trust — zero thrust😮💨
Все йде з культури. В якийсь момент (мабуть, після книжок No Rules Rules та «Принципів») мене осяяло, що якщо ставитися до кожного як до спеціаліста своєї справи, котрими вони і є, (а не як до баранів, котрих треба за мотузку тягати), то вони раптом починають працювати збс, беруть на себе більше відповідальності тощо. В українському айті, на жаль, найчастіше зустрічаються два типи «менеджерів»: учора-програміст, на якого навалили купу задач з керування командою за додаткові пів гривні на рік, або той, хто дорвався до влади й починає всіх дойобувати. Школа менеджменту фактично відсутня. Мені ж більше імпонує тема про servant leader й оце все.
Щоб це працювало, керівники мусять давати більше інформації. (Згадайте, як ваш менеджер відміряє вам крихти інфи, наче в аптеці). Коли в людей є достатньо даних, щоб сформувати ширшу картину того, що є й чого треба досягти, вони починають знаходити значно ефективніші рішення. Окрім інформації треба давати ще відповідальність+авторитет. Перше треба для того, щоб працівник був умотивований досягати результатів (і отримував за це дофамін), а друге, щоб у нього були потрібні засоби. Очевидно, що на «нульовій довірі» це все не працюватиме. Навіть навпаки: треба дуже багато довіри.
А от куди zero trust добре пасує — так це до себе. Щоразу, як вам здається, що ви знаєте щось краще, спитайте себе, а чи дійсно ви довіряєте своєму судженню і чи не сліпа це довіра.
Тепер якщо ще раз перечитати оригінальний допис, на який я посилався на початку, то можна побачити дуже багато спільних рис і висновків з декількома важливими відмінностями. Та в одному, я думаю, ми б точно дійшли згоди: треба вибудовувати здорові взаємини в команді. Це важко й довго, але воно точно окупиться. А бракованих цеглин краще позбуватися🙂
Ну й висновок автора, що варто будувати «zero trust», де кожен завжди під ковпаком (причому так, щоб ніхто цьому не дивувався й не ображався), хоча конкретних методів не дає. Я з певними твердженнями погоджуюся, але загалом маю альтернативний погляд на все це, про який і напишу.
Значить ситуація:
[…] розробник ставить оцінку на тиждень, зникає на чотири дні, і повертається з пул-ріквестом, де коду на три години з перекурами. […] Лишається відчуття, що тебе трошки намахали…
У мене тут картинка якось не склалася. Якщо манагер оцінив, що «коду на три години», то він, певно, тямить. Тоді як він прийняв початкову оцінку в тиждень? А якщо не тямить, то чому зараз береться оцінювати самотужки?
Як хтось написав у коментарях — скрам уже всі ці проблеми розвʼязав, і в чомусь це правда. Інша розмова, що скрам у всіх різний, і мало хто бачив його в канонічній формі, та ще й щоб працював. Принаймні стосовно оцінювання я виніс з однієї з контор чудову пораду.
Оцінювати задачу мусить не той, хто її імовірно робитиме, а вся команда. Якщо команда не пристріляна, то естимейти зазвичай мають нормальний розподіл. Тоді ті, хто дали найнижчу та найвищу оцінки, мають пояснити чому. Це корисно з усіх боків: по-перше, шариться досвід, по-друге, випливають раптові нюанси, про які подумав лише хтось один, по-третє, члени команди вчаться працювати один з одним.
Ідемо далі. «Розробник зникає на тиждень» — це очевидна дурня. Ті ж дейліки винайшли саме для того, щоб такого не було. Взагалі даю пораду програмістам: менеджери завжди мають значно більше задач, ніж фізично можна виконувати. І єдине, про що вони мріють з боку команди — щоб усе йшло за планом. А значить ви як виконавці маєте два обовʼязки: робити все можливе, щоб виконувався план, і повідомляти одразу, щойно він перестав. Тоді керівник має більше простору для маневрів з вищими менеджерами або замовником, а отже відносно задоволений.
Додаткова порада, як уникати зайвих питань «чим займався?»: робіть більше комітів!
Ну й нарешті дійшли до теми про zero trust. Якщо ваша команда — це циферки на дашборді, то може воно й норм, але загалом вважаю такий підхід украй шкідливим. Навіть девіз щойно вигадав: zero trust — zero thrust
Все йде з культури. В якийсь момент (мабуть, після книжок No Rules Rules та «Принципів») мене осяяло, що якщо ставитися до кожного як до спеціаліста своєї справи, котрими вони і є, (а не як до баранів, котрих треба за мотузку тягати), то вони раптом починають працювати збс, беруть на себе більше відповідальності тощо. В українському айті, на жаль, найчастіше зустрічаються два типи «менеджерів»: учора-програміст, на якого навалили купу задач з керування командою за додаткові пів гривні на рік, або той, хто дорвався до влади й починає всіх дойобувати. Школа менеджменту фактично відсутня. Мені ж більше імпонує тема про servant leader й оце все.
Щоб це працювало, керівники мусять давати більше інформації. (Згадайте, як ваш менеджер відміряє вам крихти інфи, наче в аптеці). Коли в людей є достатньо даних, щоб сформувати ширшу картину того, що є й чого треба досягти, вони починають знаходити значно ефективніші рішення. Окрім інформації треба давати ще відповідальність+авторитет. Перше треба для того, щоб працівник був умотивований досягати результатів (і отримував за це дофамін), а друге, щоб у нього були потрібні засоби. Очевидно, що на «нульовій довірі» це все не працюватиме. Навіть навпаки: треба дуже багато довіри.
А от куди zero trust добре пасує — так це до себе. Щоразу, як вам здається, що ви знаєте щось краще, спитайте себе, а чи дійсно ви довіряєте своєму судженню і чи не сліпа це довіра.
Тепер якщо ще раз перечитати оригінальний допис, на який я посилався на початку, то можна побачити дуже багато спільних рис і висновків з декількома важливими відмінностями. Та в одному, я думаю, ми б точно дійшли згоди: треба вибудовувати здорові взаємини в команді. Це важко й довго, але воно точно окупиться. А бракованих цеглин краще позбуватися
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥30👍12❤🔥3
Я обожнюю скінченні автомати. Це штука, яку дуже легко втямити і яка потім вам знадобиться мільйон разів. Їх можна використовувати для опису процесів, автоматизацій на кшталт IoT або CI/CD, діалогів або поведінки НІПів в іграх, парсингу тощо. Завдяки їм зручно контролювати послідовність виконання чого-небудь, робити відновлення до попередніх станів, обробляти помилки. (Памʼятаю, у нас у MBUX був скінченний автомат для підʼєднання телефону до автівки по Bluetooth… на півтори сотні станів 😵💫 Гляньте якось BT-спеку заради цікавості).
Але найулюбленіший мій спосіб їх використовувати — це звісно UI. Як усім відомо, найбільша проблема UI — це комбінаторний вибух станів. Якщо у вас купа «прапорців», які можуть по-різному впливати на поведінку програми, то інколи навіть утримати це все в голові важко. Але щойно ви робите скінченний автомат, усе стає значно легшим!
На прикладі вгорі якраз такий для мого таймера на Pebble. На годиннику всього чотири кнопки, але уявіть собі код обробки натискання BACK без скінченного автомата: це був би довжелезний ланцюг if-else штибу «якщо таймер запущений, але не на павзі», «якщо таймер запущений і на павзі, але програється анімація скидання» і ще десяток таких. Натомість я описав окремі стани програми, і в кожному стані у кожної кнопки лише одна функція. Я писав на💻 , тому обробник натискання кожної кнопки перетворився на простий
Але бувають способи й красивіше. Наприклад, QML дозволяє описувати скінченні автомати декларативно. Обожнюю цей підхід. Також існує цілий окремий стандарт для опису скінченних автоматів в💻 — SCXML; деякі тулзи вміють його читати, навіть той же 💻 .
Проте той же таймер мій — це дуже проста програма. Що робити, коли в'юшок стає багато? Ну, вочевидь робити більше скінченних автоматів!
Доволі зручно робити їх ієрархічними. Уявіть типове IDE, в якому є «звичайний» режим кодінгу і є окремий режим зневадження — це ваш скінченний автомат верхнього рівня з двома станами. У кожного автомата є точка входу, наприклад, в IDE ви завжди починаєте у звичайному режимі. Коли ж ви перемикаєтеся в режим зневадження, то на екрані відбувається багато чого: відкриваються нові панелі, зникають інші, міняються гарячі клавіші, інколи навіть кольорова тема змінюється. У принципі для цього всього можна було б побудувати гігантський «плаский» скінченний автомат, але значно зручніше робити їх вкладеними: наприклад, щойно ви попадаєте в стан зневадження, ви активуєте інший скінченний автомат, що контролює ті ж панелі чи гарячі клавіші. У нього буде власна точка входу й власні стани, і найголовніше — йому взагалі не треба навіть знати про існування звичайного режиму.
На діаграмі цього нема, але в моєму таймері насправді теж є дещо схоже. Річ у тім, що з головного екрану перед запуском таймера можна по довгому натисканню на SELECT зайти у вікно вибору кольорових тем, тож фактично є два стани верхнього рівня: сам таймер та його налаштування. Останні — це звичайний список, який можна гортати вгору-вниз відповідними кнопками, можна підтвердити вибір або повернутися назад. SDK платформи фактично дає напівготовий компонент для цього, тож мені не довелося писати все вручну, але всередині там звісно теж якась імплементація скінченного автомата.
Окрім цього стани можуть паралельними, що якраз чудово комбінується з ієрархічними станами. Коли спробуєте побудувати щось більш-менш складне, зрозумієте, де саме це стає в пригоді.
Переходи між станами також можна робити по-різному: це може бути реакція на щось, може таймер спрацьовувати, може бути безумовний миттєвий перехід, може бути перехід зі стану в той самий стан (наприклад, заради сайд-ефектів, що виконуються при вході або при виході) тощо.
Одна з розповсюджених помилок, які я бачу: зробити основу UI на автоматі, а потім за якоїсь термінової потреби «примазати» там десь фічу звичайним
До речі, за брак зручної можливості робити скінченні автомати я не люблю автоматизації в Home Assistant.
Але найулюбленіший мій спосіб їх використовувати — це звісно UI. Як усім відомо, найбільша проблема UI — це комбінаторний вибух станів. Якщо у вас купа «прапорців», які можуть по-різному впливати на поведінку програми, то інколи навіть утримати це все в голові важко. Але щойно ви робите скінченний автомат, усе стає значно легшим!
На прикладі вгорі якраз такий для мого таймера на Pebble. На годиннику всього чотири кнопки, але уявіть собі код обробки натискання BACK без скінченного автомата: це був би довжелезний ланцюг if-else штибу «якщо таймер запущений, але не на павзі», «якщо таймер запущений і на павзі, але програється анімація скидання» і ще десяток таких. Натомість я описав окремі стани програми, і в кожному стані у кожної кнопки лише одна функція. Я писав на
switch.Але бувають способи й красивіше. Наприклад, QML дозволяє описувати скінченні автомати декларативно. Обожнюю цей підхід. Також існує цілий окремий стандарт для опису скінченних автоматів в
Проте той же таймер мій — це дуже проста програма. Що робити, коли в'юшок стає багато? Ну, вочевидь робити більше скінченних автоматів!
Доволі зручно робити їх ієрархічними. Уявіть типове IDE, в якому є «звичайний» режим кодінгу і є окремий режим зневадження — це ваш скінченний автомат верхнього рівня з двома станами. У кожного автомата є точка входу, наприклад, в IDE ви завжди починаєте у звичайному режимі. Коли ж ви перемикаєтеся в режим зневадження, то на екрані відбувається багато чого: відкриваються нові панелі, зникають інші, міняються гарячі клавіші, інколи навіть кольорова тема змінюється. У принципі для цього всього можна було б побудувати гігантський «плаский» скінченний автомат, але значно зручніше робити їх вкладеними: наприклад, щойно ви попадаєте в стан зневадження, ви активуєте інший скінченний автомат, що контролює ті ж панелі чи гарячі клавіші. У нього буде власна точка входу й власні стани, і найголовніше — йому взагалі не треба навіть знати про існування звичайного режиму.
На діаграмі цього нема, але в моєму таймері насправді теж є дещо схоже. Річ у тім, що з головного екрану перед запуском таймера можна по довгому натисканню на SELECT зайти у вікно вибору кольорових тем, тож фактично є два стани верхнього рівня: сам таймер та його налаштування. Останні — це звичайний список, який можна гортати вгору-вниз відповідними кнопками, можна підтвердити вибір або повернутися назад. SDK платформи фактично дає напівготовий компонент для цього, тож мені не довелося писати все вручну, але всередині там звісно теж якась імплементація скінченного автомата.
Окрім цього стани можуть паралельними, що якраз чудово комбінується з ієрархічними станами. Коли спробуєте побудувати щось більш-менш складне, зрозумієте, де саме це стає в пригоді.
Переходи між станами також можна робити по-різному: це може бути реакція на щось, може таймер спрацьовувати, може бути безумовний миттєвий перехід, може бути перехід зі стану в той самий стан (наприклад, заради сайд-ефектів, що виконуються при вході або при виході) тощо.
Одна з розповсюджених помилок, які я бачу: зробити основу UI на автоматі, а потім за якоїсь термінової потреби «примазати» там десь фічу звичайним
ifʼчиком. Повірте на слово, робити так не варто — у майбутньому пожалкуєте десять разів. Краще зробіть це частиною цього ж автомата або ж додайте ієрархію.До речі, за брак зручної можливості робити скінченні автомати я не люблю автоматизації в Home Assistant.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍18
Дізнався пару днів тому з якоїсь статті, яку вже загубив, про фічу в Git 💻 , котрої мені бракувало.
Річ у тім, що в моїх робочих копіях git-сховищ часто купа якогось сміття: прототипчики, скрипти, тимчасові файли або ж файли, які не треба комітити — одним словом те, чим користуюся я сам і що варто ігнорувати.
Так, існує
Виявилося, що
Також є глобальний список ігнорування, який лежить в
Якщо ви на вінді, то впишіть туди😆
Ну й наостанок можна ще розповісти про команду для перевірки, чи щось ігнорується ґітом:
(Хто б сумнівався, що вона існує. У моїй версії🤯 Unix way, ага).
Краще запускайте з
Річ у тім, що в моїх робочих копіях git-сховищ часто купа якогось сміття: прототипчики, скрипти, тимчасові файли або ж файли, які не треба комітити — одним словом те, чим користуюся я сам і що варто ігнорувати.
Так, існує
.gitignore, але засмічувати його своїми масками файлів чи тек не завжди добре: по-перше, часто воно дійсно треба лише мені, по-друге, файл розростатиметься, по-третє, бувають випадки, коли сама наявність певного імені файлу в списку небажана.Виявилося, що
.gitignore — не єдине місце, куди можна щось таке вписувати. Є ще .git/info/exclude, який працює так само, але сам він під контролем версій не знаходиться, тож при стягуванні репи іншими членами команди у них цього всього не буде. (Хуки теж десь усередині .git лежать і страждають від цієї ж проблеми, чим мене бісять. Але тут навпаки зручно).Також є глобальний список ігнорування, який лежить в
~/.config/git/ignore. Я на macOS, тож у мене там приблизно таке:.DS_Store
**/.claude/settings.local.json
Якщо ви на вінді, то впишіть туди
thumbs.db Ну й наостанок можна ще розповісти про команду для перевірки, чи щось ігнорується ґітом:
git check-ignore <path>
(Хто б сумнівався, що вона існує. У моїй версії
git зараз у районі 160 підкоманд Краще запускайте з
--verbose, і воно тоді покаже, звідки саме прийшов ігнор:> git check-ignore .DS_Store --verbose
/Users/cpplastic/.config/git/ignore:1:.DS_Store .DS_Store
Please open Telegram to view this post
VIEW IN TELEGRAM
👍31
Зараз дід Сіпласпластик знову буде нити про системи побудови проєктів на 💻 та суміжні теми. Я вже писав раніше неодноразово про Qbs, Xmake та інші. Також писав, наскільки не люблю CMake 🤮 .
Моє особисте емпіричне правило таке: якщо виникає потреба в зневаджувачі для ваших скриптів, які перетворюють код на те, що можна запустити, то щось іде геть не так.
Microsoft колись додала можливість налагоджувати CMake-скрипти прямо у VS, а зараз оце побачив тулзу, яку хтось собі навайбкодив з ImGui — dcmake називається.
І перш ніж вебпрограмісти посміються з бідних нативщиків, я вам «напамʼятаю», що якихось 10–15 років тому можна було деплоїти вебзастосунки перетягуванням файлів з локальної теки на віддалену — іншопланетні технології. А зараз список з тудушками не запустиш без компіляторів, бандлерів, мінімайзерів, тришарового докера й обліковки на Cloudflare😉
Повернімося до нативних програм. Чого так важко-то?
Насправді головна складність навіть не в тому, щоб компілювати й запускати програму (хоча в C++ навіть це випробування, якщо є зовнішні залежності). Локально-то я її запускаю в себе! А от розповсюджувати — це проблема. У ембедерів, до речі, від цього голова так не болить.
Маємо три основні настільні системи та пару мобільних. (Раніше ще Symbian, Windows Mobile та Maemo були — шкода що померли). Пишете ви програму на комп з використанням «кросплатформного» фреймворка на кшталт Qt. Очікування: сьогодні написав, а завтра всі користуються. Для програм рівня калькулятора десь так і буде, а для чогось серйознішого — без шансів.
У кожної ОС своя атмосфера. На вінді🪟 бінарь і ліби всі в одній теці лежать, іконки 🍏 інсталяторів найчастіше нема (але інколи є!), зате є особливий архів з прогою; сама прога показується як файл, але насправді це тека зі своєю особливою структурою, яка чітко описана в специфікації, але яку всі порушують, навіть сама Apple — ліби в одній теці, бінарі в іншій, ресурси в третій; іконки 🐧 взагалі зоопарк технологій: бінарі, які запускаються, та бібліотеки можуть лежати по різних теках прямо в системі, а можуть не лежати; може бути AppImage (zip з прогою), може бути Flatpak (контейнер), може бути абишо, може не бути ліб, іконки хтозна-де, ярлики бозна-як.
Звісно, можна це все захардкодити в тулінг. Можна знайти спільний знаменник по фічах, але це завжди дуже вузенька множина. Наприклад, механізми для асоціювання файлів з програмою всюди різні. На деяких ОС є унікальні фічі (як той же QuickLook на macOS). А додати сюди ще iOS та Android (або якусь tvOS), то буде ще більше розбіжностей. Жах.
Можна компонувати все статично, і тоді бандлити значно легше, та я поки щось не бачив хороших UI-фреймворків для цього.💻 під LGPL, та ще й на C++ — таке собі. Без фреймворків писати — забагато зусиль.
Памʼятаю, як ми писали редактор для дизайнерів під macOS та вінду. Довелося використовувати щонайменше 5 різних мов: C++, QML, JavaScript, Qbs (фактично несумісний діалект QML), InnoSetup. І це я не кажу про всілякі мови розмітки чи конфігів.
Отже, воно й не дивно, що для систем побудови програм уже зневаджувачі пишуть. Як і не дивно, що контейнеризовані програми з веб-UI перемогли (чи навіть просто запакований бравзер). Працює тепер, правда, все як лайно: повільно й криво.
А тепер лишилося тільки вайбкодом це обмазати додатково. До речі, звернув увагу, що собі можу з ШІ-шкою навайбкодити якусь тулзу — і мені загалом норм. А ось коли хтось інший вайбкодить, то якось навіть лячно запускати😆 «Не настільки й сильно воно мені треба» гг. Той же 😅
Моє особисте емпіричне правило таке: якщо виникає потреба в зневаджувачі для ваших скриптів, які перетворюють код на те, що можна запустити, то щось іде геть не так.
Microsoft колись додала можливість налагоджувати CMake-скрипти прямо у VS, а зараз оце побачив тулзу, яку хтось собі навайбкодив з ImGui — dcmake називається.
І перш ніж вебпрограмісти посміються з бідних нативщиків, я вам «напамʼятаю», що якихось 10–15 років тому можна було деплоїти вебзастосунки перетягуванням файлів з локальної теки на віддалену — іншопланетні технології. А зараз список з тудушками не запустиш без компіляторів, бандлерів, мінімайзерів, тришарового докера й обліковки на Cloudflare
Повернімося до нативних програм. Чого так важко-то?
Насправді головна складність навіть не в тому, щоб компілювати й запускати програму (хоча в C++ навіть це випробування, якщо є зовнішні залежності). Локально-то я її запускаю в себе! А от розповсюджувати — це проблема. У ембедерів, до речі, від цього голова так не болить.
Маємо три основні настільні системи та пару мобільних. (Раніше ще Symbian, Windows Mobile та Maemo були — шкода що померли). Пишете ви програму на комп з використанням «кросплатформного» фреймворка на кшталт Qt. Очікування: сьогодні написав, а завтра всі користуються. Для програм рівня калькулятора десь так і буде, а для чогось серйознішого — без шансів.
У кожної ОС своя атмосфера. На вінді
*.ico, треба інсталятор, треба якийсь там vcredist_x64.exe, автозапуск через реєстр тощо. На macOS *.icns (це шо взагалі‽), автозапуск через сраку; треба обовʼязково підписувати всі бінарі ключем (на вінді взагалі-то теж) тощо. На лінуксі Звісно, можна це все захардкодити в тулінг. Можна знайти спільний знаменник по фічах, але це завжди дуже вузенька множина. Наприклад, механізми для асоціювання файлів з програмою всюди різні. На деяких ОС є унікальні фічі (як той же QuickLook на macOS). А додати сюди ще iOS та Android (або якусь tvOS), то буде ще більше розбіжностей. Жах.
Можна компонувати все статично, і тоді бандлити значно легше, та я поки щось не бачив хороших UI-фреймворків для цього.
Памʼятаю, як ми писали редактор для дизайнерів під macOS та вінду. Довелося використовувати щонайменше 5 різних мов: C++, QML, JavaScript, Qbs (фактично несумісний діалект QML), InnoSetup. І це я не кажу про всілякі мови розмітки чи конфігів.
Отже, воно й не дивно, що для систем побудови програм уже зневаджувачі пишуть. Як і не дивно, що контейнеризовані програми з веб-UI перемогли (чи навіть просто запакований бравзер). Працює тепер, правда, все як лайно: повільно й криво.
А тепер лишилося тільки вайбкодом це обмазати додатково. До речі, звернув увагу, що собі можу з ШІ-шкою навайбкодити якусь тулзу — і мені загалом норм. А ось коли хтось інший вайбкодить, то якось навіть лячно запускати
dcmake з початку цього допису навіть не запускав урешті Please open Telegram to view this post
VIEW IN TELEGRAM
👍15🤯3👀2👌1🤣1💊1
Хто читає цей канал давно, знає, наскільки я полюбляю 1Password. Завдяки ньому в мене SSH-ключі навіть не лежать на диску, а
Що я не люблю — це коли вони підіймають вартість передплати😠
Але мало хто знає, що можна отримати безплатно 1Password Teams, який зазвичай коштує 25 баксів на місяць, якщо ви розробляєте щось з відкритим кодом. Люблю, коли компанії не лише користуються надбаннями цивілізації, але й чимось віддячують. (Раніше вже писав, як аналогічним чином отримав ліцуху на Araxis Merge).
Для отримання 1Password на дурняк треба мати якийсь плюс-мінус корисний проєкт з відкритими сирцями й подати заявку через GitHub🐈 або написати їм на пошту. Важливо, щоб цей проєкт не використовувався комерційно (але вести іншу комерційну активність паралельно можна звісно). Переглядають такі запити вони раз на тиждень-два, тому доведеться трохи почекати ймовірно. Тим не менш, це реальна можливість.
Ось і я нарешті зможу перенести всі ключі, паролі й токени з особистої обліковки (за яку досі плачу й продовжу) в ту, що повʼязана саме з проєктом.
Це також допомагає закрити питання обміну всім важливим, зокрема секретами, між людьми в команді на випадок, якщо перестану бути головним мейнтейнером.
.env я можу комітити без остраху.Що я не люблю — це коли вони підіймають вартість передплати
Але мало хто знає, що можна отримати безплатно 1Password Teams, який зазвичай коштує 25 баксів на місяць, якщо ви розробляєте щось з відкритим кодом. Люблю, коли компанії не лише користуються надбаннями цивілізації, але й чимось віддячують. (Раніше вже писав, як аналогічним чином отримав ліцуху на Araxis Merge).
Для отримання 1Password на дурняк треба мати якийсь плюс-мінус корисний проєкт з відкритими сирцями й подати заявку через GitHub
Ось і я нарешті зможу перенести всі ключі, паролі й токени з особистої обліковки (за яку досі плачу й продовжу) в ту, що повʼязана саме з проєктом.
Це також допомагає закрити питання обміну всім важливим, зокрема секретами, між людьми в команді на випадок, якщо перестану бути головним мейнтейнером.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Cіпласпластик
Принаймні я б може так і робив, але у мене є #1Password. Я багато якими аналогами користувався, але щойно спробував його — одразу оформив передплату. Зараз розповім чому, бо, схоже, далеко не всі розуміють можливості.
По-перше, він тупо зручніший. У мене…
По-перше, він тупо зручніший. У мене…
👍13🥰3😁1👌1
Усі ж подивилися вже доповідь автора SQLite 🪶 і Fossil ☠️ ? Дуже раджу витратити цю годину, щоб дізнатися, як команда з трьох головних мейнтейнерів підтримує один з найбільш вживаних у сучасності продуктів. Дядько розповідає про те, як у них побудований процес тестування. Дуже цікаво!
Я й сам нещодавно перевів деякі свої self-hosted штуки з постгреса на SQLite, зокрема Forgejo та Paperless-ngx. Мотивацією було те, що на моїх обʼємах даних геть нема сенсу тримати окремі контейнери PostgreSQL🐘 чи навіть один екземпляр з кількома БД, що обслуговував би всі проги як сервіс. Натомість маю просто по невеличкому файлу — легко бекапити. Тим паче туди дуже рідко щось пишеться.
Ще днями кумедна історія була з тим, як JFrog аналізувала вразливості, які нещодавно знайшли в SQLite, і виявила, що 54 з 55 — це ШІ-слоп🤣 «Coding is solved» чи як там?
Я й сам нещодавно перевів деякі свої self-hosted штуки з постгреса на SQLite, зокрема Forgejo та Paperless-ngx. Мотивацією було те, що на моїх обʼємах даних геть нема сенсу тримати окремі контейнери PostgreSQL
Ще днями кумедна історія була з тим, як JFrog аналізувала вразливості, які нещодавно знайшли в SQLite, і виявила, що 54 з 55 — це ШІ-слоп
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Reliability Lessons From SQLite - Richard Hipp | SSW 2026
Abstract: SQLite is a C-language library that implements a self-contained, in-process relational database engine supporting full-featured SQL, an advanced query planner, and ACID transactions. By many estimates, SQLite is the most widely used software library…
🥰12👍6👀2
Cіпласпластик
Бляяяя, їх все-таки ламанули 😂
Певно, скористаюся шансом усім нагадати, як важливо підтримувати українські локалізаційні спілки, особливо ті, чиї переклади виходять з іграми офіційно. Варто хоча б Шлякбитраф підтримати через патреон чи монобанк (там, до речі, якийсь розіграш призів нині за донати).
Мрію про часи, коли всі нові ігри виходитимуть одразу з українською!💛
Певно, скористаюся шансом усім нагадати, як важливо підтримувати українські локалізаційні спілки, особливо ті, чиї переклади виходять з іграми офіційно. Варто хоча б Шлякбитраф підтримати через патреон чи монобанк (там, до речі, якийсь розіграш призів нині за донати).
Мрію про часи, коли всі нові ігри виходитимуть одразу з українською!
Please open Telegram to view this post
VIEW IN TELEGRAM
😱10👍8👨💻1
Cіпласпластик
До речі, лайфхак стосовно семантичних версій. Коли мене змушують використовувати саме цей формат, я нерідко пишу щось на шталт 😉
2026.8.13 — ще семантичніше вже нема куди Please open Telegram to view this post
VIEW IN TELEGRAM
💯10😁7🔥2💊1