Дякую за ваши зусилля!

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

Дякуємо вам за ваше починання! У нас канал не повністю україномовний, тому що ми проводимо вебінари та тренінги різними мовами, але україномовного контенту дуже багато

www.youtube.com/...​/UCZvo9jhgokYZFxDeDIdMWzg

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

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

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

В целом я готовился 40 месяцев — чуть больше трех лет.

Потратил на подготовку около семи тысяч долларов, не включая стоимости слотов и перелетов/гостиниц/еды.

Можу розповісти про підготовку до «Одеської сотки».
Вважається, що потрібно перед нею пробігти кросу не менше 100 км, хоча чим більше, тим краще.
Я тренувався приблизно 2 місяці перед марафоном. І це справді непросто, виділяти час, бо вранці мені важко бігати, а ввечері завжди є якісь важливі справи, які доводиться відсувати.
І у вас правильно написано, що в тренуваннях велика складність — не саме навантаження, а нудьга, психологічна втома, що ти годинами робиш одне й те саме. А компанії то нема)
На моїй пам’яті найдовший тренувальний крос, який я пробіг — приблизно 3 години, але я бігав Трасою здоров’я, її довжина 5 км, так що там хоч якась зміна декорацій була.
Ну і на відміну від вашої підготовки — не витратив ні копійки, мені тому і подобається біг, що будь-яка людина може собі її дозволити.

Я одразу згадав марафон «Одеська сотка», в якому сам брав участь — пробігти 100 км за 24 години.
Так от, там теж було змагання «Залізна людина» — спочатку 100 км на велосипеді, а потім у зворотному напрямку 100 км бігом. І це теж за 24 години. Я знав кількох «залізних», це були круті хлопці.

Круто! А в Україні такі змагання проводяться? Чи проводитимуться?

Дякую за огляд, а який у вас був рівень доходу на місяць?

А що щодо спільного використання Node.js та GraalVM? Наскільки це виправдано та які переваги несе?

В двух темах по REST я неоднократно высказывал свое мнение, что REST как и любой RPC, не является хорошей зрелой технологией для получения\синхронизации данных

А з чого ви вирішили, що ваша думка є експертною і когось цікавить? У вас немає жодної доповіді, жодної технічної статті на ДОУ, щоб надати вагу вашим словам чи ви самі себе зробили експертом?

Чому дівчина не любить

Чесно кажучи, я не пам’ятаю, щоб мене просили код показати на самій співбесіді.
Правда, іноді, ще до співбесіди, просять надіслати посилання на свої pet projects або просто приклади коду

Я так розумію, чи це публічна функція в деякому класі?
Тому що я особисто тести на приватні та захищені методи не пишу.
Ок, так от, якщо це публічна функція, це означає, що її повинен викликати якийсь код в іншому класі (компоненті).
А щоб викликати функцію з іншого класу, необхідно розуміти, що вона робить.
Як Java розробник розуміє, що робить той чи інший клас/метод із JDK? Навряд чи він щоразу відкриває його sources. Швидше за все, він читає контракт (документацію) як Java Docs.
Більше того, якщо ви використовуєте поліформізм або інтерфейси (патерн Strategy), ви повинні додати контракт на такі інтерфейси:

interface Executor {
public void execute();
}

Інакше ніхто не зможете реалізувати цей інтерфейс, тому що не розумітиме, що реалізація має робити.
Якщо ви написали метод і не має контракту, як зрозуміти, правильно ви його написали чи ні? Дивитись sources? Але цей метод може використовувати безліч інших класів і так по ланцюжку. Щоразу розкручувати це простирадло? Мені здається незручно та непрактично.

Це по-перше. А по-друге, як ви, наприклад, читатимете код функції, якщо ви використовуєте TDD?
У вас при TDD немає жодного коду функції, ви спочатку пишете тести і потім уже реалізацію (production code)

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

Не треба писати коментарі, вони не зроблять незрозумілий код краще.

Вибачте, але ви неправі.
Коментарі лише тоді зло, коли вони повторюють те, що написано у коді. І тоді справді вам доводиться змінювати код, а потім обов’язково коментар.
Але якщо вам потрібно написати high-level опис методу або класу з кількох рядків, це нормальна практика і без цього взагалі важко зрозуміти, для чого потрібен той чи інший API. У Java це називається Java Docs.

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

Чому??? Я написав REST API, не має значення з думкою про тестування чи без неї.
Написати потiм тести для REST API — звичайна стандартна справа, коли ви формуєте запит, відправляєте його та перевіряєте відповідь. І все.

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

Як взагалі пов’язана складність коду та складність тесту?
Код може бути 1000 разів складним, але перевірити його можна тестом із двох рядків. І навпаки.

Якщо функція є нагромадженням if/else/case, сайд-ефектів, додаткових аргументів та return стейтментів, то буде складно і прочитати її й написати тести.

Я не розумію, а навіщо для написання тестів читати тіло функції та розуміти, як ця функція працює?
А якщо це буде тест, який буде викликати ваш REST API та перевіряти відповідь? У автора тесту взагалі може бути доступу до коду проекту.
Коли ви пишете автоматизований тест, для вас те, що ви тестуєте, має бути чорною скринькою, і ніяк і інакше.
А ви виходить, пропонуєте, писати тести не за документацією до проекту, а за тим, як фактично працює код. А це докорінно неправильно.