mayton2019

Автор, намешано конечно у тебя в списке.. ой-ой. Но если интересуешся веб-протоколами - посмотри
еще на 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? Сколько транзакций на акк? Это все влияет на смыслы оптимизаций.

Брось прикалываться. Нормальные люди рисуют геометрию на matplot. Вот посмотри примеры
https://matplotlib.org/stable/gallery/lines_bars_a...

Если ты любитель ASCII-art - то рисуй прямоугольник из звездочек. Но исключай те звездочки которые
входят в тело треугольника который вписан. Принадледность точки треугольнику - это классическая задача на всяких codewars, контестерах.

Не специалист в Perl. Но использовать awk-like replacements для работы с бинарниками - так себе идея.

У тебя в примере такой кейс. Дан двоичный файл и надо заменить в нем байты
01 02 03на байты 04 05 06. Ето один кейс? Или возможны другие? 3 на 2 байта можно менять?
В этом случае размер файла изменится. И нужно-ли сделать один реплейсмент? Или найти все возможные?

Я думаю что тебе надо найти сишника, поставить ему пиво и он тебе 1 раз напишет утилиту для патчей и будешь ей всегда пользоваться.

Или попробуй разберись вот как тут пишут https://stackoverflow.com/questions/2464334/how-ca...

Сделай картинку поменьше.

Оба варианта хорошие. Но обычно если ты работаешь отладчиком и тебе
интересно где логика ведет себя не так - то второй вариант удобнее.

Однострочники хороши только когда ты досконально понимаешь
что внутри них происходит.

Напоминает попытку построить свой кеш. А зачем топик тегирован Ассемблером? Какая тут нерешаемая
для ассемблера задача?

Давайте поговорим о шрифтах. В 2012 я перешел с windows7 на Linux. И первая проблема практической работы с десктопом заключалась в том что я начал менять шрифты. Вот не нравились мне не шрифты не алгоритмы их рендеринга. Надо отдать должное МС. Шрифты у них хорошие. Дизайнеры очень долго думали над ними. Вот. Когда вы заняты кросс-платформенным UI возникает проблема. - Где взять шрифты максимально похожие на оригинал. Высота. Кернинг. Все должно быть максимально похожим на оригинальный десктоп где идет разработка иначе дизайн разваливается. В годы развития Linux Suse я пытался устанавливать их десктопы и использовать. И самая большая визуальная проблема что я видел - это полный развал шрифтового оформления. Доходило до смешного. Я просто не мог прочитать кириллический месседж в окне. Текст - сползал куда-то за границу окна. Или текст успешно переносился а баттон сползал за границы окна. Вобщем проблем было масса. Я думаю что одна из главных проблем кросс-платформенного UI - это унификация шрифтов. И дело тут вовсе не в Qt или Gnome/Gtk или KDE. А дело в том что другая платформа понятия не имеет как должен выглядет текстовый месседж.

Не знаю каким боком ERD связано с DataQuality. Но на одной лекции я слышал что для оценки качества данных используют "ящики с усами" (box-and-whisker) и по ним смотрят выбросы. Ящик строится для каждой колонки отдельно.

Реляционная диаграмма здесь скорее всего непричем. Статистика и маш-обучение оперирует обычно одной таблицей где есть всё.