Влладалаьаьыджввла?

Каким надо быть идиотом, что бы продавать это от своего имени? Тренируйтесь на здоровье. А если дело дойдет до продажи, то делайте это анонимно. Благо это сделать легко.

Реально ли купить диплом, пригодный для выезда по h1b?

particleaccel, нет. Тогда я протупил и бросил универ, хотя можно было просто заплатить)

Собственно, сейчас так и делаю. Мотивации делать что-то дополнительно, кроме гринки (как-то идти в бодишопы для l1) - нету :(

HTTPS для веб приложения в докере?

mrkotovsk1, ну так и оставляйте, а caddy поставьте на хост как reverse proxy. Конфигурация две секунды займет:

yourdomain.local {
    reverse_proxy http://localhost:20010
}

HTTPS для веб приложения в докере?

Тебе нужен https наружу или ты хочешь https внутри докер сети?

Первое легко решается caddy на хост машине. Это же решение хорошо дружит со всякими лоад балансерами и проксями, типа aws elb или cloudflare.

Второе - имхо нахрен не нужно и только усложняет все.

Как оптимизировать эти запросы на Laravel?

Иван, это невероятно мало. Это даже не мало, это вообще ноль. Даже сотни миллионов в одной таблице - небольшие данные для статистической выборки мускула. У тебя кривые запросы и попытка аггрегировать на с готовыми данными, а не механизмами sql. Это не будет работать.

Как передать на бекенд требования к API?

Антон Бреславский,

Не понимаю, почему не за ним :-) Оно за всеми, в данном контракте 2 стороны.

Потому что как я сказал выше, почти всегда более сильная сторона в проэктировании сущностей - бэк. У него тупо больше опыта в этом, потому что это то, с чем он работает постоянно, в отличии от фронта.

Если бэк сделает в API, то, что не нужно фронтам, нафиг такой бэк?

И в этом часть проблемы. Многие фронты не понимают, что АПИ делают не для них. АПИ делают что бы с приложением (бэкэнд) можно было общаться какими либо методами, а не для фронта/мобайла. АПИ делают таким, что бы с ним мог работать не только фронт, но и какие-нибудь сторонние боты, скрипты, интегрироваться другие системы.

И что бы не плодить эндпоинтов, код, усложнять логику и траблшутинг - АПИ делают универсальным. Да, фронту бывает работать с этим неудобно, особенно если брать в рассчет только одну небольшую фичу. Зато допиливать потом ничего не нужно, когда фронт поменяется, компанию купят для интеграции, откроют публичное АПИ, фичу допилят или переделают и тд.

Так что АПИ не для фронта. Точнее, не только для фронта, даже если других консюмеров на данный момент нет :)

А не из серии: бэк - я так вижу, да будет так, вот вам 1000 полей в пользователе, пофиг что выводить 5 только лишь, а лишние байты зачем?

Ну, нет. Я часто напрягаю фронт делать больше манипуляций, велосипедов, запросов и тд., чем они хотят. Так нужно, что бы упростить и ускорить работу обоим в будущем. Поэтому и появляется мнение о бэкэндарах "я так видящих" - но это лишь из-за непонимания того, зачем делать так, а не иначе. Конечно, хороший бэкэндер и хороший фронт все поймут и договорятся, но без "я так вижу" не обойтись.

Как передать на бекенд требования к API?

Антон Бреславский,

Мне кажется проблема в том, что бекенд разработчики не верно понимают разработку бизнес-логики и разработку интерфейса доступа к ней и к данным. Интерфейс на бекенд может быть HTTP, сокеты ли даже командная строка. Это всего лишь интерфейс. Эти разработчики при проектировании ендпойнта /login часто зашивают в контроллер бизнес-логику, работу с базой, генерацию сессии и т.д. И именно поэтому они связывают проектирование API с разработкой кода функции и именно поэтому когда им нужно добавить например GraphQL им нужно дублировать функционал.

Что скажите? Или API это больше чем данные?

Не понял в чем аргумент. Ну, допустим не понимают. Допустим, им потом сложно реализовать GraphQL (хотя сюрприз-сюрприз, из-за его стандартизации разработчики как раз и дублируют функционал, потому что многие вещи существующие либы для него делают автоматически, а это совсем несовместимо с другим кодом не под graph. Ну да ладно).

Допустим они тупят. Смею предположить, что из-за недостатка опыта? Если дело в этом, то я же не говорил, что бэк всегда прав. Я сказал, что финальное слово за ним, даже если они до этого договорились с фронтом. Если дело не в этом, то я не понимаю в чем тогда аргумент.

Почему заранее нельзя договориться с фронтом как данные будут бегать туда-обратно и начать работу параллельно? Такого кейса нет? Фронты не могут предложить вариант как это видят? Вы на беке дадите добро или внесете изменения и у вас будет контракт с фронтами. Вы спокойно пойдете делать и они тоже. Потом через какое-то время вы соединитесь и проверите, что ваш контракт выполнен. Что тут не так?

Это отличный вариант. Обычно и так договариваются наперед, просто без каких-либо тулз. Согласен, с тулзами будет удобней. Но с ними или без важны две вещи:
1) фронт не должен начинать работу, пока не согласовал контракт с бэком
2) не всегда у бэка есть возможность (например, из-за недостатка времени или из-за предвиденых сложностей) это сделать тогда, когда нужно фронту. Опять же, важно, что бы фронт не начал работать в это время

Если, Вы не делали никогда по другому, не значит что этого нет?

Я такого не говорил :)

Есть не только фронты, есть архитектор наконец, и 5 фронт разработчиков.

Ну, речь то была не об архитекторе, а о фронтах. У архитектора есть соответсвующий бэк опыт.

Есть опытные фронт разработчики и менее опытные бэк, такое может быть.

Может, но маловероятно что даже очень опытный фронт сможет правильно спроектировать сущности на фиче сложнее формы регистрации. Тут даже у менее опытного бэка в одиночку больше шансов, имхо. Но так или иначе, у менее опытного бэка есть вся остальная бэк команда за плечами, которая ему поможет.

Гипотеза: если фронты хорошо знают REST, то это реальный профит, когда они сами могут накидать в Swagger ендпойнтов, которые потом утвердит или поправит бекенд. Если добавить сюда удобный редактор в стиле Notion когда тутже правим и видим превью ендпойинта. А если еще к нему зацепить Swagger с реализованного бэка потом и эта чтука сделает кросс-валидацию и скажет где контракт нарушен - то вообще огонь или нет?

Опять же, все дело в опыте и вероятности. Если фича простая - конечно, им не составит труда спроэктировать сущности и, следовательно, эндпоинты. А вот если она чуть сложнее, то тут нужно будет не знание REST, а опыт с сущностями, которого у фронта нет или очень мало. Поэтому вероятность правильного проэктирования АПИ фронтом, имхо, не слишком высока.

Но да, в целом это вариант, особенно если на фронте опытные ребята.

Как передать на бекенд требования к API?

Антон Бреславский, да, есть картинка, описали с нее вызовы к АПИ. Аж две проблемы:
1) что если на картинке будет не форма из трех полей, а сложная длинная форма с пару десяткой полей? Впихнете все в POST /register? А в результате бэкэнд спроектирует это так, что вы сможете контроллировать каждую сущность по отдельности, и вам прийдется переписывать всю вашу логику с одного запроса на десяток. И какой тогда смысл от вашей работы, вашего проэктирования и ваших моков, если все надо переделывать?

Или вы считаете, что фронт может в проэктирование сущностей (и, следовательно, эндпоинтов)? Нет, не может, только если у него нет существенного бэкэнд опыта.

2) даже с простецкой картинкой фронтом было бы предложено 5 урлов. А бэк говорит: cities тащи из какого-нибудь google places/geocode API, verify-phone будет PATCH запросом на /users/validate, /register будет POST /users. А так как у юзера может быть два и больше телефонов (хоть ради упрощения и выводится только один на форме), то и для телефонов отдельный CRUD. Немного затянуто за уши, но и пример слишком простой.

И опять все выкидывать, вместе с вашими ДТОшками/интерфейсами, моками, сваггером и прочим.

К чему это я: НЕТ никакого смысла преждевременно проэктировать АПИ фронту, если финальное слово не за ним. Это трата времени в пустую. Лучше занять фронта другими задачами, пока готовится бэкэнд. Не обязательно разрабатывать паралелльно, вот и все.

Laravel есть ли хорошая книга?

jazzus, это еще ладно. Но там есть и такое)

$post = Post::find($id);

if (!$post) {
return false;
}

И надейся что кто-то твой false обработает)

Как справиться с проблемами на некоторых моделях телефонов?

rPman, нет. Еще раз: react native не рендерится ни в chromium'е, ни в web view, ни вообще в чем либо похожем на браузер. Оно вообще к вэбу не имеет отношения. JS там запускается отдельно v8'ым.

А вот если бы там был ReactJS, то да, это был бы web view, но это совсем другой фреймворк

Как справиться с проблемами на некоторых моделях телефонов?

react native не на основе chromium и тем более не на основе electron. react native не рендерится в браузере, браузера там нет от слова "совсем".

Как исполнить строку в kotlin?

Maxim Siomin, и это отлично. Нечего исполнять строки.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur,

Покажите мне этот ответ из стек оверфлоу. Я очень удивлюсь, чтобы кто-то писал --lines=100 вместо -n 100 (а -n поддерживается в макос).

Спасибо) Но это всего-лишь пример.

Обратиться к c:\ ?
Обратиться к c:\ ?
Или вы так не делаете? А почему? А может потому что изначально пишете код платформонезависимо?
Так а почему в баш не можете так делать и приводите платформозависимые примеры с --lines=100 ?

Хороший аргумент) Но использовать готовые решения (в этом случае - виртуальная файловая система, относительные пути, конфигурация с абсолютными путями или независимые хранилища типа s3) в языках легко, при том оно будет покрыто тестами, реализация будет несложной, шанс внезапно сломатся - ничтожно низкий. А если запускать все в контейнере, то все это вообще не нужно, равно как и кроссплатформеность .

На примере того же tail все по-другому. tail под linux и tail под macos - может быть вообще двумя разными бинарниками, написанными на разных языках, в разных репо, разными разработчиками с разным, но схожим набором функционала. А еще могут тупо стоять разные версии. Шанс что что-то сломается - в разы выше. И он есть даже с теми же gnu tools, а какой шанс, что сломается какой-нить mysql-client? redis-cli? Огромный. Могут легко между версиями поубирать флажки, подобавлять новых, поменять вывод, переназвать команды.

И тут можно запускать bash в контейнере, но тогда вообще весь профит пропадает, ибо тогда можно запускать что угодно.

Мне как бы никто не мешает вызывать java метод из джарника, вызывая джаву из баша. Я собственно так и сделал - написал маленький код на java, который использует java driver и провожу тесты с разными версиями mongo драйвера. Чтобы тест был релевантным и я мог бы уверенно сказать разработчикам, какие версии java драйвера точно работают.

Ну да. На каждую либу и метод - по джарнику писать? А если вывод сложнее, чем exit code 1/0? А если нужно аргументы передать, будете парсить ввод? Как костыль - ок, но к хорошему решению этому далеко.

Так если не можете привести пример, на чем основывается тогда уверенность, что баш давно пора заменить на другой более мощный и современный язык?

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

баш в качестве универсального языка и оболочки - пока что самый удобный, и альтернативы у него, как я уже писал - ksh или zsh

Ну тут наши мнения сильно расходятся. У современных языков есть вся мощь: асинхронность, параллельность, экосистема, синтаксис. Все это далеко не всегда нужно. Может даже почти никогда не нужно, я не знаю. Но когда оно нужно, вы все равно будете писать отдельную софтинку на другом языке, даже если используете ее в одном скрипте в одном месте.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur,

Как выяснилось, пример совершенно нерелевантный, потому что и для базы и для большинства других вещей как раз именно баш лучше всего подходит.

Ничего не нужно.

На этом можем и закончить) Если вы считаете, что ничего не нужно, то вопрос отпадает и баш клевый. Только я в "ничего не нужно" никогда не поверю.

У любого языка есть свои кастомные штуки при работе в разных ОС.
И совершенно непонятно, почему наличие всего одного флажка вдруг вызывает завал скрипта. Этот флажок может и не использоваться, и в 99% неиспользуется, если ты пишешь скрипт с желанием сделать совместимо.

Ну понятно, что я имел в виду ситуацию, когда этот флажок используется, а не просто висит без дела. Да даже копируя простой tail --lines=100 из ответа стаковерфлоу, совсем не ожидаешь, что оно не работает на macos. Такие же ситуации у меня были с find, не помню точно что именно. Ничего сверхестественного, самые обычные флажки. И не работает.

На джаве легко написать код, который не запустится в 1.8

Конечно. Но мы же не ставим джаву системно, иначе пришлось бы и 1.6 поддерживать, авось у кого-то завалялась :)

или не запустится в макос.

Вы не правы, совсем. Языки прячут os-specific штуки за абстракциями. Добится неработоспособности какого-то кода на одной из платформ - очень и очень сложно. Нужно прямо хорошенько постаратся.

Что значит "компилироваться в баш"? Если мне нужно сделать чекалку подключений к монго в джаве, то я могу написать библиотеку на джава именно с нужной версией джава драйвера, и из баша запускать ее с разными коннекшенами. И это будет проще и универсальнее, чем писать на джава все целиком.

.. нет, не можете. То, что вы хотите, называется не библиотека, а целое консольное приложение. Что бы у нее была точка входа, парсер аргументов, вывод exit code, stdout и stderr. Это в разы дольше и сложнее, чем просто библиотека, которую можно использовать только как зависимость к другому проекту и никак иначе.

Или вы про использование latest в докерфайле?

Да почему latest то? Сменили конкретно указанную версию с 5.7.2 на 5.7.13, в образе дефолтно-запускаемый скрипт сделает все, что нужно. docker compose up убьет предыдущий контейнер, поднимет новый, тот запустит все что ему нужно. Если на енвайронменте еще старый код и он не умеет работать с 5.7.13, то и в компоузе будет старая версия и она не поднимется там, где это не нужно. Тоже самое если девелопер меняет бранчи и переходит с одной на вторую, может хоть 10 раз в день версию менять и происходит это за 15 секунд.

Или можете привести адекватный пример технического решения проблемы путем замена на более современный скриптовый язык?

Не могу, к сожалению. Этот конкретный пример - вообще не место для скриптового языка. А другого примера не знаю, но уверен, что у скриптовых языков есть применение. И именно о таких местах надо было говорить изначально)

Другими словами, вы делаете это вручную, а не используете "более современный язык программирования", о чем и идет речь.

И? Нам автоматизировать процесс принятия сложных решений, ресерча, написания кода, пулл реквеста, мерджа, репорта багов, обновления? С радостью, когда это будет возможно.

А вот такие банальные вещи как обновление стэка - уже довольно давно прекрасно и легко автоматизируется. Как и многое другое. Не надо сравнивать одно с другим.

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

Согласен. Потому что примеры идиотские. Нужен нормальный, который не заменяется другими инструментами.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur,

подавляющее количество софта при обновлении новых зависимостей не требует.

Я поэтому и уточнил, что мы взяли этот кейс для примера. Речь вообще может идти не об обновлении. И даже если говорить об обновлении, то аргумент "подавляющее большинство" не валиден, ибо если есть хоть одна софтинка, которой нужно что-то кроме нее самой, то с этим подходом в корне уже что-то не так, раз он не универсален.

gnu tools - популярные утилиты.

Имел в виду то, что для самих скриптов может быть нужно что-то еще. Такие же доп. зависимости, какие могут быть нужны и в примере выше.

Понятно, что простенькие баш скрипты скорее всего будут работать везде. Но даже у этого нет никаких гарантий! Если у ls на макоси или у ls на ubuntu 10 какого-то одного флажка нет, потому что там ls кастомный или старой версии, то даже с "популярными" gnu tools ваш скрипт завалится.

Баш тоже может использовать библиотеку, написанную на том же языке.

Условная котлин библиотека не компилируется в баш и, обьективно, никогда не будет. А использовать такую библиотеку как executable вы не сможете, так как это библиотека, а не executable :/

Ну значит вы не понимаете, что баш это не оркестратор. Можно запускать не вручную, а через jenkins, можно использовать ansible/chef/puppet и другие вещи.

Справедливо, ок. Но это хак на хаке. Я вел к тому, что решения типа докер компоуза подходят сюда намного лучше, чем любая полу-ручная автоматизация.

Зачем тащить баш именно туда, где уже есть популярные инструменты, которые НЕ являются другими "более современными" языками программирования, а именно инструментами оркестрации???

Так это же вы сказали, что, цитирую: "При этом автоматизировать апгрейд на том же баше - да нет никаких проблем.". Я просто указал, что проблемы есть, и достаточно большие, что бы вообще забыть о подобных скриптовых решениях для таких юс кейсов. Куда-то отклонились от темы.

То есть автоматический апдейт вообще без вмешательства - невозможен, ибо это в первую очередь организационный момент. Про это я и говорил.

Так я же везде указывал, что речь идет об патч, в крайнем случае - минорных версиях. Их автоматический апдейт возможен всегда, ибо +- все следует semver'у или его подобию.

Автоматические секьюрити чеки всегда работают на отлично?

А какая альтернатива? Вручную просмотреть все - невозможно. В современных проектах сотни, если не тысячи зависимостей, если считать вложенные. В каждую из них может влетать по 10+ коммитов в день.

Что вы делаете - обновляете руками эту библиотеку в фреймворке, или обновляете весь фреймворк?

Принимаем решение исходя из цены и выгоды обеих решений. Если обновить весь фреймворк на данный момент сложно или он еще не стабилен - форк и обновляем руками библиотеку, либо откатываем фреймворк если это не критично. Если можем малой кровью обновится и это заодно пофиксит проблему - делаем так.

А если нет версии этой библиотеки без уязвимости (по словам вашего секьюрити чека), как вы обходите завалившийся чек?

Обьективно, уязвимости находятся довольно редко. Еще реже уязвимый функционал используется в проекте. Еще реже складывается ситуация, позволяющая конкретно в нашем случае использовать уязвимость. Таких ситуаций одна на миллиард.

Если вдруг не повезло - руками апдейтим, конечно же.

И самое интересное, как это у вас все выполняется полностью автоматически?

Так речь вроде была про аудит. Фикс багов не часть аудита.

Я уверен что регулярно приходится что-то делать руками.

Угу. А еще нам приходится писать код oO. Надеюсь это не была попытка сравнить возможную на данный момент автоматизацию и невозможную.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Vitsliputsli, https://docs.aws.amazon.com/AmazonRDS/latest/Auror...

Посмотрите чейнджлог. То, что есть более старая минорная или, тем более, трехгодичной давности мажорная версия, вовсе не значит, что они более стабильны и что в них нет тех самых багов, поправленных в новых версиях. Это вовсе не "новинки". Патч и, в случае некоторых продуктов, минорные версии - это как раз стабилизация предыдущей версии.

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

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur,

Обычно апгрейды самой базы не требуют никаких дополнительных зависимостей. Все зависимости которые нужны - они нужны для работы самой базы и уже установлены. А вот ставить дополнения и зависимости для "скрипта, который запустит обновлялку" - imho перебор.

Ну мы же для примера взяли базу и вообще процесс обновления) Явно не может быть такого, что всегда обойдется без зависимостей, это нонсенс.

Все нужные для работы баша бинарники

Для баша? Или для типичных (опять же, типичных в моем понимании) скриптов на нем? Первое - это понятно, а второе - отписал выше)

То есть фронт и бек у вас всегда один микросервис? И написан на одном фреймворке?

Нет. Вы же спросили про "метод", я про него и ответил. Фронт и бэк априори не могут быть на одном фреймворке, но легко могут использовать библиотеку, написанную на одном языке.

Я не понимаю. Почему для вас баш - это обновление руками?

Ну не прям руками. Но и не автоматически. Опять же: есть у вас 50 девов и в придачу еще 6-8 стейдж/прод енвов. На каждом будете вручную запускать скрипт, даже если допустить, что он универсально выполнится на linux/macos/docker разработчиков и условный ubuntu/docker стейджов? А если через день найдется бажок и нужно будет откатить? Опять все руками?

Это, все таки, разные вещи. Если вас в команде 3 человека и у вас только стейдж и прод - ок, это терпимо. Но с любым более-менее большим проектом это совсем не работает.

плохую базу...

AWS Aurora mysql :) А если серьезно, бывает, не могу сказать, что база прям плохая. Можно перейти на aurora postgre, но это сложно на живом большом проекте)

Зачастую смена версии фреймворка может потребовать неслабых изменений в коде.

Патч и даже минорная - нет, не требует, иначе вам стоит сменить фреймворк. Если мажорную - конечно, но мажорные версии любых больших продуктов выходят не чаще раза в год. Там подготовка, согласование и костыли при апдейте - вполне нормальны.

У вас очень, очень, очень простой проект.

Это не так. В нормальной разработке именно так и должно быть. Для обновления зависимостей во всех языках есть менеджер зависимостей, собирающий нужные версии нужных библиотек, под нужную платформу и в нужном порядке.

Вдобавок вероятно нет аудита и возможность ставить что хочется из инета напрямую.

Вообще я не понимаю, как это связанно с тем, о чем мы разговариваем. Но все проходит через пулл реквесты, встроенные автоматические секьюрити чеки и проверку лицензий. Если имеется в виду ручной аудит, то это либо просто еб*нутые конторы, которым некуда потратить сотни тысяч на разработку собственных решений (вместо тех, которые предполагаемо не пройдут аудит), либо очень большие конторы, которым это даже выгодно.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Vitsliputsli, новые патч версии наоборот более стабильны. Возможно выше назвал их "минорными" - если так, то имел в виду именно патч. В них только багфиксы, они априори не могут быть менее стабильными)

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

А ваши апгрейды базы не требуют доп. зависимостей? Вот прям никаких? На голом alpine все запустится? Не смешите.

Зависимости нужны почти всегда. Лично мне даже лучше, если это будет одна единственная джава машина (или не только она - котлин, вообще то, компилируется не только в джаву, можно и в обычный бинарник, как с джавой внутри, так и вовсе без нее), чем тонна непонятных бинарников на уровне системы непонятных версий и, как сказали выше, с непредсказуемым IO.

А если у вас 5 микросервисов, у вас будет 5 мест или одно?

Одно, конечно же. Либо один микросервис, либо одна общая библиотека.

Непонятно что такое за разные места и в чем заключается сложность. Я редко встречал проекты, написанные один в один - как минимум бэк и фронт зачастую разные фреймворки, а то и разные языки программирования, вот уже два места вместо одного. И в чем собственно проблема?

Так очень малое кол-во кода как-либо шерится между фронтом и бэком. Это просто разные миры. Хотя, опять же, тот же kotlin-multiplatform позволяет компайлить куски кода одновременно и в джаву на бэк, и в джаву на андроид апку, и под айос, и под фронт. И да, это используют, дабы упростить и ускорить разработку, а так же свести риск проеба к минимуму.

Фиксы для базы, которые могут вызвать несовместимость данных

Это патч версии. Если сильно боитесь, можно поднимать снепшот, апгрейдить базу, запускать тесты и потом уже апгрейдится. И это спокойно можно делать на CI, автоматически по смене версии базы в каком-нибудь docker-compose.yml.

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

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

Вот вы пишете на фреймворке, а к нему выходят те же обновления уязвимости. Как вы его обновляете каждый месяц? Или фреймворк вы так часто не обновляете, и почему-то считаете что уязвимости в базе важны, а в фреймворке нет?

Я не говорил про уязвимости) Я говорил про очевидные баги базы, вызывающие проблемы у конечных юзеров проекта. Да, если в фреймворке есть таковые и оно решено в новых версиях - мы поднимаем версию, конечно. Только дебажить проблемы в фреймворке почти всегда очень легко, а дебажить проблемы с базой - почти всегда очень сложно. Поэтому фреймворк обновлять регулярно нужды, обычно, нет, но можно. И обновляем мы его меняя циферки версии в одном файле, diff на одну строчку :)

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

Saboteur,

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

Верно. И у bash нет нормальных тест-фреймворков.

Это должно решаться средствами того языка, на котором пишется проект.

Речь о тестировании самих bash скриптов. Понятно, что к проекту это не имеет отношения.

как девопс

Я не девопс) Я разработчик с малюсеньким опытом девопсинга)

Я это решаю в первую очередь CI/CD инструментом, в котором может использоваться и простые bash скрипты и сложные технические решения вроде GRP в оракле или kubernetes.

Конечно, да. Но тут либо CI/CD решает 100% задач, либо приходится допиливать что-то. И, опять же, редко когда удается допилить требя строчками bash скрипта.

Вот каким именно нормальным ЯЗЫКОМ вы это решаете

Ну вот помимо существующих CI/CD, с радостью попробую kotlin script.

А в чем проблема, если каждый инструмент будет лезть в github своим методом?

В том, что этот метод нужно поддерживать в двух местах, вместо одного? Насобирать три-четыре таких места и никто не захочет это трогать.

Апгрейд версии?

Да.

База в кластере, апгрейдим по очереди ноды, соблюдая инструкции совместимости и все.

И как это решает то, что люди (девопсы) за*бутся апгрейдить ее постоянно ручками? Да никак, проекты тупо забивают и скедьюлят "апгрейд архитектуры" раз в миллион лет - ну потому что не будут же они обновлятся раз в месяц. А фиксы, нужные фиксы базы, релизятся раз в месяц, если не чаще.

Значит у вас нет потребности в стабильности крупной базы, если self-hosted достаточна.

На моем рабочем проекте - к сожалению есть потребность, у нас aws aurora. И это ужасно, но абсолютно понятно - мы пожертвовали фичами и понятностью в пользу стабильности и авто-девопса. Но это крайние меры, а не дефолтный путь.

Опять таки, в большом проекте апгрейдиться на каждую минорную версию совершенно неподходящее решение.

Вы же понимаете, что минорные версии выходят не с фичами, а с багфиксами? Бывает (чаще чем хотелось бы - достаточно глянуть на историю версий mysql и станет ясно) что именно в минорную версию все упирается. И лучше, если минорную версию можно поднять за 2 минуты, обновится, подождать чуток и посмотреть, разрешилась ли ситуация, а не тратить дни на дебаг и потом мучатся с апгрейдом.

Совпадать опять таки должна не всегда, httpd редко вызывает несовместимость, это же не php

... очень бредовый аргумент. PHP тоже обратно-совместим по большей мере, как и большинство инструментов. В новых версиях появляются новые фичи и фиксы. Их не использовать? А еще не все используют httpd и тут вообще вся идея рушится)

Попробуйте так стэк пообновлять у 50 девов и на 6-8 средах - желание повторять отпадет еще до того, как вы это первый раз провернете.

Ваша проблема, что вы кидаетесь словами подразумевая какой-то свой локализированный случай, но при этом пытаетесь сказать что ваш опыт в конкретном проекте с конкретной инфраструктурой обязательно должен подойти всем.

Наверное. У меня недостаточно опыта с bash, что бы привести больше примеров и говорить за всех. У меня сложился такой опыт, что использовать баш для скриптов я не хочу, так как вижу, что другие инструменты решают его проблемы. Возможно за рамками юс кейсов, которые я видел, ситуация совсем другая.

Почему для скриптинга в шелле используется bash а не более современный язык программирования?

DevMan,
я смотрю на это со стороны девопс. Ее ставить не нужно - предполагается, что используются контейнеры, а их не переживет разве что мой роутер или умная лампочка)

Saboteur,

огромный оверинженеринг для вещей вроде копирования файла
Вам самому не смешно от этой чуши?

Конечно смешно. Но давайте поговорим не о копировании файла, а, например, о билде и деплое проекта. Тут ненужная до того мощность языка как раз нужна. Из банального:
- погрупировать таски
- записывать время выполнения каждой мелкой таски
- проверять что она не завалилась
- репортить все это в какой-нить слэк в конце
- делать ролбек в случае неудачи
- подчищать за собой остатки

Все это делается очень легко с помощью нормального языка. С bash это адская боль.

Баш тоже легко тестируется - +x и все

Я про автоматические тесты.

Непонятно что такое шарить код между проектом и скриптом автоматизации - скрипты на баш это просто код.

Ну, например в проекте есть код, вытаскивающий актуальную версию чего-то там с помощью какого-нить github SDK. Потом эта версия понадобилась в каком-то скрипте. Если проект и скрипты на одном языке - это элементарно шерится. Если на разных - проще вообще не шерить.

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

Ну да. Как часто вы обновляте базы на продакшене? Девелоперы хотят делать это условно раз в месяц, но без контейнеров заниматся этим будут в лучшем случае раз в два-три года.

Именно поэтому в нормальной ситуации вы не ставите себе в облаке базу, а используете готовое облачное решение.

Да нет, не использую. Над таким "облачным решением" обычно ноль контроля - оно падает когда захочет, обновляется только руками в дешборде, отстает по версиям от self-hosted.

Единственная причина, по которой я бы использовал готовое облачное решение - так спокойней за ценные данные. Остальное будет жить в контейнерах.

Зачем обновлять контейнер с httpd, если httpd это практически по дефолту уже установленный в системе сервис, и обновить его можно не косячным скриптом с контейнером, а штатным пакетным менеджером.

Затем что обновлять его нужно одновременно у девов, QA, на тестовых, на стейдже, на продакшене. На каждом хосте ручками ставить нужную версию? А она же еще совпадать должна!

Ну вот, можете посмотреть на баш-скрипт посложнее: https://github.com/sfkulyk/jks-manager/wiki

Не понял к чему это. Показать, что на баш можно написать хороший код? Если это пример такового, то я извиняюсь, но это плохой код. Не в рамках баша - возможно для него он хорош, а в сравнении с тем, как бы тоже самое выглядело на любом современном языке. Это тяжело читать, там много дубляжа, это невозможно будет протестировать никак кроме как руками.

Возможно, если подобную програмулинку не нужно поддерживать, так как в ней минимальный функционал - оно и ок. Но так же не всегда)