« У того, кто может двигаться между планетами, на которых можно жить, есть надежда. » Надежда на что? Почему надежда у того кто может двигаться между планетами должна как-то отличаться от надежды того кто может двигаться между городами и странами?

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

Нет в этом ничего печального. « даже владыка-просто пылинка » А двигатель планет не пылинка? Владельцем какого количества камней в космосе ты должен быть, чтобы тебя перестала мучить эта мысль?

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

« Поправил заголовок темы, тем более, в тексте темы автор уточняет, что речь именно про бесплатность. » Опять ведёшься на наброс. И совершенно зря. Совершенно очевидно что автор наброса использует модерирование как аргумент в споре. Вместо того чтобы начать обсуждение неоднозначного вопроса на равных в самом треде он призывает модераторов, чтобы они назначили его «правым» административными средствами. И делает это уже не первый раз.

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

Забавный тред. Половина участников говорит agile не нужен потому что всё и так очевидно. Другая половина в упор не согласна эту самую очевидность понимать и признавать.

Там вообще-то ссылка на пдфку есть. Как раз для того чтобы не смотреть сам доклад целиком.

Собственно вот идеальная иллюстрация к вопросу зачем нужны все эти «agile-болтуны». Они нужны затем чтобы не тратить время инженеров коллег по команде на вот таких вот «мозговитых» кадров, которым надо с нуля объяснять суть регулярных релизов, почему это не значит «умереть но доделать фичу в завтрашнему дню» и как это вообще работает. То есть ты либо отправляешь человека к ним самообразовываться, и agile-болтуны слава богу написали уже тонны всяких материалов по теме с примерами, пояснениями, опытом из жизни и всякими такими вещами. Либо если человек безнадежен - отсеиваешь на раннем этапе.

« В каких областях можно делать релизы по расписанию? » В любых. Как бы то что этот принцип встречается как у Эрика Рэймонда, так и в «суровом энтерпрайзе» с Lean Agile Scrum и этим вот всем намекает. « Кто те сотрудники, которые могут автоматически релизить по расписанию хоть что-то? » Кто угодно. Надо только сесть и хорошенько подумать, что такое вообще «релиз».

« Спасибо за развернутое определение понятия «абстрактная хрень». » Я думала программисты отучаются от позиции «если это нельзя увидеть и пощупать - этого не существует» где-то на первом месяце обучения, а поди ж ты.

« Монолит — это и есть «простой случай». Самый простой, какой только может быть, все проблемы распределенных систем к нему не относятся. » К нему относятся все проблемы монолитов.

Слайд 7 отсюда: https://fosdem.org/2022/schedule/event/centos_stream_stable_and_continuous/

« Мне не совсем понятно сарказм это или нет. » Нет, это не сарказм. « Поэтому далее ещё более непонятно, как верно - «по расписанию» или «подстраиваться на каждом шаге». » Тут нет противоречия Релиз по расписанию - это шаг. Вот на каждом таком шаге ты смотришь на то что получилось и спрашиваешь себя туда ли ты идёшь и с правильной ли скоростью. И если нет, то начинаешь искать всякие разные способы исправления. https://en.wikipedia.org/wiki/Release_early,_release_often

« А вот agile, это как если бы специальные болтуны рассказывали про гибкие методы программирования, чтобы программы были гибкими » Ну давай сделаем вид что ты никогда не слышал, чтобы кто-то предлагал сначала написать бекенд со 100500 моделями, потом к нему приделать фронденд. Потом покрыть это может быть тестами. Ну а потом начать задумываться о том как это в итоге будет выкатываться в прод. Agile как подход это не про стикеры, а например про то что надо сначала создать полный цикл, включая тесты и выкатку, обрабатывающий один запрос и одну модель, после чего наращивать вширь итерациями. И это не формальности, для реализации такого подхода нужно выбирать соответствующую архитектуру. То есть приходится подстраивать всю разработку. Также например Agile про то что выкатывать обновления надо по расписанию, а не по готовности. Потому что «готовность» - это плавающая цель, а нужно смотреть на то что есть здесь и сейчас и подстраиваться на каждом шаге. И много других подобных «очевидных» вещ

« «ООП не работает, нам обещали большую гибкость и переиспользование кода, а в реале приходится всей командой над иерархией классов дрожать» » Так можно. Идеальных беспроблемных решений не бывает. Ни ООП ни Agile не могут магически сделать всё легко и просто. И не обязаны. Но фишка в том что ни от Agile, ни от ООП ты никуда не денешься. И не потому что все дураки и не лечатся, а потому что несмотря на все проблемы это работоспосбный подход дающий результат.

Нет, если ты про agile знаешь только стикеры на доске, которые вообще-то не agile, а kanban, то это как раз уровень фломастеров. От классов, фабрик и т.п. оно далеко очень.

« У нас всё сводится к тикетам в джире и цветным стикерам на доске (или их виртуальным аналогам). После чего те же самые люди делают ту же самую работу. » Стикеры на доске = линтеры в code review, или даже подсветка кода в IDE. Сами по себе они ничего конечно не решают и плохой код хорошим не делают. Но говорить о том, что они вообще не нужны и ничему не помогают тоже неверно. И неверно говорить что «ООП не работает, потому что мы пробовали стрелочки на доске фломастерами рисовать, а код лучше не стал»

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

Agile - это такой unix-way для управленцев. То есть это некий принцип, имеющий под собой вполне разумные основания. Но при применении на местах либо не виден, либо не работает, либо работает не так, либо вызывает совершенно безумные холивары на тему что это всё же такое. И при хорошем управлении ты не будешь особо задумываться, что оно у тебя Agile, потому что применяемые практики будут «самоочевидны». А при плохом никакие лозунги и книжные рецепты не помогут.

7.1 Ответ на некорректное сообщение (авто, уровень 0) (-2) Пункт 7.1 правил форума https://www.linux.org.ru/help/rules.md Не надо в ответ на троллинг писать оскорбления троллю и вступать с ним в перепалку. Игнорируй его и/или пиши в соответствующий тред чтобы троллинг почистили Ссылки на некорректные сообщения (57) https://www.linux.org.ru/forum/linux-org-ru/16693570

12 страниц хейтили контейнеры, пришла пора переходить на людей?

« Вопрос вот какой. Получается эти федоровские флатпаки можно себе устанавливать в виде докер-контейнеров командой docker pull bla-bla/baobab? » Я не разбиралась в деталях, но скорее всего да. При этом flatpak вероятно делает кучу других полезных вещей, типа складывания этих образов отдельно от просто контейнеров, прокидывания правильных каталогов внутрь, расшаривания устройств по необходимости, создания desktop-файлов, настройки профилей и т.д. и т.п. То есть всё это можно было бы сделать и руками запустив контейнер из образа, но только это было бы сравнимо с однострочником для установки генты.

« У Васи Пупкина её нету, и потому ваши решения ему не подходят. » Давай ты откроешь тред на начало и найдёшь где и что я советовала ТСу. Spoiler: я не предлагала ему развернуть кубернетес. Разумеется в разных случаях требуются разные решения. Фишка в том что ты не понимаешь и не знаком с «99% процентами» «типовых» случаев, но прибежал в тред рассказывать как все неправы.

« Я имел в виду, что Ландау писал для гораздо меньшего количества людей, чем пишет, например Шалыто или Майерс. Соответственно его аудитория более калиброванная и отборная и там люди действительно могут свободно читать формулы и им не нужны графими и прочая визуализация. » Он для студентов первокуров, то есть вчерашних школьников писал если что.