Ты не написал тип протокола. В первом варианте что https?
И кроме того веб-сервер также воспринимает имя хоста как часть URL. На этом основан виртуальный хостинг (это когда на 1 IP ты можешь держать много веб-доменов).
Vitsliputsli, эволюция, брат. Современные языки - строгая типизация. Rust, Golang, Nim.
Язык Си можно просто рассмотреть отдельно. Он создавался как портабельный ассемблер и многие вещи которые нам кажутся трюками там остались по историческим причинам. И никто их убирать не будет. Есть сферы разработки где Си просто безальтернативен (микроконтроллеры) но я в данном случае говорю не них, а про разработку бизнес-логики. Тоесть тот сегмент где мы с вами (читатели и писатели в qna.habr) сидим.
chopix, как будет угодно. Но есть старые добрый программерские принципы. Такие как KISS и YAGNI.
Их никто не отменял. И если ты можешь решить задачу не затаскивая в стек лишние фреймворки - то это значит что ты отлично решил задачу.
Я-бы приветствовал строгость как естественный процесс приведения беспорядочного исходного
кода к более порядочному. Это знаетели... как переход с языка C на С++.
chopix, дружище. Ты вообще понимаешь как проектируется ORM? Ты описываешь entities. Описываешь сервисы (репозитарии). И методы. И работаешь через методы. Это и есть лучшие практики работы с ORM.
Если ты решил взять готовую базу и затащить все что можно в ORM то тогда тебе ORM не нужен. Бери SQL. Он универсальнее в данном случае.
Ну вот там Photo это табличка. А PhotoService.findAll - это метод которым можно читать таблицу. Бери как-то по аналогии. Я не знаю и читай как вообще работают с ORM.
Kroyzen, мы с чем боремся? С новым софтом. Или просто разработчик выдал новую версию? Если так - то image: менялся и попробуй верни старую версию. Если заработает - тогда пиши письма разработчику. Дескыть софт падает.
Тут два момента. Первое. Исходники должны лежать в репозитарии кода проекта. Git, Gitlab неважно. Это моя консервативная точка зрения старого разработчика. Когда они в репах - то их можно централизованно фиксить и распространять патчи. Особенно это удобно когда у тебя тыща серверов и десять енвайронментов.
Второе. Будут-ли они лежать в sql-файлах или в XML/Liquibase/Flyway или C#/Java сорцах - это особо не важно. Важно чтобы был минимальный объём дейтвий для внесения изменений. В идеале - ты в пятницу вечером заменил 'a' на 'b' сделал commit/push тег деплой и открыв банку пива пошел домой.
И всё. Никакие другие действия не нужны. Никтому ни звонить. Никаких админов не уговаривать. Вот как-то так.
JRBRO, ты от всего не подстрахуешся. Поэтому начитай с этого и пиши новые вопросы по ходу. Придумывать всякие угрозы для тебя и опасные места - это знаешь-ли неблагодарное дело. Короче получи свой опыт.
Володимир Паламар, насчет Kafka я точно не скажу. Но если нет балансировок и перезагрузок - тогда пропускная способность кафки почти бесконечна. Вот сколько машин в кластер загонишь на столько и умножать можно. Ну это грубая формула. Там на самом деле есть еще репликация.
А RabbitMQ - это я просто для общности сказал чтоб было с чем сравнивать. Можно даже взять Apache ActiveMQ. Это все из бесплантного. А по поводу недостатков. Эти все штуки хорошо работают в топологии точка-точка. Но если у тебя модель топиков-подписок то эти архитектуры ведут себя гораздо хуже чем кафка. Собственно ... Кафка это даже не MQ система. Это скорее распределенное хранилище логов сообщений. Вот поэтому ее и часто советуют в оппозицию к стандартным системам.
Володимир Паламар, сколько клиентов одновременно присутствуют? Согласно архитектуре Kafka каждый клиент - это consumer и его нужно настроить на топик или есть еще опция топик + партишен или ключ.
Успех архитектуры kafka будет зависеть от того сможете ли вы разложить producers/consumers/partitions оптимальным образом иначе у вас все будут вычитывать всё.
При скорости в 500 машин по 0.05 сообщений в сек получаем средний канал 25 сообщений в сек. При такой нагрузке Kafka не нужна. Можете брать RabbitMQ.
и на последней итерации когда diff уже будет готов просто выведи на экран keys + values.