Ну ... кругом є межа ...

Якщо «тут в тебе труба прорвала ... ми її підлатали щоб не текла ... що з нею далі?» — то це більш ніж ок.

Якщо «ми тут вікно на іншу стіну перенесли, бо в сусіда злий собака» — звісно що не ок і треба було обговорити.

Нещодавно робив ремонт ... ви знаєте ... це ще той agile )))

Тут ми зараз знову ж можем кожен наводити свої історії ... Електрик, наприклад, може зауважити, що десь варто кинути іншого перерізу провід, бо проектний буде грітися... чи, наприклад, запропонувати на ванну поставити додатковий ПЗВ (і бажано поставити більший щиток). Сантехнік може сказати, що туалет занадто далеко від стояка і «з цим треба щось думати». Штукатур може сказати, що десь порушена геометрія кімнати ... тощо.

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

Waterfall має свої недоліки. Тому й придумали agile. Як на мене, навіть коли все продумано від початку до кінця, є сенс звертати увагу на обставини по ходу. В готовому будинку ще одну розетку доставити важко ... але в 99% випадків дуже хочеться.

Та й ось SpaceX показує, що agile застосовний навіть в галузях, де був waterfall десятиліттями... в них ж кожен запуск starlink-а — це як спринт ... щоразу новий білд і нова модель супутника. І, як виявляється, воно життєздатне.

Це аджайл-досвід, так?

Думаю, можна так сказати.

бачить лише спек на модуль та інтерфейси

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

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

намаганням дати раду складності сумі всіх умов та обмежень

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

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

Моя ж теза полягає в іншому: далеко не кожен рух здатен порушити крихку рівновагу проекту. І рішення є сенс приймати як можна простішим способом (що в більшості випадків є можливим ... тим більше в IT).

Для того, щоб проект розвивався, ініціативу потрібно заохочувати. Це дуже наївно вважати, що хтось розумний може «сісти і придумати» гарний продукт/рішення/архітектуру. В багатьох випадках проблеми вилазять при безпосередній реалізації. І хочете чи ні, а якість придуманої архітетури найкраще бачать ті самі прості розробники.

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

Ви написали, в цілому, може й вірно. Але я б не хотів працювати в компанії з таким підходом. Занадто багато бюрократії. До того ж ви описуєте самий довгий шлях, а подаєте його як найкоротший.

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

Якщо ж в сфері компетенції іншої команди — знайти їх ліда і «продати» ідею туди.

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

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

Ну і якщо це зовнішній клієнт, треба дивитись на те як організована робота в цілому. Можливо є сенс продати фічу клієнту одразу і на рівні «виконавець-виконавець» і потім вже підняти її на рівень sales. Але знову ж ... по обставинам.

З карантином — то лажа, згоден ... але з ним багато де лажа.

Для старту, такий офлайновий курс, в Києві після роботи — саме воно.

По онлайнових курсах, так не підкажу.

З іншої сторони, якщо якась база у вас є, то sdk, examples, reference manual і вперед розбирати периферію за периферією.

Скачал среду en.stm32cubef7_v1-16-0.zip Внутри даже нет экзешника, чтобы установить ее или запустить

www.st.com/...​t-tools/stm32cubeide.html
Тут, наче як, остання ... там під win звичайний інсталятор.

Але в embeded з ide кругом біда ... тому cube ide ще дуже навіть гарний інструмент.

techmaker.ua/embedded-basic

Ви ж в курсі, що то помийний сайт?

Оригінал тут: stackoverflow.com/...​ish-character-doesnt-work

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

І декілька, які знадобилося погуглити )

Цікаве питання про Bloom filter. Я спершу не згадав що це, але як почав читати, зрозумів, що це та ж фігня, яку використали в signal для contact discovery. Я б сказав, що це дуууже нішеве питання.

Я б розглянув варіант не вбиватися в академічну реляційну БД.

Один тариф на місяць для всіх номерів влізе в один json.

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

Єдине, що для такого підходу треба обирати backend, де можна в пам’яті тримати гарно розкладений той json в зручну in-memory структуру, яку постійно всю тримати в пам’яті (щось схоже на кеш).

А самі json-и, можна навіть в gzip тримати в blob в БД, там і версіювати.

Мінус такого підходу в тому, що треба забути про запити всередину того json. Але плюсом є те, що структуру можна зробити «природною» для даних, in-memory буде працювати дуже швидко, а БД буде дбати лише про «persistance».

принимать решения на основе требований, а не личных преференций

выбор на совсем другой базе данных — MySQL ... так как она давала дополнительные организационные преимущества. При использовании со Spring Data JPA стало возможным получать подсказки о несовместимости на этапах сборки и тестирования проекта

Питання не розкрите. З наведеної аргументації схоже, що «преференції» однії людини поміняли на «преференції» іншої.

количество активных пользователей выросло в 10 раз. Тут и начались сложности.

Ще не було системи, яка б таке пережила без доробки.

Метрики не збирали — бо не треба було і за це не доплатили ... та й не знали що збирати.

Проблеми з SQL не проявляють себе на малих даних. Доналаштування БД при зміні об’єму даних — стандартна процедура. Щоб передбачити ріст в 10 разів, треба було нагенерити в базу в 10 разів більше даних на тестах. (За тестування під навантаженням, скоріш теж не заплатили, того і не зробили).

Я вам більше скажу, зросте кількість даних ще в 10-100-1000 разів, база, майже напевно, знову підведе.

А также точно оценить задачу, учитывать перспективу развития проекта через 2, 5, 10 лет.

Це неможливо. Щоб проект жив 2-5-10 років і витримував зміни, потрібна компнда розробників в штат (або на підхваті в аутсорсі).

В итоге при создании каждого объекта на сторону приложения вытягивалась добрая половина базы данных.

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

Основна задача ORM — це mapping: ResultSet на об’єкти, об’єкти на інсерти, ще мож щось з процедурами.

Query Builder — це вже не задача ОRМ, хоч і для специфічних задач ще згодиться.

А ось join-и, витягування дочірніх об’єктів, генерація запитів, hibernate-івські сесії — це все те, чого варто уникати — ці всі інструменти створюють більше проблем, ніж вирішують.

Базу даних треба поважати: писати складний SQL руками.

Не забывайте грамотно разбивать свою систему на слои.

Шари — це добре. Але в більшості випадків, це є сенс робити на етапі рефакторингу, коли стає очевидним де і що є сенс розділяти. Інакше ж, створиться мінімум по три об’єкти на кожну сутність (dao, dto і, власне, модель) і купа перетворень між ними. В результаті, вагон класів і каша в коді.

Шари — це добре, але Keep It Simple.

Fxml — то добре ... але це не парадигма, це інструмент. Тому змішувати там більш ніж норм ... а нагавнокодити можна і змішуючи і не змішуючи )

Ну ... javafx — це ж як раз і є UI фреймворк.
Всякі «Licence agreement» можна і у web view зверстати. А UI — засобами фреймворку. Зрештою, в javafx стандартна архітектура ... нічого незвичного. Єдине що візуального редактора там не дуже ... scene builder ... трохи ... з особливостями.

WebView в JavaFx — це ще той тормоз ... just in case.

матрицю транспонував в універі,

Це не зовсім так ... наприклад, жорданову форму матриці я зараз ось так не згадаю і не зроблю, оскільки після курсу лінійної алгебри жодного разу не використовував. Цей «м’яз» все-рівно треба качати ) Він не так швидко атрофується, але атрофується.

є «фундаменталс» і досвід, який не незнецінюється, на відміну від знання «модних фрейморків».

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

Якщо повернутися по моєї початкової тези, то я говорив про досвід зрілого розробника в якійсь технології.Тобто, вже маючи якийсь фундамент в, наприклад java, можна мати рік досвіду в C#. І теза полягала в тому, що, наприклад, 5 java+1 C# не сильно відрізняється (в знаннях C#) від 5 java + 5 С#.

Ну і, fundamentals та досвід ... то як м’яз .... накачати важко, підтримувати легше але вимагає постійної роботи, а якщо нічого не робити, втратити тонус дуже легко.

Це абсолютно вірно ... але суть в тому, що ці шишки та граблі дуже швидко забуваються і через рік-два «десь я таке робив ... треба глянути отой репозиторій», а через 5 ... ну ... 10 років тому я писав на C# ... я зараз, звісно, можу писати на C#, можу поправити щось в старих проектах ... але, щоб по нормальному там щось робити, треба розбиратися заново. Ну і про граблі та шишки я там слабо вже щось пам’ятаю.

Тобто, кінець-кінцем, мілкі граблі «новачком» гугляться на stack overflow за хвилину, а більш важливі тренують в людини відчуття того що є добро чи зло в сфері. З часом це все сильно обезцінюється. Тому я і дав людині з більшим досвідом 15-20% «чогось» більше, хоча на відрізку 2-5 років це може бути і 5-10% а то і менше... По суті, немає чого вчити майже в будь-якій сучасній технології більше року. Решта часу — то збільшення кута зору, просвітлення, війна добра зі злом, прекрасного з огидним, тощо.

якому рік від народженя

Найбільш ризикованим для нас був не gitlab. Ризикованим був flutter, якому як раз і був рік від першої версії. Тоді і мова нова, архітектура UI ні на що не схожа, купа ліб під одну задачу і майже всі в беті та з github-а з малими community.

Це був дійсно ризик ... але пройшло вже понад рік, і я вам скажу, що кращої платформи для розробки UI я ще не бачив на своєму скромному шляху (якщо порівнювати з Delphi, MFC, Windows Forms, WPF, JavaFx, HTML+CSS+JS, Android, Swift).

тягнути github ci, якому рік від народженя

В нас був CI на Bamboo до того.
Після нього CI на gitlab — це був ковток свободи і свіжого повітря. Виправдав себе практично через місяць. Тільки що варте білди в контрольованих середовищах в docker контейнерах. Зараз у нас всі білди в контейнерах, крім ios. І коли ми налаштовували на ios runner, я згадав, що то за пекло, коли тобі потрібно обслуговувати runner (то версію чогось міняй, то на диску щось видали, то система якесь оновлення просить).

Щодо нового інструменту ... на self hosted gitlab ми перейшли на початку 2016го, на gitlab ci десь через 11 місяців. ± десь і тоді починали впроваджувати контейнеризацію по серверах. Я вам скажу, в цих всіх «нових» технологіях ми не зіштовхувалися з «непереборними багами». Були відсутність якихось фіч, які б дуже хотілося, але то таке.

скрипти в бранчах

Це одна з основних переваг — проект розвивається скрипти міняються. Завжди можна зробити будь-який білд будь-якої версії і все буде коректно.

VSTS була якась

Я вийшов з microsoft-ського стеку десь в той час, коли тільки цей інструмент випускав свої перші версії. Тому предметно порівняти не зможу.

І скільки людьских місяців праці витратилии на написання екшнів і розмноженя воркфловів по репам ?

Не зовсім зрозумів питання, якщо чесно. Звісно на те, щоб .gitlab-ci.yml + обв’язку до нього зробити знадобився час. Але на той момент нам багато і не треба було. Я б не став міряти місяцями. Та й еволюціонували білд скрипти з проектом. А той час, що ми потратили, був з запасом зекономлений на білдах-тестах-деплоях.