ну вот докер это костыль для решения проблем линукса - зоопарка дистрибутивов и что каждая программа срёт в систему, отсутствия контейнеризации программ
на java и делал. В итоге не нативный интерфейс, и те же проблемы с форматом распространения. Сделал в итоге баш скрипт установки, благо что баш есть на всех линуксах. И всё равно возникли проблемы с разными форматами sudo su и разной файловой структурой
Вот я пытался делать десктоп под линукс. Сразу проблема: гном или кде? deb или rpc или...? Сделать порты под всё - никакого времени и бюджетов не хватит. Аналогично думают и альтиумы, не хотят вкладывать огромные усилия, больше чем для винды, для мизерного количества пользователей.
Сделайте хотябы чтобы разработка под линукс была дешевле разработки под виндовс
если я знаю как сделать лучше и какой запрос должен получиться, то зачем мне мешающий костыль hibernatе? Зачем мне постоянно проверять его работу и пытаться заставлять его не делать говно? Ради чего?
Когда у вас большая сложная система как раз-таки все эти рукописные SQL и есть самый геморрой с которым никто не хочет связываться, аля : оно как-то работает, давно пованивает, но последний человек, который туда залазил уже 10 лет как на пенсии, поэтому добавим ка мы памяти базе и забудем, когда в следующий раз всплывет эта проблема я уже уволюсь.
Это как раз про хибернейт. Что он там генерит никто особо не знает и не понимает, запросы в логе обфусцированы и их огромное количество, никто не понимает что с этим делать. Лучше добавим ещё памяти
Вот это "мы изменили поле в объекте и оно должно автоматически сохраниться в бд" я считаю порочной практикой. 1) Это магия, сайд-эффект, ниразу не очевидное поведение
2) Похоже у вас в коде бардак, что вы не можете уследить за изменениями объекта и что несколько мест могут внести изменения и перезатереть, а вы об этом не знаете. Я предпочитаю идти по пути бизнес-действие = транзакция. Входные данные, их обработка, сохранение в бд. При чём в бд должны изменяться не все данные, как в случае с хибернейтом, а только изменяемые по этому бизнес-сценарию. Как такое реализовать в хибернейте не представляю. То что у вас объект с данными куда-то уходит, кто-то что-то там делает и вы не знаете что и зачем, и при этом ещё и хотите автоматом сохранить всё что там кто-то наделал - это караул.
Скорее солидную такую книгу страниц в 600. И все это постоянно забывается.
Моё мнение по хибернейту:
Какую проблему решает хибернейт? Борьба со сложностью? Нет, оно добавляет сложность, но маскирует её.
Экономия времени разработки? Возможно, но экономит на самом бутылочном горлышке приложения - общении с БД. Эта экономия вылазит боком при начале эксплуатации.
Остается третий вариант: все используют и мы используем. Кто мы такие чтобы сомневаться в умных дядях.
Возможно изначально это создавалось чтобы избавить от необходимости знать sql. Но на деле выходит что знать sql с хибернейтом надо ещё лучше, плюс приходиться изучать кишочки хибернейта.
У либ в большинстве нет обратной совместимости.
Древняя программа, работающая с либой 1.0, скорее всего не будет работать с либой 3.0.
В java мире тоже есть репозитории либ, но там поступили умнее — у каждой либы есть группа, название и версия. В одном репозитории может одновременно храниться и использоваться одна либа разных версий. В линуксовых репах такое невозможно, отсюда проблемы с обязательным сносом старых либ и попутной поломкой софта
В винде. Копируешь папочку с программой — и программа работает. А не как в линуксе — с копаниями в репозиториях, поиске нужной версии, потом эта софтина засирает тебе всю систему с попутным сносом старых либ (от чего ломаются другие софтины). Именно из-за этого dependency hell и проблем с установкой и поднятием окружения в линуксе и был придуман докер.
Вот какой надмозг придумал репозиторий либ без поддержки версионирования этих либ?
Поддержку автора. Простой пример: написать установщик под максимум возможных систем.
Под винду один единственный — и всё работает на всех версиях и системах.
Под линукс — сразу появляется зоопарк deb, rpm, zypper, pacman,emerge, etc. Разная работа с рутом, для каждого дистрибутива разный софт, проблема с версиями.
Так что в лучшем случае пишется какой-нибудь шельник под убунту, а на остальное забивается большой и толстый. Выбрали конструктор — вот сами и пишите сами себе установщик
обратная сторона — функции с одним действием, как советует какой-то очередной апологет. В итоге вместо чтения кода сверху вниз приходится прыгать по всему коду и куче файлов. Стало ли это удобнее? Нет. Стало ли кода меньше? Нет, стало больше.
Когда стоит делить:
Когда кусок кода используется в нескольких местах
Когда большую портянку возможно разбить на логические блоки
Пожалуй это все причины.
2. В проекте имеется закомментированный код
Чтобы искать в истории надо знать время и место. Закомментированный код показывает место, по нему же можно узнать время.
Или можно делать как в офисном холодильнике — если за n месяцев старый код не понадобился — удаляем его.
Solid это не более чем "нормально делай нормально будет". Там нет конкретных рекомендаций, только ряд весьма спорных абстрактных качеств.
И упоминание этого солид выдает в человеке каргокультиста, начитавшихся модных статей, при этом без понимания — что это и зачем
У вас аргументы в стиле «надо делать хорошо, и тогда проблем не будет». Глупость.
Методы класса зависят от состояния класса — факт. Повреждение состояний вызовет повреждение метода.
И уж тем более завязываться на внутреннее состояние. Давайте уж сразу глобальными переменными хуячить.
Микросервисы — зло.
Тесты это в первую очередь клиентский код
Нет. Юнит-тесты это закрепление текущей реализации кода. Белый ящик, дублирование логики.
Интеграционные тесты — действия пользователей, внешнее воздействие
ну вот докер это костыль для решения проблем линукса - зоопарка дистрибутивов и что каждая программа срёт в систему, отсутствия контейнеризации программ
на java и делал. В итоге не нативный интерфейс, и те же проблемы с форматом распространения. Сделал в итоге баш скрипт установки, благо что баш есть на всех линуксах. И всё равно возникли проблемы с разными форматами sudo su и разной файловой структурой
а если не опенсорс? А если майнтейнеры не делают/не могут/не хотят? Может стоит остановиться и договориться о едином формате распространения программ?
как она может быть дешевле если надо делать пару десятков сборок под все возможные случаи? И одну сборку под винду
сам он не стесняется оскорблять всех вокруг
Вот я пытался делать десктоп под линукс. Сразу проблема: гном или кде? deb или rpc или...? Сделать порты под всё - никакого времени и бюджетов не хватит. Аналогично думают и альтиумы, не хотят вкладывать огромные усилия, больше чем для винды, для мизерного количества пользователей.
Сделайте хотябы чтобы разработка под линукс была дешевле разработки под виндовс
есть жук, позволяющий отслеживать такое на компиляции. Есть тесты. Я например всё взаимодействие с бд делаю через тесты с поднятием базы.
Так в чём суть орм? Кроме неудачной попытки создать слой абстракции над бд
если я знаю как сделать лучше и какой запрос должен получиться, то зачем мне мешающий костыль hibernatе? Зачем мне постоянно проверять его работу и пытаться заставлять его не делать говно? Ради чего?
Это как раз про хибернейт. Что он там генерит никто особо не знает и не понимает, запросы в логе обфусцированы и их огромное количество, никто не понимает что с этим делать. Лучше добавим ещё памяти
Вот это "мы изменили поле в объекте и оно должно автоматически сохраниться в бд" я считаю порочной практикой.
1) Это магия, сайд-эффект, ниразу не очевидное поведение
2) Похоже у вас в коде бардак, что вы не можете уследить за изменениями объекта и что несколько мест могут внести изменения и перезатереть, а вы об этом не знаете. Я предпочитаю идти по пути бизнес-действие = транзакция. Входные данные, их обработка, сохранение в бд. При чём в бд должны изменяться не все данные, как в случае с хибернейтом, а только изменяемые по этому бизнес-сценарию. Как такое реализовать в хибернейте не представляю. То что у вас объект с данными куда-то уходит, кто-то что-то там делает и вы не знаете что и зачем, и при этом ещё и хотите автоматом сохранить всё что там кто-то наделал - это караул.
Хибернейт получается поощряет такое
Скорее солидную такую книгу страниц в 600. И все это постоянно забывается.
Моё мнение по хибернейту:
Какую проблему решает хибернейт? Борьба со сложностью? Нет, оно добавляет сложность, но маскирует её.
Экономия времени разработки? Возможно, но экономит на самом бутылочном горлышке приложения - общении с БД. Эта экономия вылазит боком при начале эксплуатации.
Остается третий вариант: все используют и мы используем. Кто мы такие чтобы сомневаться в умных дядях.
Возможно изначально это создавалось чтобы избавить от необходимости знать sql. Но на деле выходит что знать sql с хибернейтом надо ещё лучше, плюс приходиться изучать кишочки хибернейта.
Древняя программа, работающая с либой 1.0, скорее всего не будет работать с либой 3.0.
В java мире тоже есть репозитории либ, но там поступили умнее — у каждой либы есть группа, название и версия. В одном репозитории может одновременно храниться и использоваться одна либа разных версий. В линуксовых репах такое невозможно, отсюда проблемы с обязательным сносом старых либ и попутной поломкой софта
Вот какой надмозг придумал репозиторий либ без поддержки версионирования этих либ?
Под винду один единственный — и всё работает на всех версиях и системах.
Под линукс — сразу появляется зоопарк deb, rpm, zypper, pacman,emerge, etc. Разная работа с рутом, для каждого дистрибутива разный софт, проблема с версиями.
Так что в лучшем случае пишется какой-нибудь шельник под убунту, а на остальное забивается большой и толстый. Выбрали конструктор — вот сами и пишите сами себе установщик
обратная сторона — функции с одним действием, как советует какой-то очередной апологет. В итоге вместо чтения кода сверху вниз приходится прыгать по всему коду и куче файлов. Стало ли это удобнее? Нет. Стало ли кода меньше? Нет, стало больше.
Когда стоит делить:
Когда кусок кода используется в нескольких местах
Когда большую портянку возможно разбить на логические блоки
Пожалуй это все причины.
Чтобы искать в истории надо знать время и место. Закомментированный код показывает место, по нему же можно узнать время.
Или можно делать как в офисном холодильнике — если за n месяцев старый код не понадобился — удаляем его.
Мисс слаба на передок и не может совладать с инстинктами?
Solid это не более чем "нормально делай нормально будет". Там нет конкретных рекомендаций, только ряд весьма спорных абстрактных качеств.
И упоминание этого солид выдает в человеке каргокультиста, начитавшихся модных статей, при этом без понимания — что это и зачем
Методы класса зависят от состояния класса — факт. Повреждение состояний вызовет повреждение метода.
И уж тем более завязываться на внутреннее состояние. Давайте уж сразу глобальными переменными хуячить.
Микросервисы — зло.
Нет. Юнит-тесты это закрепление текущей реализации кода. Белый ящик, дублирование логики.
Интеграционные тесты — действия пользователей, внешнее воздействие