Мне кажется что "двойка" не является чем-то эмоционально плохим. Тоесть от контекста зависит. Например : тройка как оценка - плохо. А тройка лошадей - скорее всего хорошо. Тоесть заменяя слова на слова вряд-ли удастся корректно решить задачу не потеряв смысл текста.
Да. Я-же пишу про это. Возвращайте объект Optional. И сравнительный анализ перформанса должен быть следующим вопросом в qna. Примитивы против опциональных объектов. Или бросание исключений против возврата объектов из функций.
Мне кажется что VPN сервис может выполнять роль honey pot для мамкиных хакеров. Кто сказал что владелец VPN не сдаст вас с потрохами? Сдаст. Особенно если он на территории Евросоюза.
В Java все намного хуже. Мы либо можем возвращать из функции новый объект что само по себе тоже Performance Issue. Либо можно вернуть Double.NaN как признак того что вещественное число вышло кривое. Это технический долг который потянет за собой очень сложные и трудноуловимые эффекты в зависимом коде по стеку. И все кто юзают такую волшебную функцию в Java будут обязаны проверить на NaN (Not a Number) и принять решение.
Согласитесь в Scala все выглядит красиво и элегантно и главное типобезопасно.
Мирон, этот забавный технический артефакт, который вы описали тем не менее не является основанием к переписыванию приложения. Поскольку вы ссылаетесь на performance issue (PI), то данный issue надо бенчмаркать и делать justification.
Если у вас есть ссылка на github или другой источник который моделирует проблему - то буду признателен.
Тут еще есть другая проблема. Merge изменений. И с такими источниками как сайты - это нетривиальная задача. Убивать всю базу - дорого. Мержить корректно с сохранением ссылочной целостности - сложно. Простой пример - переименование какого-то продукта или торговой марки. Что делать с теми данными которые уже есть? Как детектировать что продукт был переименован а не создан новый?
Я вот думаю что сама идея парсить два разных сайта и потом сливать это в единую реляционную БД - обречена на неудачи. Тут очень много условностей. Может быть даже лучше все спраршеные данные сливать в какую-то NoSQL систему наподобие MongoDb или CouchDb в виде документов и уже организовать поиск по ней. Причем сливать всё что есть. Почему я ратую именно за такой подход. В современном мире BigData например в цепочке ETL уже стали отказываться от трансформации. Грубо говоря сливают все что есть в raw (Lake) и потом уже строят представления или материализуют то что есть. Если вспоследствии аналитик захочет новый атрибут который был спаршен - его можно будет достать и добавить в Mview. Но в случае с реляционным подходом такая затея обречена на неудачу. Мы ведь не парсили нужный атрибут. Кроме того если к двум сайтам еще добавить десяток - а в них совершенно другая схема и смыслы полей - другие.
Но ведь экспертный вопрос по реляции остался. Как относятся рестораны и сервисы? Один ресторан обслуживается одним сервисом? Или многие с многими? Города - тоже самое.
Вот ее нужно просто детализировать и описать как сервисы доставки (это тоже сущность) связаны с городами, ресторанами и продуктами. В лучших традициях проектирования баз данных. Тоесть отразить эту сущность на реляционной или концептуальной модели.
Можно конфиги просто хранить в git-репозитарии (приватный) и оттуда ставить на сервер. Таким образом задача бэкапа решается с другой стороны. Изменения конфигов тоже идут со стороны git.
Копирование базы на флешку - по другому конешно но есть у меня сомнения в полезности этого действия. Хороший хостинг и так обеспечивает бэкап баз.
Лексер и парсер как термины возникли еще в XXm веке. Это как основы теории трансляторов. И спокойно себе существовали. Vizitor и прочие шаблоны - это уже конец 20 го века и книга Четвёрки бандитов где собственно визитор и был описан.
Если вы не можете втащить Визитор в задачу трансляции то это даже хорошо. Это говорит о том что шаблон там просто не нужен как отдельная сущность. Одним из признаков хорошего проектирования кстати является доказательство ненужности того или иного шаблона. Это как исскуство Кун-фу. Ученик ищет повода подраться. А учитель или мастер - вообще ищет способа как-бы бой не состоялся.
