mayton2019

1) Отправляю https запрос (GET) сайту
2) Это сообщение сначала с помощью волн ( 2,4 ГГц ) передаётся моему роутеру. С помощью сетевой карты? Или сокета? Или с помощью чего передаются данные? | Это, насколько я понимаю, у нас канальный уровень (в OSI это и физический и канальный)

Ты молодец, что ты решил так детально изучать физику процессов. Но по моему слишком глубоко копнул. WIFI тоже имеет свои протоколы связи и ты еще с пол-года на них застрянешь. Вообще науки лучше изучать в "ширину" а не в глубину. Остановись на каком-то уровне.

А то дойдешь до физики суб-атомного уровня а там еще конь не валялся...

Функция chr() умеет преобразовывать код символа в символ. Знаете ASCII код буквы 'A' ? Дальше - дело техники.

Возможно у UI есть ограничения. Посмотри вот другая утилита есть https://www.mongodb.com/docs/database-tools/mongoi...

Я не помню синтаксис MSSQL но может быть как-то так

delete 
  dbo.Корреспонденция 
from 
  dbo.Корреспонденция INNER JOIN dbo.Отправители ON dbo.Корреспонденция.код_отправителя = Отправители.код_отправителя
where 
  контактный_телефон like '8%' and 
  substring(контактный_телефон,2,1) = substring(контактный_телефон,4,1);

UPD: подожди лайкать. Единичку забыл в функции.

Я в таких случаях просто подмигиваю продавцу.... дескыть. Договоримся. И он позволяет поставить на ноут что угодно в магазине или в сервисном центре и мы далее вместе смотрим как Linux стартует. Расчитываемся и продавец на кармашек получает свои несколько долларов.

Автор, намешано конечно у тебя в списке.. ой-ой. Но если интересуешся веб-протоколами - посмотри
еще на GraphQL https://graphql.org/ я думаю он очень интересен для современного разработчика.

Еще посмотри на QUIC для общего развития https://cloud.google.com/blog/products/gcp/introdu... там интересно.

REST - это вобщем-то не протокол а скорее философия или архитектурный подход к работе с http. У него - очень размытые границы в реализациях. И иногда сложно взять приложение и классифицировать что оно такое. Рест или не-рест. Рест использует коды ошибок из HTTP и поэтому существует только в слое http.
В теле REST сообщения может быть что угодно. XML, JSON или просто текст. Неспецифицировано короче. Наивные попытки внести в рест спецификации появились сравнительно недавно. Рест хорошо интегрируется с балансерами и реверс-прокси (nginx).

SOAP - это именно "протокол". Базируется на XML с жесткой схемой. Причем работающий почти на всех слоях сетей. Может на не только по HTTP но и по сырым сокетам бегать. Хотя в настоящее время - непопулярен. Типизирован. Имеет специальный файл спецификации (WSDL) который точно описывает все сигнатуры методов. Требует большой аккуратности в реализациях. И обычно никто не пишет SOAP клиент-сервер вручную а пользуются генераторами API. Часто используется в банках и крайне консервативных ведомствах.

Если это единый проект - то ему нужен один репозиатрий.

SOLID может на каком-то этапе противоречить например KISS. Например вы, как старший разработчик можете видеть "вперед" и прогнозировать потребность бизнеса в расширении какого-то функционала. И будете закладывать Open/Closed и прочие философии. А разработчик уровня Junior который неделю назад пришел на проект - этого не знает и будет писать "как чукча". Тоесть буквально то что надо сделать - тои напишет. И между вами может возникнуть спор как раз на тему SOLID против KISS. Но вы можете ошибаться в своём прогнозе потребности бизнеса. Или бизнес может передумать. В этом случае правда оказалась на стороне святой простоты (Santa simplicitas).

Как вы понимаете такие антагонизмы не могут быть удовлетворены аж никогда. Поэтому вы никогда не найдете проекты которые удовлетворяют ВСЕМ философиям которые перечислены в списке одновременно.

Буквально недавно было обсуждение здесь https://qna.habr.com/q/1241266

Если кратко - то под каждую платформу - надо писать какой-то #ifdef ....#endif. Тоесть ваш код
будет в объеме умножаться на число платформ которые надо поддержкать. Сколько их щас?

В чистом виде язык "C" не имеет какого-то стандарта на отображение графики.

Почти все современные среды разработки в дереве проекта (Project=>External libraries) показывают зависимости.
Но успех мероприятия сильно зависит от того как проект создавался. Для maven-сборщика
это точно работает. Для других - надо смотреть.

Давайте представим объект и DTO которым пользуется объект. Если объект возаращает DTO как представление самого себя, например методом showStruct(): DTO будет ли это являться нарушением инкапсуляции?

Я понял ваш вопрос. Смотрите. Философия ООП базируется на том что все действия с объектом должны быть санционированы языком или средой выполнения. Например в Java есть техника рефлексии которая позволяет много чего делать например менять приватные поля. Это часто используется в Mock/Mockito и я часто про это говорю. Мокито - фактически взламывает инкапсуляцию. Но это всех устраивает потому-что "тестить нуна!".
В Java также есть технология сериализации-десериализации которая обеспечивает сохранения состояния объектов на диск или передачу их в сеть для дальнейшей работы (например пользовательская сессия прыгает между нодами кластера). И это действие (сериализация) полностью санкционировано средой и языком. Всех это устраивает. Хотя с моей точки зрения - этож капец взлом. Но зато в Java вы никогда не сделаете down-casting объекта одного типа к типу другого если иерархия этого не позволяет. Этого делать нельзя ... ну потому что это точняк нарушение ООП. И нельзя найти никакой санкции на такое странное действие. Вот в языке С++ например вы можете жонглируя указателями взглянуть в любую память своего процесса или потока и прочитать любой байт или word/dword. Что можно сделать в PHP из подобного? Я не знаю. Но новерное что в PHP много механик которые не позволяют делать хакинг когда. Вот. Поэтому ООП и считается философией программирования а вовсе не тюрьмой. Вобщем код надо писать по правилам языка и среды а не "хачить". И лучшие практики ООП они как раз стоят именно на этой идее. Кроме того - не существует единого ООП - а есть просто разные его реализации в разных языках. Короче вы не найдете самого-самого-ООП-шного языка.

А вообще если это опнсорц - ну сделайте себе форк и меняйте что хотите в исходниках.

И Еще пример. если объект не будет возвращать никаких данных о себе, то тогда как придерживаться принципа OpenClosed?

Про что вообще OpenClosed? Это - расширенная трактовка ООП в части SOLID (вторая буква О).
Означает что если вы хотите внести изменение в класс - то вы его наследуете. Например
class BMWX5 extends BMW { .. }
Мы ничего не нарушили. Мы не меняли свойств BMW. Мы создали новый класс BMWX5 где есть изменные методы. Оригинальный BMW мы не трогали. Все - в правовом поле.

Обычно DAO не сериализируют. Вот Contact - можно.
И DAO так не делают. Обычно DAO предоставляет доступ к источникам данных. К базе например.
Но он не обязан ничего внутри себя хранить.

А моя программа выдает при n = 5 m = 4 путь: 15432

Код работает как написано. Только ты зря завел переменную current. Без нее можно обойтись.
Получается что ты шагаешь не через единичку а идешь длинными прыжками по модулю 5.
И тебе кажется что идешь назад.

for (int i = 0; i < n; i++) {
            System.out.print(arr[current]);
            current = (current + m) % n;
        }

Я-бы переписал проще.

for (int i = 0; i < n; i++) {
            System.out.print(arr[(i+ m) % n]);
        }

Если они связаны 1:1 то соедини их в одну табличку и все.

UPD: Автор если ты сомневаешся - то лучше не делай. На все технические вопросы тут ответят.
Но риски - это дело твоё. Похлопывать тебя по плечу или давать санкции на авантюры - никто не будет.
Если ты отвественный за БД и уверен в себе - то иди и делай.

В аналоговой технике 20-го века (усилителях и эквалайзерах) это могло называться тон-компенсация (Equal-loudness contour) https://en.wikipedia.org/wiki/Equal-loudness_contour

У меня - сходу замечание по твоему стилю. Зачем ты переменную card переписываешь? Это сбивает с толку.

List<Card> cards = .....

cards = entityManager

Нельзя одну переменную брать в двух ипостасях. Сэкономил в одном - проиграл в читаемости.

Второе я думаю что эта задача прекрасно решается одним SQL-запросом. Так было в продуктовых системах с 2000х годов когда еще не было этих ваших ORM/Hibernate. И все нормально работало. Поэтому делай все одним запросом. Не думай о накладных расходах в базе. Мой опыт показывает что база - лучше справляется когда выбирает все данные сразу одним курсором (запросом).

А игры с Lazy-Eager которые придумали в ORM решают проблемый самого ORM и ApplicationServer а базе они вобщем-то не нужны.

Если ты собрался глубоко заняться оптимизацией - посмотри лекцию Алименкова особенно в части трассировки Hibernate запросов. Собери цифры. Сколько карточек на 1 акк в среднем? 1 или 10 или 1000? Сколько транзакций на акк? Это все влияет на смыслы оптимизаций.