ага

ну ваще

прямо вот фича года )

надо еще одну опцию добавить чтобы еще git commit -am "Initial commit" делало

В мире Clojure видел даже более полезную вариацию: коммит, в описании которого команда, сгенерировавшая содержимое коммита.

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

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

Я кстати забыл скинуть ссылку на обсуждение но кода в Твери (надеюсь не забанят)


https://tver.io/meetup/nocode/index.html

кто?

за Тверь в чате Спб, как не "профильное" сообщение

было б смешно, если бы за публикацию ссылки на эвроновские митапы гнали из канала ссаными тряпками

просто Тверь это часть спб )))

на питерский

Тверь же практически рядом, даже Москва подальше будет.

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

Всем привет, а кто-то пробовал реализовывать подобную штуку? https://dry-rb.org/gems/dry-transaction/0.13/around-steps/

Чет не заводится. Сначало падало на:

extend Dry::Container, но я подсмотрел в тесты и заменил на => extend Dry::Container::Mixin

Теперь падает на result = block.(Success(input)) => NoMethodError: undefined method `Success' for MyContainer:Class


Мб чет не правильно сетаплю, но с тестов я недопонял, как правильно это готовить

добрый вечер люди
а кто-нибудь деплоит на прод с помощью gitlab piplines? Сегодня решил деплой первый раз настроить, написал конфиг gitlab-ci.yml и понял что для тестов это очень удобно. поднимается образ, разворачивается проект, пустая база, бегают тесты, потом всё сворачивается. Тут проблем нет. Вот с деплоем вопросы, во первых не нашел как в конфиге gitlab-ci.yml экспоузить порты и volumes прописывать, а если еще gitlab-ci.yml в связке с docker-compose.yml использовать то вообще дичь начинается типа докер в докере (dind). Это нормально вообще? Можете опытом поделиться?

JR писали недавно что-то https://jetrockets.pro/blog/scaling-rails-docker-aws-beanstalk

Мы вообще gitlab ci используем, в том числе для деплоя в прод (но там хелм и кубер) и для внутренних тестовых деплоев (там компоуз), но вопрос и суть проблемы не понял.  Особенно не понял, почему в gitlab-ci.yml должны попасть порты.

я к тому что в gitlab-ci.yml можно сконфигуриваться всё тоже что и в docker-compose, по крайней мере для моего проекта достаточно и он также билдит и запускает контейнеры и почему бы только его не использовать. Я предполагаю что вы как и в статье выше тестите и собираете образы и пушите их в репо, а потом оттуда кубер забирает. Я же пытаюсь развернуть на текущей машине, где gitlab runner крутится. Плозая идея?