Два года назад перешли с MongoDB на PostgreSQL и забыли о ней, как о кошмарном сне.
Может, конечно, «вы не умеете их готовить», но…
Непривычный синтаксис (NoSql, чтоб его...)
Низкая скорость записи. Блокировать всю коллекцию при добавлении документа — это круто.
Невозможность создания ссылок на другие коллекции
При восстановлении базы из бекапа (пара терабайт объемом) MongoDB благополучно падала
Слабый функцонал Spring Data. Да, на CRUD вполне хватает, но какие-то запросы посложнее приходилось создавать с ощутимым напрягом
Это только то, что вспомнилось с лету.
Но, самое главное — в чем смыл такой связки?
MongoDB предназначена для хранения документов произвольной структуры.
Но Java-то этого не умеет!
То есть, мы или храним документы одной и той же формы (тогда зачем нам MongoDB?), либо скатываемся до безтиповых данных, работая с документом как с Map (что чревато).
А не хотите ли получить при старте сервера сообщение "Error 10.", а в FAQ прочитать "Если вы при старте сервера видите бокс с сообщением Error 10, удалите пустую строку в конце конфиг-файла"?
Это при том, что конфиг-файл генерится инсталлятором...
И это при том, что софтина стоила (на тот момент, не знаю, сколько сейчас) около 30к евро, а недельные курсы по работе с ней - около 100к.
Вы скажете "имя, сестра, имя?" Извольте - IBM WebSphere Commerce Suite. Должен уточнить сразу - это было 20 лет назад, надеюсь, такие "фичи" давно исправлены. Но это было, факт.
Ну, я вот гуглю, как прочитать данные с клавиатуры.
Как открыть и прочитать файл.
Как открыть JDBC коннект к базе.
И да, 20+ лет джавы.
И делаю это по одной простой причине — подобные действия делаются один раз в несколько лет (да и то не факт, можно просто скопировать этот код с предыдущего проекта), и улетучиваются из памяти сразу же, как закрыл вкладку с классом.
Ой ли?
Взятый на имя бомжа хостинг, развернутая там ip-фония… и будет потом голова у почты болеть, где ж этого бомжа найти, чтоб ему квитанцию о штрафе вручить.
И это если не принимать во внимание принципиальную невозможность определить — это действительно спамит контора А или эту кампанию заказала контора Б, чтобы утопить конкурента.
Нет. К сожалению, спам не уничтожим. Ибо цена его все ниже, а из-за того, что 95% населения — идиоты, всегда найдется тот, кто поведется и тем самым сделает рассылки рентабельными.
Умрет он, только если действительно народ перестанет на него вестись ВООБЩЕ. Но… см. выше про 95%
Причем не умозрительные рассуждения, а опыт трех лет практической работы с подобным «конструктором Лего» (конкретно — с Intershop Enfinity Suite). И я скажу так — это худшее, что со мной случалось за весь мой 25-летний стаж работы программистом.
Хорошего можно сказать только одно — это красиво выглядит. ВСЕ!
Дальше идут только одни проблемы:
— передача данных между блоками. Реализована в виде банального dictionary — то есть прощай типизация. Чтобы понять, что идет на выход из одного блока, и что идет на вход другого — изучай properties каждого блока. Отдельный привет, если данные не совпадают по формату — приходится лепить промежуточный блок для конвертации. А теперь мысленно представьте, какую площадь занимает Map<ID, List> -> List. То, что на чистой джаве укладывается в пять строчек, занимает пол-экрана.
— найти нужный блок. Медитируешь, пытаясь понять, какой из 20 блоков xxxPricexxx тебе нужен — а в итоге выясняется, что нужен какой-нибудь applyVAT
— громоздкость. Отлично, когда диаграмма простенькая, линейная и укладывается в в один экран. Но, с более-менее сложной логикой… это постоянный скроллинг в стороны, изменения масштаба и прочие удовольствия.
— ну, и least but not the last — code merge. Это просто аццкий сотона в кубе! Какие-то конфликты сложнее «добавить один блок посередине» можно решить, только очищая диаграмму, а потом ручками накатывая на нее блоки. Иначе либо отказ в автоматическом мерже (в лучшем случае), либо абсолютная каша из двух веток с совершенно рандомными переходами.
Можно было бы вспомнить еще — но и этого более чем достаточно, чтобы сделать вывод: идея красивая и наглядная, но в реальной разработке совершенно негодная.
Повторюсь еще раз — это не теоретические мысли, это опыт практического использования такой системы во вполне реальных проектах. Упаси Боже от таких «улучшений»!
Право на труд гарантировано Конституцией.
Соответственно, любой договор/соглашение/ограничение этого права идет лесом.
Как бы иного не хотелось работодателю.
Да, насколько я понимаю, в наших юрисдикциях соглашения о том, что работник не будет в течении какого-то времени после увольнения конкурировать с работодателем — ничтожны. Хотя это был бы вполне цивилизованный способ предотвращения ровно таких ситуаций.
Серьезно?
То есть, уволившийся из ресторана повар должен 1-3-5 лет идти на стройку класть кирпичи, а не устроиться через дорогу в другой ресторан?
Вот заходите вы в магазин часов (ну, вот нужны они вам срочно). Бюджет — 100 баксов.
Вам с порога объявляют, что часы у них — от миллиона до двух. Экономия времени? Безусловно.
Точно так же вилка может помочь при устройстве на работу. Каким бы шикарным спецом не был кандидат, платить ему 10к зелени, когда есть ресурсы платить только тысячу, никто не сможет.
Ну и, банально, такой спец просто не отошлет резюме на заведомо неприемлемую вакансию.
ИМХО — нет никакой трагедии в том, чтобы использовать диаграммы Венна. С одним условием — уточнять, что они применимы только для ключей (точнее, для unique полей). В случае же дубликатов схема другая. Да и все.
Диаграммы просты и понятны, а JOIN, ИМХО, в 99% случаев идет по ключу. Не знаю, как у других, а у меня лично за 20 лет программирования ни разу не возникла необходимость использовать какие-то другие поля.
Это, примерно, как с математикой — в школе нас несколько лет учат, что квадратный корень из отрицательного числа взять нельзя, а в институте внезапно появляется мнимая единица.
Может, конечно, «вы не умеете их готовить», но…
Это только то, что вспомнилось с лету.
Но, самое главное — в чем смыл такой связки?
MongoDB предназначена для хранения документов произвольной структуры.
Но Java-то этого не умеет!
То есть, мы или храним документы одной и той же формы (тогда зачем нам MongoDB?), либо скатываемся до безтиповых данных, работая с документом как с Map (что чревато).
Видимо, да.
Я не знаю, к примеру, как можно объяснить, почему инсталлятор при одном запуске пишет путь как "D:\\WCS", а в следующий раз "D://WCS".
Запустишь еща раз - опять "D:\\WCS".
После таких сюрпризов удивляться пустой строке, которая валит запуск сервера, я уже перестал.
Занятный был софт, да...
Ошибки в бесплатной Android Studio...
А не хотите ли получить при старте сервера сообщение "Error 10.", а в FAQ прочитать "Если вы при старте сервера видите бокс с сообщением Error 10, удалите пустую строку в конце конфиг-файла"?
Это при том, что конфиг-файл генерится инсталлятором...
И это при том, что софтина стоила (на тот момент, не знаю, сколько сейчас) около 30к евро, а недельные курсы по работе с ней - около 100к.
Вы скажете "имя, сестра, имя?" Извольте - IBM WebSphere Commerce Suite. Должен уточнить сразу - это было 20 лет назад, надеюсь, такие "фичи" давно исправлены. Но это было, факт.
Как открыть и прочитать файл.
Как открыть JDBC коннект к базе.
И да, 20+ лет джавы.
И делаю это по одной простой причине — подобные действия делаются один раз в несколько лет (да и то не факт, можно просто скопировать этот код с предыдущего проекта), и улетучиваются из памяти сразу же, как закрыл вкладку с классом.
На джуна меня не возьмут, да? :-)))
Взятый на имя бомжа хостинг, развернутая там ip-фония… и будет потом голова у почты болеть, где ж этого бомжа найти, чтоб ему квитанцию о штрафе вручить.
И это если не принимать во внимание принципиальную невозможность определить — это действительно спамит контора А или эту кампанию заказала контора Б, чтобы утопить конкурента.
Нет. К сожалению, спам не уничтожим. Ибо цена его все ниже, а из-за того, что 95% населения — идиоты, всегда найдется тот, кто поведется и тем самым сделает рассылки рентабельными.
Умрет он, только если действительно народ перестанет на него вестись ВООБЩЕ. Но… см. выше про 95%
Причем не умозрительные рассуждения, а опыт трех лет практической работы с подобным «конструктором Лего» (конкретно — с Intershop Enfinity Suite). И я скажу так — это худшее, что со мной случалось за весь мой 25-летний стаж работы программистом.
Хорошего можно сказать только одно — это красиво выглядит. ВСЕ!
Дальше идут только одни проблемы:
— передача данных между блоками. Реализована в виде банального dictionary — то есть прощай типизация. Чтобы понять, что идет на выход из одного блока, и что идет на вход другого — изучай properties каждого блока. Отдельный привет, если данные не совпадают по формату — приходится лепить промежуточный блок для конвертации. А теперь мысленно представьте, какую площадь занимает Map<ID, List> -> List. То, что на чистой джаве укладывается в пять строчек, занимает пол-экрана.
— найти нужный блок. Медитируешь, пытаясь понять, какой из 20 блоков xxxPricexxx тебе нужен — а в итоге выясняется, что нужен какой-нибудь applyVAT
— громоздкость. Отлично, когда диаграмма простенькая, линейная и укладывается в в один экран. Но, с более-менее сложной логикой… это постоянный скроллинг в стороны, изменения масштаба и прочие удовольствия.
— ну, и least but not the last — code merge. Это просто аццкий сотона в кубе! Какие-то конфликты сложнее «добавить один блок посередине» можно решить, только очищая диаграмму, а потом ручками накатывая на нее блоки. Иначе либо отказ в автоматическом мерже (в лучшем случае), либо абсолютная каша из двух веток с совершенно рандомными переходами.
Можно было бы вспомнить еще — но и этого более чем достаточно, чтобы сделать вывод: идея красивая и наглядная, но в реальной разработке совершенно негодная.
Повторюсь еще раз — это не теоретические мысли, это опыт практического использования такой системы во вполне реальных проектах. Упаси Боже от таких «улучшений»!
Соответственно, любой договор/соглашение/ограничение этого права идет лесом.
Как бы иного не хотелось работодателю.
Серьезно?
То есть, уволившийся из ресторана повар должен 1-3-5 лет идти на стройку класть кирпичи, а не устроиться через дорогу в другой ресторан?
Вот заходите вы в магазин часов (ну, вот нужны они вам срочно). Бюджет — 100 баксов.
Вам с порога объявляют, что часы у них — от миллиона до двух. Экономия времени? Безусловно.
Точно так же вилка может помочь при устройстве на работу. Каким бы шикарным спецом не был кандидат, платить ему 10к зелени, когда есть ресурсы платить только тысячу, никто не сможет.
Ну и, банально, такой спец просто не отошлет резюме на заведомо неприемлемую вакансию.
Диаграммы просты и понятны, а JOIN, ИМХО, в 99% случаев идет по ключу. Не знаю, как у других, а у меня лично за 20 лет программирования ни разу не возникла необходимость использовать какие-то другие поля.
Это, примерно, как с математикой — в школе нас несколько лет учат, что квадратный корень из отрицательного числа взять нельзя, а в институте внезапно появляется мнимая единица.
?
В уме его, конечно, не рассчитаешь, но с приложениями под любую платформу оно и не нужно.