Хранимки, конечно, очень мощный инструмент. И очень старый. Но от программирования в БД уходят уже много-много лет - БД сложно масштабировать, да и инструментарий не так удобен.
Конкретика немного есть тут (пара лет с небольшим случаю): https://github.com/apache/solr-docker/pull/13 - образ JRE превратился в тыкву в определенный момент. Веселье в том, что мы обновили docker до актуального из реп - получили новое сообщение об ошибке. И по новому сообщение вышли уже на это сообщение (оказалось, что в репах тоже чуть более старая версия, чем нужно).
Нарывался, что более старая версия docker на сервере не сумела запустить свежий образ (собранный более свежей версией docker). Причем ошибка была не "новая версия образа, не могу прочесть", а что-то прям совсем непонятное и дикое - за давностью не помню, но вроде приложение падало с "нет доступа к ФС".
P.S. причем я как минимум две подобных ситуации помню, как решались проблемы обновлением docker. И оба раза внятных причин сбоя не было - приходилось идти в гугл и искать решение.
А еще версия docker может быть разной. Причем одной у разработчика, другой у CI/CD и третьей на сервере. И у каждой свои нюансы (и несовместимости). Или вообще не docker, а что-то еще стоять может (тот же podman). И кеши сборки могут быть разные, как и базовые образы при том же теге.
Но стоит сказать, что веселья явно стало сильно меньше относительно до-docker времен с "а у меня работает" от программиста. Да и по работоспособности docker-сборки можно с высокой степени достоверности определить, на какой стороне проблемы - у разработчика или на сервере (а может косячить и CI/CD).
Podman как альтернатива Docker. Со временем вы узнаёте, что Docker — не единственный вариант. Podman, например, не висит постоянно в памяти. Можно даже сделать алиас, alias docker=podman, и забыть, что у вас на самом деле не Docker.
Лично у меня с podman как-то не пошло. Много мелких отличий (и это еще ладно, с этим можно разобраться, было бы время и желание).
Но вот технические проблемы заставили вернуться к docker. Простейший пример - неудачный перезапуск контейнера из-за занятого порта прошлой версией контейнера. В чем дело глубоко не копал (не всегда есть время и желание копать подобные проблемы), так что чинился перезагрузкой.
Я бы сказал, что правильная организация процесса разработки помогают заработать процессам вокруг. И да, организация технических нюансов - часть организационных усилий.
Но именно организованность в целом я бы поставил на первое место в этом вопросы, а технические моменты - как следствие.
Никакой "чистый код" и "чистая архитектура" не вовлекут бизнес в процесс разработки. А вот правильные люди и грамотно построенный процесс разработки - очень даже.
На одном из проектов, как-то делал, что транзакция, доступная на запись, только в uow появлялась. Вероятно, это можно было обойти, но сама необходимость обхода хоть немного давала "защиту от дурака", который напрямую в БД писать попробует. Но деталей реализации сейчас уже и не вспомню.
Краткое содержание: Был бардак. Навели порядок (вернее все переписали), повысили прозрачность кода, повысили вовлеченность сотрудников - стало лучше.
Ничего не имею против чистой архитектуры, на надо понимать, что никто и никогда специально не пишет "плохой" код и не делает "грязную" архитектуру. Она такой становится от времени и от накопленного тех.долга.
Переписать все - рабочее решение, и именно это решение - основа успеха. Да, нужна грамотная организация. И нужно тщательно следить кто, что и где делает/правит. А "чистая архитектура" - не более чем повод. С тем же успехом можно было назвать тотальным рефакторингом.
Опять же, бардак образуется естественным путем при развитии системы. Удастся ли через 5 лет активного развития текущую итерацию назвать чистой архитектурой? Или придется снова все переписывать?
P.S. и да, много общего описания без практической конкретики.
Согласен, но не на всех скоростях произойдет опрокидывание, а только на тех, где набранной кинетической энергии больше необходимой потенциальной для опрокидывания. Так что чем ниже центр масс - тем больше безопасная скорость )
Пример с доской не совсем корректен, на мой взгляд. Точка опоры у качели не меняется при наклоне. А вот у неваляшки - меняется, за счет чего она и находит устойчивое положение. К нашему случаю, на мой взгляд, пример с неваляшкой ближе.
Согласен, что сам по себе низкий центр тяжести ничего не гарантирует. Это заслуга и особой формы опоры - при которой любой наклон игрушки делает ее центр масс выше нейтрального положения.
И было бы неплохо оценить, насколько проще загружать/разгружать такую штуку с низким центром тяжести
Думаю не ошибусь, если скажу, что штуку с низким центром тяжести всяко проще грузить/разгружать, чем штуку с высоким при прочих равных (если не рассматривать вариант разгрузки путем само-опрокидывания).
В целом да, должно помочь. Может и не во всех ситуация, но тем не менее...
Правда есть у меня сомнения в надежности подобных устройств в разрезе 140 тонн груза - у подъемных кранов сильно другая механика выдвигания опор и то бывают инциденты. Но это уже несколько другой вопрос, "на глазок" не берусь оценивать )
Я больше скажу - если максимально снизить центр тяжести, при отключении питания точно так же опрокинется, потому что некому держать баланс.
Не совсем так. При низком центре тяжести достаточно зажать тормоз для устойчивого положения. Да, есть некоторые нюансы с кривизной поверхности, но тем не менее низкий центр тяжести поможет. Простейший пример - неваляшка устойчива даже на наклонных поверхностях (в разумных пределах).
Эм... Я писал про опрокидывание при проблемах с питанием / механикой / электроникой.
А опрокидываться будут - просто потому само-балансирующая техника с высоким центром тяжести падает по определению, и в технике есть единые точки отказа (двигатель / шина / электроника и т.д.).
Оно поедет - вопросов нет. Вопрос в аварийности и последствиях этих аварий.
Одно дело вставшее моноколесо - человек спрыгнул, может упал. В редких случаях - бывают и более тяжелые последствия.
В данном же случае любой инцидент - это серьезная авария, останавливающая цикл производства. Да даже БелАЗ можно при поломке в сторону отвести. А тут что делать? Войлоком тащить? А груз рассыпавшийся куда девать?
Высота кузова самосвала меньше высоты текущих колес - не вижу необходимости в 2 раза более высоких колесах. Впрочем, вероятность необходимости увеличения колес не отбрасываю - надо проектировать и смотреть, а не оценивать "на вскидку".
Мотор-колесо + АКБ под днищем + кузов самосвала между колесами - вполне складывается у меня. Правда рама, чтобы колеса не сложились под весом, нужна очень мощная. Возможно, в этом и загвоздка. 140 тонн - это БелАЗ, можно оценить раму под этот груз.
Да и ширина вероятно имеет значение - самосвал должен в существующую инфраструктуру вписываться.
Ну а более длинный предмет балансировать даже проще должно быть - канатоходцы не дадут соврать )
Хранимки, конечно, очень мощный инструмент. И очень старый. Но от программирования в БД уходят уже много-много лет - БД сложно масштабировать, да и инструментарий не так удобен.
Конкретика немного есть тут (пара лет с небольшим случаю):
https://github.com/apache/solr-docker/pull/13 - образ JRE превратился в тыкву в определенный момент.
Веселье в том, что мы обновили docker до актуального из реп - получили новое сообщение об ошибке. И по новому сообщение вышли уже на это сообщение (оказалось, что в репах тоже чуть более старая версия, чем нужно).
И чем это поможет, если я вручную останавливаю контейнер и вручную же его запускаю?
Нарывался, что более старая версия docker на сервере не сумела запустить свежий образ (собранный более свежей версией docker).
Причем ошибка была не "новая версия образа, не могу прочесть", а что-то прям совсем непонятное и дикое - за давностью не помню, но вроде приложение падало с "нет доступа к ФС".
P.S. причем я как минимум две подобных ситуации помню, как решались проблемы обновлением docker. И оба раза внятных причин сбоя не было - приходилось идти в гугл и искать решение.
А еще версия docker может быть разной. Причем одной у разработчика, другой у CI/CD и третьей на сервере. И у каждой свои нюансы (и несовместимости). Или вообще не docker, а что-то еще стоять может (тот же podman). И кеши сборки могут быть разные, как и базовые образы при том же теге.
Но стоит сказать, что веселья явно стало сильно меньше относительно до-docker времен с "а у меня работает" от программиста. Да и по работоспособности docker-сборки можно с высокой степени достоверности определить, на какой стороне проблемы - у разработчика или на сервере (а может косячить и CI/CD).
Ну так девиз современности - "Не быть, а казаться"
Лично у меня с podman как-то не пошло.
Много мелких отличий (и это еще ладно, с этим можно разобраться, было бы время и желание).
Но вот технические проблемы заставили вернуться к docker. Простейший пример - неудачный перезапуск контейнера из-за занятого порта прошлой версией контейнера. В чем дело глубоко не копал (не всегда есть время и желание копать подобные проблемы), так что чинился перезагрузкой.
Я бы сказал, что правильная организация процесса разработки помогают заработать процессам вокруг. И да, организация технических нюансов - часть организационных усилий.
Но именно организованность в целом я бы поставил на первое место в этом вопросы, а технические моменты - как следствие.
Никакой "чистый код" и "чистая архитектура" не вовлекут бизнес в процесс разработки. А вот правильные люди и грамотно построенный процесс разработки - очень даже.
На одном из проектов, как-то делал, что транзакция, доступная на запись, только в uow появлялась.
Вероятно, это можно было обойти, но сама необходимость обхода хоть немного давала "защиту от дурака", который напрямую в БД писать попробует.
Но деталей реализации сейчас уже и не вспомню.
Краткое содержание: Был бардак. Навели порядок (вернее все переписали), повысили прозрачность кода, повысили вовлеченность сотрудников - стало лучше.
Ничего не имею против чистой архитектуры, на надо понимать, что никто и никогда специально не пишет "плохой" код и не делает "грязную" архитектуру. Она такой становится от времени и от накопленного тех.долга.
Переписать все - рабочее решение, и именно это решение - основа успеха. Да, нужна грамотная организация. И нужно тщательно следить кто, что и где делает/правит. А "чистая архитектура" - не более чем повод. С тем же успехом можно было назвать тотальным рефакторингом.
Опять же, бардак образуется естественным путем при развитии системы. Удастся ли через 5 лет активного развития текущую итерацию назвать чистой архитектурой? Или придется снова все переписывать?
P.S. и да, много общего описания без практической конкретики.
Значит с низким ЦТ оно просто не поедет толком.
Ну что же - не очень-то и хотелось )))
А чем "ЦТ близок к оси" хуже варианта "ЦТ выше оси"? Тем более я за "ЦТ заметно ниже оси".
Как бы да, опускать бесконечно не получится - ЦТ ставится не рандомной точкой на чертеже. Так что высокого ЦТ гораздо проще добиться, чем низкого.
Но чем вариант высокого ЦТ интересен - лично от меня ускользает... Разве что ускоряться можно будет сильнее.
Да. Не решит проблемы, но уменьшит - уже хорошо )
Мой изначальный посыл и был о том, что низкий центр масс будет просто безопаснее, а не решением всех проблем.
Согласен, но не на всех скоростях произойдет опрокидывание, а только на тех, где набранной кинетической энергии больше необходимой потенциальной для опрокидывания. Так что чем ниже центр масс - тем больше безопасная скорость )
Пример с доской не совсем корректен, на мой взгляд. Точка опоры у качели не меняется при наклоне. А вот у неваляшки - меняется, за счет чего она и находит устойчивое положение. К нашему случаю, на мой взгляд, пример с неваляшкой ближе.
Согласен, что сам по себе низкий центр тяжести ничего не гарантирует. Это заслуга и особой формы опоры - при которой любой наклон игрушки делает ее центр масс выше нейтрального положения.
Думаю не ошибусь, если скажу, что штуку с низким центром тяжести всяко проще грузить/разгружать, чем штуку с высоким при прочих равных (если не рассматривать вариант разгрузки путем само-опрокидывания).
В целом да, должно помочь. Может и не во всех ситуация, но тем не менее...
Правда есть у меня сомнения в надежности подобных устройств в разрезе 140 тонн груза - у подъемных кранов сильно другая механика выдвигания опор и то бывают инциденты. Но это уже несколько другой вопрос, "на глазок" не берусь оценивать )
Не совсем так. При низком центре тяжести достаточно зажать тормоз для устойчивого положения. Да, есть некоторые нюансы с кривизной поверхности, но тем не менее низкий центр тяжести поможет.
Простейший пример - неваляшка устойчива даже на наклонных поверхностях (в разумных пределах).
Эм... Я писал про опрокидывание при проблемах с питанием / механикой / электроникой.
Оно поедет - вопросов нет. Вопрос в аварийности и последствиях этих аварий.
Одно дело вставшее моноколесо - человек спрыгнул, может упал. В редких случаях - бывают и более тяжелые последствия.
В данном же случае любой инцидент - это серьезная авария, останавливающая цикл производства. Да даже БелАЗ можно при поломке в сторону отвести. А тут что делать? Войлоком тащить? А груз рассыпавшийся куда девать?
Высота кузова самосвала меньше высоты текущих колес - не вижу необходимости в 2 раза более высоких колесах. Впрочем, вероятность необходимости увеличения колес не отбрасываю - надо проектировать и смотреть, а не оценивать "на вскидку".
Мотор-колесо + АКБ под днищем + кузов самосвала между колесами - вполне складывается у меня. Правда рама, чтобы колеса не сложились под весом, нужна очень мощная. Возможно, в этом и загвоздка. 140 тонн - это БелАЗ, можно оценить раму под этот груз.
Да и ширина вероятно имеет значение - самосвал должен в существующую инфраструктуру вписываться.
Ну а более длинный предмет балансировать даже проще должно быть - канатоходцы не дадут соврать )