Чтение некоторых документаций - это не всегда путь к развитию :D
Но вот с репликой про бабосы - соглашусь. Не люблю аналогии, но история уже знала луддитов и наглядно показала, что если бизнесу будет выгодно работать каким-то образом, то все мы будем работать так (или будем работать не мы)
вы всерьёз считаете, что не читать документацию это хорошо?
Возможно так могло показаться, после моих слов о том, что больше не нужно долго разбираться с документацией к какой-нибудь GUI библиотеке. Но это было скорее небольшое ворчание на все эти GUI библиотеки (в документации некоторых действительно долго надо разбираться чтобы понять как сделать что-то сложнее окошка с "Hello World") от человека, который почти все время битики гонял туда-сюда по сетевым интерфейсам, файлики на диск писал и был удовлетворен TUI)
А по теме: конечно, я такую крамолу и помыслить не могу. RTFM и RTFS - наше всё) Говоря в 5-м подходе о ревью того, что там ИИ наделал, я это и имел ввиду в том числе. Представьте, что ваш коллега (живой, не кремниевый) пошел сделал фичу и принес для нее новую библиотеку в проект - до момента ревью вы, скорее всего, тоже не будете вникать что там за библиотека, читать ее документацию и код. А вот на ревью-у-у-у-у-у.... Лично я так и подхожу к тому, что делает ИИ. Потому он у меня и делает PR-ы, а не пушит ничего напрямую.
И еще я в тексте упоминаю, что в проекте должны быть и тесты, и линтеры, и настроен CI, и еще все что угодно, что вы сочтете нужным, что может помочь вам иметь предсказуемые результаты работы программы. И если перед пушем и созданием PR ИИ будет это все прогонять и сам убеждаться что ничего не сломалось (а если сломалось, то чинить), то возможность появления нагенерированной чуши снижается кратно.
Вообще вопрос верификации того, что навайбкожено - это тема для отдельного разговора. В индустрии, кажется, до сих пор идут споры о том как правильно проверять что люди наделали, а мы тут привносим новые сущности в виде гномика в процесс разработки, которые едва ли требуют меньшего (а то и большего) внимания. И тот, кто найдет универсально применимый подход, будет богат, я думаю)
Проходил собес в тиньк на админа и там задавали точно такую же задачу на одном из этапов, именно такая формулировка и была. И, когда я (как и автор) перебрал все возможные проблемы (начиная с 3rd party и баз и заканчивая граничными балансировщиками) и сдался, сказав "Не понимаю где тут еще может быть проблема", интервьювер сказал мне что проблема заключается в том что перед возникновением проблем выкатили новую версию приложения и именно в ней проблема.
Тут все проще, кмк. k8s job не используются, т.к. есть некоторая потребность в управлении жизненным циклом pod-в на стороне Jenkins: управлять переиспользованием и временем жизни поднятых исполнителей и тому подобное.
У меня на практике встречался случай, когда приходилось держать некоторое время под для сборки приложения на JS (которому требовалось выкачивать пару Гб в node_modules), чтобы сократить время повторных сборок. С k8s job такое вряд ли удалось бы провернуть просто потому что, насколько я помню, k8s не позволяет переиспользовать job-ы
Опять же не во всей России все так хорошо:
1) в моем родном городе (г. Нарьян-Мар) до сих пор у родителей старый добрый ADSL модем
2) в СПб год назад я жил недалеко от м. Чкаловская и в квартиру заходил старый добрый коаксиал (ситуация никак не изменилась за год, как я знаю)
Так что заявления в духе «у нас смогли, а у них нет» — немного голословны, кмк
Самым большим открытием этой книги был термин «мотоколсяка» (вместо «sidecar»), docker изображения (вместо образов). Очень тяжелый перевод.
У меня много книг этого издательства, но это первая, в которой терминология меня напрягает.
Уже в этом году (а он только начался) наблюдались «отключения интернетов» в Зимбабве и Венесуэлле. В предыдущим году в Ингушетии был шатдаун. И не то чтобы в этих случаях кто-то «снаружи» его отключал.
А Вы можете назвать случаи целенаправленого отключение интернета для какой-то страны извне?
На мой взгляд, действительность расходится с Вашим мнением и чаще происходят отключения изнутри, а не извне.
Чтение некоторых документаций - это не всегда путь к развитию :D
Но вот с репликой про бабосы - соглашусь. Не люблю аналогии, но история уже знала луддитов и наглядно показала, что если бизнесу будет выгодно работать каким-то образом, то все мы будем работать так (или будем работать не мы)
Возможно так могло показаться, после моих слов о том, что больше не нужно долго разбираться с документацией к какой-нибудь GUI библиотеке. Но это было скорее небольшое ворчание на все эти GUI библиотеки (в документации некоторых действительно долго надо разбираться чтобы понять как сделать что-то сложнее окошка с "Hello World") от человека, который почти все время битики гонял туда-сюда по сетевым интерфейсам, файлики на диск писал и был удовлетворен TUI)
А по теме: конечно, я такую крамолу и помыслить не могу. RTFM и RTFS - наше всё) Говоря в 5-м подходе о ревью того, что там ИИ наделал, я это и имел ввиду в том числе. Представьте, что ваш коллега (живой, не кремниевый) пошел сделал фичу и принес для нее новую библиотеку в проект - до момента ревью вы, скорее всего, тоже не будете вникать что там за библиотека, читать ее документацию и код. А вот на ревью-у-у-у-у-у.... Лично я так и подхожу к тому, что делает ИИ. Потому он у меня и делает PR-ы, а не пушит ничего напрямую.
И еще я в тексте упоминаю, что в проекте должны быть и тесты, и линтеры, и настроен CI, и еще все что угодно, что вы сочтете нужным, что может помочь вам иметь предсказуемые результаты работы программы. И если перед пушем и созданием PR ИИ будет это все прогонять и сам убеждаться что ничего не сломалось (а если сломалось, то чинить), то возможность появления нагенерированной чуши снижается кратно.
Вообще вопрос верификации того, что навайбкожено - это тема для отдельного разговора. В индустрии, кажется, до сих пор идут споры о том как правильно проверять что люди наделали, а мы тут привносим новые сущности
в виде гномикав процесс разработки, которые едва ли требуют меньшего (а то и большего) внимания. И тот, кто найдет универсально применимый подход, будет богат, я думаю)Проходил собес в тиньк на админа и там задавали точно такую же задачу на одном из этапов, именно такая формулировка и была.
И, когда я (как и автор) перебрал все возможные проблемы (начиная с 3rd party и баз и заканчивая граничными балансировщиками) и сдался, сказав "Не понимаю где тут еще может быть проблема", интервьювер сказал мне что проблема заключается в том что перед возникновением проблем выкатили новую версию приложения и именно в ней проблема.
У меня на практике встречался случай, когда приходилось держать некоторое время под для сборки приложения на JS (которому требовалось выкачивать пару Гб в node_modules), чтобы сократить время повторных сборок. С k8s job такое вряд ли удалось бы провернуть просто потому что, насколько я помню, k8s не позволяет переиспользовать job-ы
1) в моем родном городе (г. Нарьян-Мар) до сих пор у родителей старый добрый ADSL модем
2) в СПб год назад я жил недалеко от м. Чкаловская и в квартиру заходил старый добрый коаксиал (ситуация никак не изменилась за год, как я знаю)
Так что заявления в духе «у нас смогли, а у них нет» — немного голословны, кмк
У меня много книг этого издательства, но это первая, в которой терминология меня напрягает.
А Вы можете назвать случаи целенаправленого отключение интернета для какой-то страны извне?
На мой взгляд, действительность расходится с Вашим мнением и чаще происходят отключения изнутри, а не извне.
Не имелось ли тут ввиду слово «реляционная»