Уххх... як на мене, то є дуже нішевий інструмент.

Від GCM, звісно важко відкрутитись, адже він тримає монополію на пуші. Від crashlytics — теж, оскільки вони викупили основного конкурента.

Щодо решти, використовували database та storage.

Скажу вам так ... складається враження, що команда firebase ненавидить flutter, але їх змушують його підтримувати:
— бібліотеки від firebase — одні з найпроблемніших з точки зору міграції на нові версії... постійно на них тратиться час
— не можна просто десь вказати токен додатку ... вони зробили налаштування настільки складним, що для цього зробили аж окремий cli інструмент.
— бібліотеки для flutter немає ... тобто вони є, але то проксі в native. Але 90% api — то просто api на сервер ... не зрозуміло чому воно не на dart.
— firebase messaging ... ехх ... доводиться його викидати і самому писати binding-и на java та swift.
— не працює на desktop ... я розумію про messaging, але не розумію про крешлітику та аналітику.
— realtime база — крута, але api — ну таке собі ... хочеться роботу з ним акуратно загорнути в адаптер і забути, що це бачив. Ну і легко прострелити собі ногу і отримати безлімітний рахунок від гугла.
— storage — те ж саме що і realtime.

Можете обгрунтувати своє твердження?

Зараз продактів взагалі не готують. Більше того, цю роль виконують або техліди або PM або сейлзи або SEO або команди колегіально. Окремих продактів не так багато.

Вірним є те, що продакт менеджментом займаються люди, що взагалі не мають освітньої бази щодо цієї ролі. І, очевидно, робляться помилки.

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

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

Факультет — скоріше всього, погано вибраний термін.

Наврядчи, цей напрям тягне на окрему спеціальність. Якось дивно звучить PHD з product management.

Ну і сам менеджмент — досить усталена сфера. Окремих особливостей в ІТ не так і багато.

Інша справа, що є сенс розвивати свою «школу» в цьому напрямку. Можливо навіть як кафедру ... тощо.

Є сенс збирати best practices, case-и, підходи. Формувати ± стандартизовані прсібники, навчальні програми, тощо. Створювати способи обміну ідеями: аля коференції різного калібру.

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

Asyncio — це бібліотека для асинхронного програмування в Python

Як на мене, то більш коректно такі бібліотеки пов’язувати з кооперативною багатозадачністю (en.wikipedia.org/...​/Cooperative_multitasking) ніж з асинхронністю?

З асинхронності тут є лише те, що після await-а задача може не одразу повернутись в event loop, а лише після деякої зовнішньої події (IO, сигнал від executor-а, тощо).

Плюс за MQTT, RS-485 ... сьогодні виробники все ще дуже рідко турбуються про взаємодію.
(Привіт тим, хто в побутову техніку вставляє годинники, які постійно збиваються і синхронізувати їх можна лише пальцями)

Щодо автоматизацій ... я не впевнений, що розібрався повністю ... але схоже, що тут ви намагаєтесь наклікати все з телефона по принципу подія-реакція + готові «модулі» як термостат.

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

Ви розповіли про цікавий підхід. Сьогодні вдалося дізнатись щось нове :)

Корисно, коли підіймаєш «а чим саме його зламали 10 років тому?»

Щодо цього ... якщо в репозиторії не повний хаос, то з тим піходом, що описував я, проблем з трекінгом «коли і що зламали» особливо немає.

З тих випадків, коли треба було щось знайти більше зустрічався з іншою проблемою. Якщо відбувається великий рефакторинг, де переносяться/переназиваються файли і при цьому міняються в структурі ... в цих випадках git не розуміє, що то move/rename і вважає, що там add/remove... і історія обривається на таких рефакторингах.

Цікавий workflow ... я вірно зрозумів, що коли відбувається merge, то в кінці він виглядає як merge чистих комітів main0->A -> B -> C->main1 (з вашого прикладу)?

Так як ми зараз працюєм, це виглядало б як main0->A1->B1->C1->A2->B2->C2->ABC3->main1.
Тобто, якщо коміт зроблений, то лише в дуууже рідкісних випадках ми його переробляєм (зазвичай лише на етапах, поки коміт лежить локально). Всі виправлення йдуть в наступних комітах поверх попередніх.

В такому випадку, немає проблеми хронологічно дивитись на зміни під час review (можна глянути main0 vs ABC3, а можна і С1 vs A2, наприклад). В нас не появляється «наступної версії коміта A», а просто наступна зміна.

В кінці, звісно, ми не маєм гарної історії ... але за ціль це не ставиться.

Можливо, для великого публічного open source наш підхід є не дуже добре. І тут гарна історія може мати більшу цінність.

Але для закритих проектів це працює дуже не погано.

А ревʼю через що проводите?

Якщо чесно, я не впевнений, що до кінця зрозумів ваш приклад...
Давайте так:
1. В gitlab є можливість порівнювати будь-які два коміти. Наприклад: gitlab.com/...​aight=false&view=parallel
2. Також можна коментувати зміни.
3. Для merge request-ів там також є інструменти. Наприклад, таке: gitlab.com/...​b/-/merge_requests/114997 (правда, багато смачних речей тут лише в платній версії)

Але, власне, для маніпуляцій з деревом, ми частіше користуємось локальними UI: TortoiseGit, SmartGit.

Якщо я вірно розумію, то у вашому прикладі ви порівнюєте два патчі, при цьому застосовані до різних комітів. Якщо чесно, ніколи не виникало бажання побачити саме таке порівняння. В яких випадках це вам стає в нагоді? Якось звиклось працювати в термінах «merge-ення гілок», а не «застосування патчів».

порівняти дві версії одного PR складно

Я вірно розумію, що у вашому прикладі є дві гілки з різними предками з main-ом, які роблять однакову задачу і ви намагаєтесь обрати яку з них мержити в main?
Це цікаво :) ... я, напевно, б гялнув два diff-и: по одному на кожну гілку між гілкою і її парентом з main.

Не простіше. Але значно гнучкіше.

Насправді, не виключено ... мені складно об’єктивно порівняти, так як з gitlab ми працюєм понад 7 років, а про jenkins та gerrit лиш доводилось бачити збоку.

Ми користуємось як self hosted git сервер, де зручно керувати користувачами + CI. А ... ну і docker registry там ще корисний для образів, які CI білдить.

Доречі ... щодо «git-вебморда» ... частково так ... але базового функціоналу достатньо ... ніхто в нас в команді не мержить і не ребейсить через веб.

Альтернативи толком я не знаю.
— Github — НЕ self hosted.
— Jenkins+Gerrit? Це точно простіше і краще ніж Gitlab?

Можливо, хтось так думає, але це не дуже раціонально.

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

Люди йдуть, і це не залежить від статі. І причин багато. Яка вам різниця чи це дикрет чи це контора через дорогу, чи це вступ на PhD, чи переїзд в іншу місто/країну, чи у воєнкомат, чи проблеми зі здоров’ям.

На своєму досвіді, я не бачу кореляції між статтю та «надійністю» людини.

Ви згадали тут найбільш тривіальний спосіб використання ChatGPT. При цьому, найменш ефективний.

Зараз модель «знає» мало фактажу і може забагато «вигадувати». Тому прямі запитання — то «таке» ... погратись.

Сила інструменту проявляється коли ви даєте моделі всі необхідні тези/факти/дані.

Can you tell about Python using the facts below?
<і тут ви тезово пишите що ж ви хочете сказати>

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

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

Як працює AI

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

Чи доречно порівнювати протести художників проти AI з луддизмом

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

Що робити 2Д-художникам

Адаптовуватись. Сприймати це як інструмент. Як колись було з фотошопом, наприклад. Згенеровані зображення гарні, але там зображено не те, що в голові у автора.

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

Щодо авторського права ... якщо мережа видала зображення яке не є ідентичним авторському (до певної межі), то не бачу предмету зловживання.

Доречі, прикольно ... 5хв погратись з chat gpt і можна отримати щось дуже схоже.

Запит: Write 10 in-depth questions about docker for job interview.

Відповідь (після декількох експериментів з запитами):

1. Can you discuss the security concerns associated with running applications in Docker containers and how they can be mitigated?

2. How does Docker handle container resource allocation, such as CPU and memory, and what mechanisms are available to limit resource usage?

3. Can you explain the process of building a Docker image from a Dockerfile, including the use of multi-stage builds?

4. How does Docker handle networking in a multi-container environment, including load balancing and service discovery?

5. Can you describe the security measures in place within Docker, such as image signing and user namespace mapping?

6. Can you discuss the use of Docker Compose for defining and managing multi-container applications?

7. Can you discuss the use of third-party tools and services, such as Docker Trusted Registry and Docker Cloud, in a Docker deployment?

8. How does Docker support the deployment and management of applications in cloud environments, such as AWS and Azure?

9. Can you explain the process of rolling out updates to containers in a production environment, including zero-downtime deployments and blue-green deployment strategies?

10. Can you discuss the use of Docker volumes and bind mounts for persistent storage, and the trade-offs between the two options?

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

Хоч і надіятись на те, що chat gpt володіє необхідним фактажем в цьому випадку було досить сміливо, але як на мене, вийшло не погано.

Світ став іншим. Методи 30річної давності станом на сьогодні є варварством (подивіться хоч на стоматологію)

Mono завжди був захищений від DDoS-атак

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

Є нюанс... якщо не рухатись далі, то це є рух назад. І для лікарів в тому числі.

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

Це як 30 років досвіду роботи з fortran. Добре, але трохи «таке».

Взагалі, блокування сайтів — це дуже велике зло в довгій перспективі. І такого, по нормальному, не мало б бути в інтернеті взагалі.

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

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

Достатньо самого простого блокування через DNS і цього достатньо, щоб 90% людей не стали шукати варіантів обходу.

Тому ... надійно заблокувати неможливо ... але й, майже завжди, цього і не треба.

В мене мало якоїсь особистої статистики, але, схоже, що з дба ростуть монструозні пакети на хранимих процедурах :) Ну, або, можливо, намагання зав’язати всі питання консистентності бази на рівень БД.

З того, що я бачив, що одне, що інше, «так собі» працює.

Якщо я вірно зрозумів вас, то у вас вся логіка схована за абстракціями, що дає Hibernate.

Що є інша крайність. Вам тепер треба думати не лише, про артефакти, які створює база, а й про артефакти які додає Hibernate.

Так і живем :)

что лучше мне бы прочитать книгу на тему Х

Так було завжди. Якщо така книга існує.

Але cutting edge — то завжди статті/блоги.

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

А в GPT — статистично сформована послідовність букв, коректність якої ніхто не гарантує?

Інша справа, якщо зробити пошук за допомогою GPT і знайти в Кормені шматок, який треба прочитати. Не згенерувати, а знайти. Читати, звісно, що варто оригінал.