WEB-программист, сетевой администратор
Алгоритмы и структуры данных лежат в основе работы любого приложения или системы.
Компании, такие как Google, Amazon или Microsoft, в процессе собеседований проверяют именно эти знания, поскольку они являются универсальными и применимыми ко всем областям разработки.
Привет, Хабр!
В прошлой статье мы начали разговор о паттернах микросервисов (Часть 1). Ну что ж, давайте продолжим!
Паттерн «API-шлюз» (API Gateway)
Итак, следующим популярным шаблоном является паттерн API Gateway, который часто упоминается в контексте микросервисной архитектуры. Этот шаблон основывается на использовании шлюза, находящегося между клиентскими приложениями и микросервисами, предоставляя единую точку входа для всех клиентских запросов.
Редкая самоделка на тему «умного дома» обходится без термометров. В интернете есть масса инструкций по подключению, но при этом обычно ограничиваются «классическим», учебно‑демонстрационным вариантом, наверняка его все видели:
Берется какая‑нибудь ардуиноподобная плата, или что‑то из серии ESP, один из выводов GPIO настраивается в прошивке как линия 1-wire, а микросхема DS1820 подключается примерно так:
У меня, как и у многих посетителей Хабра есть raspberry pi. А ещё, почти честные сто мегабит от провайдера домашнего интернета. Идея о маленьком домашнем сервере от такой комбинации появляется сама по себе. Но сервер он ведь на то и сервер, чтобы работал независимо от факта нахождения пользователя в физической доступности. В связи с этим, возникает вопрос, как подключаться к такому серверу удалённо? Обычно провайдеры домашнего интернета прячут своих пользователей за NAT, так как IPv4 на всех не напасёшься. Мой провайдер исключением не является. Внешний статический IP он так же не предоставляет (по крайней мере, такой услуги в ЛК я не нашёл), да и совершенно ни к чему выставлять шлюз в локальную домашнюю сеть во внешний интернет. Shodan, ботнеты, сканеры и краулеры никто не отменял. Раньше для подобной задачи решение было очевидным – виртуальная частная сеть. Однако сейчас, с учётом нарушения сетевого коннекта по определённым протоколам, хочется иметь как минимум резервный удалённый канал связи. Да, нарушение коннекта по привычным для данной задачи протоколам неполное: можно отыскать протокол, который не забанен, можно поиграть с настройками, тем не менее хочется иметь возможность сделать это удалённо. Мой взгляд упал на нестандартные средства решения этой задачи.
Представьте ситуацию: вы нашли критический баг в проекте, исправили его в feature-ветке, но до полного слияния ещё далеко. Или вам срочно нужно перенести одно конкретное изменение из текущей ветки в другую. В таких случаях git cherry-pick становится вашим секретным оружием.
Эта статья продолжает серию материалов, посвящённых семинарам внутреннего обучения сотрудников NAUKA. В этой публикации разберем некоторые вопросы, связанные с тестированием разрабатываемых программных продуктов. Материал, представленный в статье, может быть полезен начинающим тестировщикам и аналитикам IT-компаний, а также студентам.
Привет! Это команда Яндекс Практикума. Делимся подборкой экспертов курса «Системный аналитик» — со статьями, курсами, книгами, видео и инструментами для аналитиков, разработчиков, тестировщиков и других специалистов, работающих с API.
Книга «React 19. Разработка веб‑приложений на JavaScript» — тот нечастый случай, когда пособие по самым последним средствам разработки выходит на русском языке параллельно с англоязычными изданиями. Обычно российские издательства берут в перевод лицензионную книгу и только через год она выходит на русском языке. Но не в этом случае. Книга Владимира Дронова — это новейшее руководство по React 19, начиная с базовых концепций и заканчивая продвинутыми инструментами, такими как Redux, Formik и анимации. Отдельное внимание уделено практическому применению библиотеки, включая разработку полноценного веб-приложения с использованием Firebase.
Существует достаточно много решений для локального и удаленного чтения и сбора логов с различных систем, но некоторые из них могут быть сложны в своей конфигурации и достаточно тяжеловесные для мониторинга одного или двух микросервисов, особенно, если не стоит вопрос удаленного хранения логов. У меня есть небольшой проект, который в процессе своей работы пишет логи, по этому на примере него расскажу, какие решения для их чтения использовал, и к чему в итоге пришел.
В мире разработки программного обеспечения существует множество "священных коров" — принципов и практик, которые принимаются как данность и редко подвергаются критическому анализу. Особенно показательна ситуация с принципами SOLID на русскоязычных ресурсах: достаточно открыть Хабр, чтобы найти 100500 статей о SOLID, и в каждой из них принципы интерпретируются по-разному.
Само существование такого количества "объяснительных" статей говорит о фундаментальной проблеме: если принципы требуют толкования, значит их названия не являются самодостаточными и интуитивно понятными. А если каждый разработчик понимает принципы по-своему, возникает вопрос — зачем вообще нужны принципы, которые не дают однозначного руководства к действию? Принципы SOLID, предложенные Робертом Мартином, давно стали одной из таких "священных коров". Однако пришло время честно признать: то, как мы используем SOLID сегодня, часто противоречит изначальным идеям и в целом иногда может приносить больше вреда, чем пользы. Зависит от контекста.
Самый яркий пример искажения первоначального замысла — это интерпретация принципа единственной ответственности (SRP).
Сегодня я рад представить новый масштабный проект, в рамках которого мы подробно рассмотрим технологии и подходы, ранее не освещенные в моих статьях.
На этот раз мы создадим телеграм-бота с MiniApp (ранее известным как WebApp) — это будет бот с интегрированным мини-сайтом прямо в Telegram. Для реализации проекта мы используем два основных фреймворка:
1. FastAPI — мощный Python-фреймворк, который мы задействуем для разработки API нашего телеграм-бота. Мы рассмотрим уникальный подход, позволяющий создать полноценный бэкенд, который будет закрывать как API-методы, так и функционал телеграм-бота.
2. Vue.js 3 — JavaScript-фреймворк, выбранный за его удобство разработки и возможности создания сложных визуальных элементов.
В этой статье мы сосредоточимся на описании бэкенда, а создание приложения на Vue.js 3 будет вынесено на следующую статью.
Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем.
Продолжение статьи об архитектурных паттернах для масштабируемости приложений.
Приветствую, коллеги! Меня зовут @ProstoKirReal. Мне бы хотелось с вами обсудить как работает интернет от кабелей на витой паре, соединяющие простые локальные сети до подводных коммуникационных кабелей соединяющие между собой континенты и основные операторские сети.
Поскольку в одной статье невозможно охватить всю тему целиком, я разделю подготовленный материал на несколько частей. Сегодня мы начнем с базовых понятий.
Какое-то время подходы к версионированию варьировались от компании к компании, до тех пор, пока соучредитель GitHub Том Престон-Вернер не предложил единый подход к выпуску и нумерации версий проектов. Этот подход называется Семантическим Версионированием и подробно описан в этом документе. В этом тексте я бы хотел проиллюстрировать основные положения документа и разобраться, что нам может рассказать версия проекта.
Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем. Она поможет понять:
Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.
Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.
Как избежать излишней сложности, которая может быть вызвана преждевременным внедрением сложных архитектур.
Цель статьи — помочь вам найти баланс между производительностью, масштабируемостью и сложностью системы. Вместо того чтобы сразу применять микросервисы, мы предлагаем сначала рассмотреть более легкие инструменты, делая выбор осознанно и обоснованно.
Развитие методологий CI и CD не стоит на месте. Тем не менее, проверенные практики, вероятно, останутся актуальными и в 2025 году. В этой статье покажем некоторые из таких в действии.
Так исторически сложилось, что язык программирования PHP порой недолюбливают. Я не встречал еще ни одного Java программиста который бы не смотрел на PHP свысока или хотя бы не ронял фразы типа: «К сожалению, практически вся e‑commerce написана на PHP». Наверное это происходит из‑за того, что мы видим «плохой» код на PHP, иногда вынуждены поддерживать этот код и переносим негатив на сам язык. Но тем не менее, нельзя отрицать, что PHP популярен — по данным на 2024 год, PHP используется на более чем 75% всех веб‑сайтов, где язык программирования известен.
Надеюсь, эта статья может быть полезна не только тем, кто не работает с PHP постоянно, а вынужден лишь иногда что‑то время от времени фиксить, то и тем для кого PHP является «родным» языком. Я собрал некоторые антипаттерны или плохие практики из‑за которых плохой код и появляется. Возможно вы узнаете здесь свои приемы и подходы и пересмотрите их.
Хабр, привет!
Сегодня говорим о Debian. Debian не нуждается в представлении – это один из самых популярных и востребованных дистрибутивов Linux. Несмотря на широкую доступность в интернете, крупные предприятия сталкиваются с проблемой использования дистрибутива в изолированных контурах обслуживания, что требует поднятия зеркала репозиториев внутри.
Однако в случае с Debian поднятие полного зеркала может осложняться объемом репозиториев — там по‑настоящему много пакетов, включая и те, что обычно не нужны на серверах, например игры. Помимо этого, официальной поддержки Debian не существует, а работать как-то нужно. Поэтому в этой статье мы расскажем о способе создания готовых архивов для зеркал с урезанными подборками пакетов, нужных для установки и/или обновления одного или более серверов с известным набором ПО.
