Привет! Меня зовут Данил, я backend-разработчик в Doubletapp. Почти во всех наших проектах есть пользователи, которые могут войти в систему. А значит, нам почти всегда нужна авторизация. Мы используем авторизацию, построенную на JSON Web Token. Она отлично сочетает в себе простоту реализации и безопасность для приложений.

В интернете есть много разных материалов с объяснением, что такое JWT и как им пользоваться. Но большинство примеров ограничиваются выдачей токена для пользователя. В этой статье я хочу рассказать не только о том, что такое JWT, но и как можно реализовать работу с access и refresh токенами и решить сопутствующие проблемы. Будет немного теории и много практики. Присаживайтесь поудобнее, мы начинаем.

Путеводитель:

• Что такое JSON Web Token?
• Использование и реализация
• Простая реализация JWT
• Access и refresh tokens
• Как отозвать токены
• Доступ с нескольких устройств
• Удаление старых данных
• Резюмируем

Как создатель и руководитель курсов по C# я вижу, что часто у людей, начинающих изучать этот язык, принципы Объектно-Ориентированного Программирования вызывают затруднения в понимании. А так как один из лучших способов что-то понять, это посмотреть применение на примерах, то я решил написать статью с примерами принципов. Рекомендую найти какую-нибудь статью или книгу, где прочитать основную теорию, а в этой статье уже посмотреть примеры применения этой теории, чтобы понять её лучше.

На текущий момент есть различные точки зрения на то, сколько же в ООП всё-таки принципов и в этой статье мы будем считать, что этих принципов четыре: Инкапсуляция, Наследование, Полиморфизм и Абстракция. Примеры будут приведены на языке C#, однако, они очень простые, да и сама суть не зависит от языка, поэтому будет полезна всем начинающим изучать ООП программистам.

Обмен веществ — это та сила внутри организма, которая загадочным образом решает, превратить ли съеденную пищу в прилив энергии или в лишние килограммы на весах.

Медленный или «вялый» обмен веществ — это первое, что мы виним в своих попытках похудеть. В результате индустрия объёмом в $33 млрд (и это только в США) предлагает тысячи продуктов, обещающих ускорить метаболизм для успешного похудения. Но вместо того, чтобы покупать добавки, можно сделать кое-что другое, чтобы ускорить метаболизм.

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

Всем привет! Меня зовут Виктор Василенко, я техлид и Solution-архитектор. Я работал в Яндексе и X5 Group и уже не первый год сотрудничаю с Практикумом. Я делюсь опытом на курсах «Алгоритмы и структуры данных» и «Асинхронное программирование на Python».

Архитектор ПО — это специалист, ответственный за проектирование структуры и организацию системы или продукта. Роль архитектора в IT-компании включает в себя не только технические задачи, но часто и коммуникационные и организационные обязанности. Также архитектор является промежуточным звеном между бизнес-процессами и технологическими решениями.

Пока что индустрия не может чётко определить эту деятельность как профессию. В общероссийском классификаторе профессий ОКПДТР архитектор встречается скорее ландшафтный, чем программного обеспечения. В вузах вы не сможете найти специальность «Архитектура программного обеспечения». 

Границы профессии достаточно размытые, и часто это не профессия и должность, а скорее роль. Задачи разнятся: архитектор должен уметь писать код и документировать его для коллег, в то же время он может коммуницировать с бизнесом и заказчиками, выстраивать стратегию развития компании на годы вперед. 

В этой статье я хочу поделиться своим видением роли архитектора ПО и рассказать:

Кто такой архитектор ПО и какие они бывают;

Чем занимается архитектор решений в компаниях разного масштаба;

Чем отличаются инженеры от архитекторов ПО;

Какие обычно задачи стоят перед архитектором ПО;

Конкретно: какие нужны навыки и компетенции;

Как перейти из инженера на позицию архитектора.

Данный проект рассматривается как pet-project. Любую критику и советы готов увидеть в комментариях.

Это моя фактически первая статья на хабре за долгое время, последняя была написана очень много лет назад, если что-то не так - напишите в личные сообщения - я все исправлю.

Репозиторий с исходным кодом: https://github.com/theartofdevel/notes_system

Видео версия: https://www.youtube.com/watch?v=Txi95RQPRP0

Под катом текстовая расшифровка.

Привет! На связи Олег Казаков из Spectr.  Мы занимаемся разработкой цифровых сервисов, в том числе высоконагруженных систем с микросервисной архитектурой и большим количеством различных интеграций.

В статье расскажу об одном из кейсов при работе над проектом с микросервисной архитектурой — реализации единой системы авторизации и аутентификации.  Поговорим про теорию, рассмотрим различные стратегии реализации и особое внимание уделим паттерну API Gateway.

Скажу сразу: я никогда не жду развёрнутого ответа на этот вопрос на собесах. Это глупо и в моем случае — эгоистично. Однако, на мой взгляд, помимо общего интереса к платформе, знать, как он работает очень полезно, т.к. это снимает целый ряд вопросов. Например, исключает вариант, когда разработчик считает, что Dispose вызывается автоматически и вызывать его самому не надо. Или же если разработчик более опытен, помогает ему автоматически, на уровне мышечной памяти писать код, приводящий к наименьшему количеству проблем.

Другой вопрос, что мне субъективно не очень нравится, как объясняется его работа. Потому, предлагаю альтернативный подход, описанный в моей книге, .NET Platform Architecture.

Если мы с вами будем досконально разбираться, почему были выбраны именно эти два алгоритма управления памятью: Sweep и Compact, нам для этого придётся рассматривать десятки алгоритмов управления памятью, которые существуют в мире: начиная обычными словарями, заканчивая очень сложными lock-free структурами. Вместо этого, оставив голову мыслям о полезном, мы просто обоснуем выбор и тем самым поймём, почему выбор был сделан именно таким. Мы более не смотрим в рекламный буклет ракеты-носителя: у нас на руках полный набор документации.

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

Данная статья является продолжением статьи - Ивентная модель данных с использованием Kafka и Kafka Connect: Построение гибкой и распределенной архитектуры.

Добро пожаловать во вторую часть статьи о построении гибкой и распределенной архитектуры с использованием Apache Kafka и Kafka Connect! В первой части мы ознакомились с ивентной моделью данных, разработали сервис отправителя и настроили интеграцию с Kafka, чтобы асинхронно отправлять сообщения. Теперь настало время рассмотреть вторую часть этого увлекательного проекта.

Привет, Хабр! В наше время при постоянном росте объемов данных и необходимостью более быстрой и надежной обработки информации, мы сталкиваемся с требованием к эффективному обмену и синхронизации данных между различными системами. Отслеживание и обработка данных в реальном времени стало жизненно необходимым для современных приложений.

В этой статье мы рассмотрим, как Kafka Connect – мощный инструмент из экосистемы Apache Kafka – приходит на помощь при решении сложной задачи синхронизации данных между базами данных. Мы рассмотрим, как используя Kafka Connect, мы можем эффективно следить за изменениями в одной базе данных, обрабатывать их в нашем Java приложении и мгновенно записывать их в другую базу данных, обеспечивая надежность и безопасность данных.

Построим гибкую и масштабируемую архитектуру, которая позволит нам забыть о проблемах связанных с несогласованными данными и наслаждаться мгновенным доступом к актуальной информации для наших бизнес-процессов.

(а если «ДА», то как это можно реально осуществить)

Американский физик, лауреат Нобелевской премии Ричард Фейнман: «Если бы человек вздумал соорудить вечный двигатель, он столкнулся бы с запретом в виде физического закона. В отличие от этой ситуации в биологии нет закона, который утверждал бы обязательную конечность жизни каждого индивида».

В этой статье, в первой её части, я попытаюсь теоретически обосновать возможность бессмертия человека. А во второй части попробую предложить метод, как это можно сделать практически при успешной реализации четырёх исследовательских проектов, два из которых находятся на стадии завершения.

В первой статье мы узнали, зачем нужен GraphQL и в чем различия между GraphQL и REST. Начиная с этой статьи, мы углубимся в детали практического использования GraphQL.

Почему масштабировать вообще сложно?

В сети много текстов, так или иначе касающихся масштабируемости кода, но авторы очень часто упускают одну главную вещь: почему масштабировать — это сложно.

Основная причина тут в том, что как только вы начинаете изменять какую-то большую систему, она начинает разваливаться. Ну, за исключением тех случаев, когда у вас вообще всё на 100% покрыто тестами. Однако, в реальном мире история с покрытием тестами такова, что код современных приложений покрыт (в лучшем случае) примерно на 1%.

Может быть, 100% покрытие тестами — это реальность не только для библиотек, утилит или компиляторов (ведь мы можем формализовать их поведение математически), но и для веб-приложения? Да не, фигня какая-то...

В один прекрасный день, стреляя по NPC в космосе, мне стало интересно, а смогу ли я этот рутинный процесс немного автоматизировать.

Выводить в консоль «Привет, мир!» я уже умел.
Теоретическое представление, что нужно делать, так же имелось.
Оставалось дело за малым - реализовать задумку.

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

Обзор одного из способов передачи информации между управляемым и неуправляемым кодом – почти забытого маршалинга.

­­ 

На первый взгляд, Clean Architecture – довольно простой набор рекомендаций к построению приложений. Но и я, и многие мои коллеги, сильные разработчики, осознали эту архитектуру не сразу. А в последнее время в чатах и интернете я вижу всё больше ошибочных представлений, связанных с ней. Этой статьёй я хочу помочь сообществу лучше понять Clean Architecture и избавиться от распространенных заблуждений.

Введение

На одном из моих поддерживаемых проектов недавно встала задача проанализировать возможность миграции с .NET фреймворка 4.5 на .Net Core по случаю необходимости рефакторинга и разгребания большого количества накопившегося технического долга. Выбор пал на целевую платформу .NET Core 3.0, так как, судя по утверждению разработчиков от Microsoft, с появлением релиза версии 3.0, необходимые шаги при миграции legacy кода уменьшатся в несколько раз. Особенно нас в нем привлекли планы выхода EntityFramework 6.3 для .Net Core т.е. большую часть кода, основанную на EF 6.2, можно будет оставить «как есть» в мигрированном проекте на net core.

С уровнем данных, вроде, стало понятно, однако, еще одной большой частью по переносу кода остался уровень безопасности, который, к сожалению, после беглых выводов аудита придется почти полностью выкинуть и переписать с нуля. Благо, на проекте уже использовалась часть ASP NET Identity, в виде хранения пользователей и других приделанных сбоку «велосипедов».

Тут возникает логичный вопрос: если в security часть придется вносить много изменений, почему бы сразу же не внедрить подходы, рекомендуемые в виде промышленных стандартов, а именно: подвести приложение под использование Open Id connect и OAuth посредством фреймворка IdentityServer4.