Когда моя сестра переехала в другой город и познакомилась с соседями, оказалось, что дедушка и бабушка ее соседа и наши бабушка с дедушкой были хорошими друзьями и общались, живя рядом в другом городе – два поколения назад. Интересно, когда обнаруживаются такие неожиданные связи. Согласно теории сетей, пути, соединяющие узлы сети, зачастую короче, чем могло бы показаться.

Если каждый в сети знает k других людей, то можно упрощенно предположить, что, начав от этого человека и совершив n переходов от узла к узлу, мы найдем kⁿ человек. Учитывая экспоненциальный рост, потребуется совсем немного времени, чтобы построить путь от любого конкретного человека до любого другого в графе.

Но в реальных социальных сетях многие люди, знакомые конкретному человеку, также знают друг друга. Такое пересечение между друзьями друзей снижает количество новых людей, к которым я могу обратиться после каждого перехода на пути от стартового узла.  Может быть непросто найти такие пути, которые начинаются в сплоченном сообществе, а далее разветвляются до самых отдаленных уголков сети.

В главе 20 книги Networks Crowds and Markets ее авторы Дэвид Изли и Джон Клейнберг дают теоретический аппарат, описывающий, как в реальном мире могут возникать феномены, укладывающиеся в граф «мир тесен». В этой теории сочетается идея гомофилии, согласно которой схожие люди кучкуются вместе, и идея слабых связей, где отношения ветвятся в масштабах всей сети. Объяснение основано на работе Дункана Уоттса и Стива Строгаца. Давайте проследим эти примеры при помощи кода, написанного при помощи Neo4j.

Привет, Хаброжители! В книге «Идеальная работа. Программирование без прикрас» легендарный Роберт Мартин (Дядюшка Боб) создал исчерпывающее руководство по хорошей работе для каждого программиста. Роберт Мартин объединяет дисциплины, стандарты и вопросы этики, необходимые для быстрой и продуктивной разработки надежного, эффективного кода, позволяющего испытывать гордость за программное обеспечение, которое вы создаете каждый день.

Роберт Мартин, автор бестселлера «Чистый код», начинает с прагматического руководства по пяти основополагающим дисциплинам создания программного обеспечения: разработка через тестирование, рефакторинг, простой дизайн, совместное программирование и тесты. Затем он переходит к стандартам — обрисовывая ожидания «мира» от разработчиков программного обеспечения, рассказывая, как часто различаются эти подходы, и помогает вам устранить несоответствия. Наконец, он обращается к этике программиста, давая десять фундаментальных постулатов, которым должны следовать все разработчики программного обеспечения.

Учимся использовать и реализовывать на Python алгоритм поиска в ширину (BFS) для решения реальных задач.

Давайте поговорим о популярном алгоритме, который называется «Поиск в ширину» (BFS). Затем реализуем этот алгоритм, чтобы найти решение для реальной задачи: как выбраться из лабиринта.

Алгоритмы поиска применяются для решения таких задач, которые можно смоделировать как графы. Каждый узел графа – это экземпляр задачи. Каждый поисковый алгоритм начинается с узла (исходный экземпляр – состояние) и наращивает вслед за этим узлом новые (то есть, новые экземпляры задачи), решая задачу допустимыми способами. Этот процесс останавливается, как только алгоритм находит решение (успех – конечное состояние) или не может создать ни одного нового узла (провал). Среди самых популярных алгоритмов поиска – поиск в глубину (DFS), поиск в ширину (BFS), жадный алгоритм, поиск по критерию стоимости (UCS), A*-поиск, т.д. В этой статье речь пойдет о поиске в ширину.

Монолиты слишком раскритикованы

Сейчас, когда о какой-то компании говорят, что она продолжает развивать монолит, может показаться, что компания эта старомодная, а с масштабированием монолита у нее могут возникнуть проблемы, правда? Я решил написать о том, что некоторым людям (и мне в том числе) монолиты кажутся замечательными. Тем не менее, технология действительно ушла далеко вперед, и я думаю, что пора пересмотреть подход к созданию монолитов.

Управление доступными ресурсами в облачной среде по запросу – тема, которая бывает очень непростой. Но эта работа стоит того, поскольку вы сможете использовать ресурсы гораздо эффективнее. Поэтому многие компании и проекты решаются мигрировать на облачные платформы, в частности, на Azul, AWS, Google Cloud или другие. С точки зрения программиста, есть одна истина, которая сохраняется и в облаке: рекомендуется понимать поведение и ограничения того JVM-приложения, что вы развернули (или не приложений, а подов, минимальных развертываемых единиц в Kubernetes). Платформа Java является многопоточной, и, даже если вы не собираетесь использовать какие-либо доступные для этого API, платформа все равно порождает множество потоков-демонов, работающих в фоновом режиме. Такие потоки нужны не только для очистки и подхватывания неиспользуемой памяти. Они относятся к платформе, а что насчет фреймворков? Фреймворки Java пытаются обслуживать большие эксплуатационные мощности; следовательно, инициируется работа множества вспомогательных потоков. Ниже мы немного заглянем под капот. В этой статье будет подробнее рассмотрено, как устроены популярные фреймворки Quarkus и Spring-Boot, сколько потоков они инициируют, чтобы обслужить все результаты. Давайте вместе пробежимся по примерам и для начала разберемся, какова разница между мониторингом и профилированием.