Діте теж люди ) І вони теж хочуть вчитися/працювати/заробляти.

свободное время без тасок

Хіба таке буває? На роботі треба працювати. Навіть в самі халявні часи є технічний борг, який треба фіксити.

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

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

З того, що я знаю, в нас аналітику або купують, або роблять в великих екселях.

Наступний етап: всякий ML, але про нього в економічних моделях поки не чув.

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

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

1. Поділити на 10 ІТшників та поділити на три залізо — то серйозна заява. Це схоже на не-ІТ компанії з софтом з 90х, які не можуть вилізти з зоопарку софта, технологій та старих рішень.

2. Якщо я вірно зрозумів вашу тезу, то шукають те, чого немає: стандартизованого cloud.

3. Виктристовувати cloud це часто корисно. Особливо в допоміжних сервісах. Але щоб в усьому... хз.

Могли б ви з досвіду назвати 2-3 use case-а, коли перехід в cloud був би виправданий, за умови, що за альтернативу взяти редизайн системи на власних потужностях? (Якщо не рахувати речі типу SaaS як crm, ту ж пошту, трекери задач, office 365, тощо ... особливо, якщо бізнес не ITшний)

Важко погодитись з вашими висновками.

Візьміть приклад з розробки ... колись був IDE з Borland Pascal, зараз є JetBrains. Чи вплинув цей перехід на розробку? Очевидно, що так і досить суттєво. Чи змінило це сутність роботи? Думаю, що не дуже.

З «DevOps» переїзд між голий linux->віртуалки->докер по суті спрощує та пришвидшує деякі процеси, але, знову ж, на скільки принципово?

Щодо cloud ...
1. Сервіси як такі — далеко не новинка: mail, dns, sms gateways існували вже дуже давно як сервіси. Зараз їх асортимент, просто, розширився.

2. Хмарні сервіси не стандартизовані. Відповідно, їх використання — це вже vendor lock in. Особливо це важливо, якщо використовувати специфічні фічі.

3. Часто, є зручним розмістити щось там на VPS. Але як тільки появляється яке не яке навантаження, одразу чомусь вигіднішим стає взяти в оренду виділений залізний сервер.

4. Є фічі, які cloud провайдери дозволять робити значно легше і краще, ніж самостійно: cdn, масштабування, частково бекапи. Але, знову ж, це дорого під навантаженням. І можна прийти до думки, що простіше взяти по серверу на кожному континенті в оренду.

5... В хмарних рішеннях, звісно, є сенс для деяких задач. Але із-за 1-4 я не розумію хайпу навколо цього. Що б там не було, але точно не про «дешево» та не про оптимізацію витрат.

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

Можна ставити питання як себе продати... але щоб було що продавати, знову ж, треба рости професійно.

Продукція Apple, в основному досить якісна, хоч і дорога.

Але всім рекомендую її НЕ купувати.

В них погана філософія: все закрите, все платне, все не сумісне ні з чим, крім своїх ж продуктів.

Розвивався б світ ІТ з такими принципами, ми б зараз не мали б і, напевно, половини досягненнь, які є сьогодні.

В тижні 7×24=168 годин. В середньому, для нормального сну треба 56 годин. Робочий тиждень 8×5=40 годин. Їжа, душ і інші фізіологічні потреби десь 3×7=21 годину. Час на дорогу дім-робота хай 1.5×5=7.5 годин.

Залишається 43.5 годин на особисте життя, навчання, відпочинок, тощо.

І тут ви описуєте людину, яка майже половину (40 з 40+43.5) свого активного часу виділяє на діяльність, в якій зовсім не зацікавлена, не має амбіцій та інтересів?

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

Є декілька питаннь, якщо у вас є бажання відповісти.

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

2. Договора в електронній формі. ЕЦП круто лише в межах України і то не дуже й то популярно. Як укладати договора віддалено з іноземцями? Чи мають скани з підписом однієї сторони якусь юридичну силу?

3. Про інтелектуальну власність ... на скільки я розумію, довести, що той чи інший код чи макет чи інший продукт інтелектуальної праці був зроблений в межаж угоди і є власністю замовника — неможливо. Будь-які «цифрові сліди» як то логи, коміти, тіккети є такими, що можна підробити. Що заважає працівнику скачати собі весь код і потім заявляти, що він його сам зробив вечорами вдома, а в актах взагалі не про це йдеться і компанія сама краде його працю? Не хеш-суми ж архівів/комітів в актах вказувати? І навіть якщо так, чи приймє суд хеш-суму в акті як доказ?

Як ви збирали статистику запитів по всій мережі? Щось типу DPI на роутері? Чи агенти на серверах з RDP, що зливають логи підключеннь?

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

— 1946 java файлів на 13Мб суто java-коду. Класів, відповідно, більше, якщо врахувати вкладені. Це лише java. А ще є php з адмінкою, crud-ами, тощо.

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

— про глобальні події я не сильно зрозумів про що ви ... якщо про щось типу event bus, то в чому проблема взяти RabbitMQ ? ... хоча в нас його і немає. В деяких сценаріях ще ZooKeeper може бути.

— щодо сутностей ... сутності різні бувають ... якщо ви про БД, то 127 таблиць в них в сумі 919 полів, в найширшій таблиці 64 поля.

— що ви розумієте під вкладеними колекціями теж важко зрозуміти ... відношення 1:N в БД? якщо поля я порахував grep-ом, то тут так прикинути не вийде :) ... є і 1:N і N:N і їх ніхто не рахував :)

— lazy loading теж різний буває ... якщо ви про те, що разом з об’єктом підвантажуються всі foreign key-ї (чи lazy чи ні), то такого не робимо взагалі. Якщо треба перейти по foreign key, робиться явно ще один запит — корона не злетить. З такої точки зору, більш lazy не придумаєш :)

З однієї сторони, проект, дуже навіть не малий. З іншої, 127 таблиць в БД не так і багато, якщо порівнювати з «деякими». Але, ви знаєте, проектував би зараз, старався б архітектуру розбити хоча б на 2-3 менші сервіси з меншою кількістю таблиць. Наприклад, 100% виніс б всю бухгалтерію кудись подалі, так як вона «погано впливає» на архітектуру в цілому, так як міняється кардинально і часто.

Хотілося б зрозуміти, що відповіді на ці питання вам зможуть пояснити?

Якщо чесно, об’єктивно відповісти важко, оскільки зі spring не працював ... лише читав про нього.
Тому круто було б, щоб ви прокоментували мої аргументи:

1. Щодо netty ... тут можна написати будь-що з будь-яким мережевим протоколом ... але це не чесне порівняння. Щодо http ... можна зробити long push, можна зробити обробку запитів в корутинах (з котліном), а можна і звичайний веб-сервер (що трохи громоздко).

2. SparkJava — стартує в пару стрічок і зробити API на пару викликів — просто і швидко.

3. Щодо HTTP API в цілому ... більшість таких API в нас мають «свій» спосіб підпису запитів та серіалізації. В результаті, робота з http сервером зводиться до невеликої обгортки, яка роутить запит вже по власноруч написаним класам ... і тут абсолютно все-рівно, що там під капотом чи netty чи sparkJava чи щось інше на свій смак, так як робота з цим середовищем робиться лише в двох-трьох файлах.

4. Application server-и ми не використовуєм. Сайти пишем на php, а не на java, тому http весь — це лише server2server api.

5. Щодо dagger ... він compile-time і генерує код, який можна читати. Швидше не напишеш. Конкурентів немає. Не бачу сенсу в іншому підході до dependency injection.

6. gRPC — працює мегашвидко порівняно з REST. Клієнт і сервер генеруються для купи мов програмування. Дуже швидко і безболісно пишеться як сервер так і клієнт. Мінус: в браузері не буде нормально працювати, немає аналога curl, postman, тощо.

7. Щодо бази ... є така ідея, що «базу даних треба поважати». Hibernate, в цих термінах, її «не поважає», і тому з ним проблем більше, ніж рішень (ми пробували лише в одному проекті ... не виключено, що невірно застосували). Але цей пункт краще винести в окреме обговорення, так як гарного рішення «а як, все-таки треба робити» в мене зараз немає. Найбільш адекватним ORM, з моєї точки зору, для java є гугловський Room під Android, але то лише під Android. ... хоча дивлюсь тут jdbi пропонують ... треба глянути до нього ... виглядає непогано на перший погляд.

Щодо фіч spring-а, які, можливо, були б корисні, але в нас явно немає:
— Все таки вирівняна та стандартизована екосистема підходів.
— AOP виглядає круто, хоч і громоздко і привносить в проект магію. Не знаю, що там на практиці з ним, але як мінімум є така можливість і вироблені практики.
— Кругом обіцяють, що має вийти testable код. Якщо так, то круто. Але відчуваю, що безкоштовного сиру там немає.

Dagger для dependency injection,
Netty для «крутого» сервера,
SparkJava для «простого» http сервера,
gRPC для RPC замість REST...
Це коротко про те, що в наших проектах є.

З Hibernate гірше ... їздимо на своєму велику поверх jdbc. Треба якось довести до розуму його і викласти в open source.

Схоже, що ви пишите ці тези базуючись не лише на тезах університетського курсу по БД.
Тому, хотів би почути вашу думку з приводу наступного ....

Великі і потужні БД (той ж oracle) — це дійсно витвір мистецтва. І щоб там відверто не накосячити на великих схемах там дійсно вистачить роботи, щоб цим займалась окрема людина, інколи навіть команда. Це я до того, що я не заперечую те, що в таких випадках DBA є сенс сприймати як повноцінний напрямок роботи.

З того, що я знаю, серйозні БД круто працюють, коли працюють на одному сервері. Тому, з ростом, цей сервер розганяють дисками, процами, пам’яттю стільки, скільки це взагалі можливо (хоч це не пропорційно дорого). З якогось моменту, а може й самого початку додають кілька реплік ... для всяких бекапів, аналітики та read-only запитів чи навіть fail-over (ще один дорогущий сервер). До цього моменту «все нормально». А далі починаються проблеми, проблеми з multi-master рішеннями, проблеми з шардуванням на рівні БД, тощо. Це все складно та працює не так швидко, як хотілося б. Перехід з «одного сервера» на якийсь варіант з кластером, наврядчи можна нормально зробити без змін в підходах як до архітектури самої БД так і до логіки роботи з нею самих додатків.

З іншої сторони, можливим варіантом є відмова від централізації БД. Коли вимоги до масштабування звалюються не на плечі БД, а закладаються в архітектуру самого додатку. В цьому випадку, не виключено, що кожна «нода» такого додатку сама по собі буде мати «свою» БД. Не виключено, що якісь дані (що рідко міняються) і будуть лежати в multi-master кластері. Не виключено, що для певних операцій (наприклад, лог транзакцій) і будуть використовуватися специфічні рішення (наприклад, kafka). Можливо, що навіть в фінансових сферах класичний ACID не такий вже і важливий (подивіться як працюють еквайрингові системи ... там операції по банківських картках точно не ACID ... той самий eventual consistency може досягатися навіть через кілька днів).

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

Знову ж, суб’єктивно, я більше схильний використовувати прості open source бази, ставити до них прості вимоги, і якщо навіть колись якась фігня станеться і треба буде мігрувати, ... це не буде проблемою, так як «не сильно то й ми від бази багато хотіли, те що нам треба вміють всі». А якщо такі рішення не тримають навантаження, значить треба думати як зробити навантаження меншим, чи винести його в іншу форму, чи обробляти іншим чином, чи розподілити його якимось способом...

Ееее... то історія з іншого світу ... в нас тут стартапи і все таке ))

1. Це принципово нічого не міняє. Райський простір ACID операцій кінець-кінцем або тріщить по швам, або стає занадто ресурсоємним і дорогим.

1.1. (сарказм) Це призводить до дорогих БД на дорогих сертифікованих серверах з дорогими сертифікованими обов’язково рейдами в дорогих сертифікованих датацентрах, які обслуговують дорогі сертифіковані девопси/адміни/мережеві інженери, і якими управляють дорогі сертиіфковані DBA.

2. DBA на базі до одного гігабайта (якщо ви подивитесь вище по дискусії — там йшлося про такі випадки) — не занадто?

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

4. Напевно, основне ... не завжди, але часто, великі проблеми з БД вирішуються не на рівні БД. Тому окремий DBA не допоможе, а навіть зашкодить, так як потрібна буде людина, яка знає «що там в БД» і знає «що там поза БД».

З свого досвіду, різниця є ... і їх декілька:

1. поняття ціліснісності БД часто виходить за межі самої БД і все-рівно треба про це думати на рівні додатку, незалежно від того є там процедури чи немає.

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

3. Якщо потрібен таки query builder, то не факт, що в процедурах вийде лаконічніше (наприклад, у випадку типу «а чи треба join-ити отой підзапит»)

4. В додатку, при потребі, можна організувати кешування різного роду, об’єднання insert-ів, додаткову синхронізацію, тощо

на відміну від декількох клієнтів з однією БД, де збережені процедури матимуть перевагу.

Це саме той випадок, коли я з вами погоджуся. А саме, коли ці клієнти писані різними командами, в різний час та на різних мовах. Це саме той випадок, коли БД перетворюється в такий собі «мікросервіс», який і доступ контролює і правила роботи з даними задає. Питання чи повинна цим займатися БД є відкритим та реторичним.

я не розумію чому саме вам довелось кривитись?

Вважайте, що це суб’єктивне враження :)
Просто, згадувавлися не дуже приємні епізоди колупання з БД, що пов’язані з надмірною вірою в те, що оптимізація запитів в СУБД знає що робить і обирає дійсно найкращий спосіб виконати запит чи процедуру.

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

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

Я бачив, умовно, три «види» БД.
1. Малі бази. Це бази, які наврядчи доростуть до гігабайта. В таких базах можна робити, умовно, все, що заманеться. Якось, кінець-кінцем запрацює. Таких баз більшість і до них входять мільйони різних веб ресурсів. Тут можна розважатись як хочеться: і тригери і прцедури :)

2. Бази з великою кількістю логіки. Тут сотні таблиць, близько до нормалізованої форми, проставлені вторинні ключі, купка процедур, можливо і бібліотек процедур, а може і з тригерами. Це, буває, схоже не на БД, а на невеликий мікросервіс з своїм API у вигляді процедур. Такі академічно зроблені бази я бачив в банківських системах.

Все, наче, круто .... але така БД їсть багато ресурсів .... і, що біда, багато ресурсів одного сервера. Горизонтально масштабувати — майже неможливо (хто б що не говорив про реплікацію і подібні речі).

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

3. Бази з великою кількістю даних. Зазвичай в таких базах все на стільки просто на скільки це взагалі можливо. Кожен крок продуманий так, щоб не дай боже щось не затормозило. Якщо десь і є процедура, то цей крок явно прорахований і ця процедура робить рівно те, що ефективно робить БД. Тут, часто використовують і NoSQL і якісь спеціалізовані речі.

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

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

Для логів/журналів/аудит-логів: kafka та/або elastic search.

----

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

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

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

А для чого на php шаблонізатор, якщо php і є шаблонізатор? :)