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

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

Основное внимание в статье будет уделено автоматизации процесса создания документации API сервисов, которые разрабатываются с помощью фреймворков Express.js и Gin, используя подходящий для этой задачи инструмент - Swagger.

В алгоритмических задачах на графах мы часто используем четыре известных алгоритма: Поиск в ширину или глубину, алгоритмы Дейкстры и А*. Разбираемся, почему на деле это один и тот же алгоритм.

По резюме встречают, по скиллам провожают.

Данная статья результат поиска некоего каноничного решения организации безопасности доступа к ресурсам в микросервисной архитектуре, построенной в экосистеме Spring. После прочтения десятка статей по данной тематике, к сожалению, не нашел то, что искал. Spring Security оказался одной из самых недопонятых технологий. Основная проблема у всех - изобретение своего велосипеда поверх стандартного функционала Spring Security. Зачастую, данные статьи сопровождаются комментариями никогда так не делать. И у многих, наверно, возникает вопрос, а как собственно можно делать. Ситуацию несколько прояснила официальная документация. Взяв её за основу, я хочу показать, как можно организовать безопасность микросервисов максимально простым и быстрым способом.

“Чтобы что” - это что? Как научить аналитика-проектировщика, что является обоснованием функциональных требований, а что нет? Когда заказчик отвечает на вопрос “чтобы что”, как понять, является ли это ответом? Я не нашел книг, где это было бы описано понятно, сжато и лаконично. Чаще всего описаны абстрактные рассуждения, в применении которых на практике возникают проблемы. В статье на примерах разбирается как находить причину требований, какие они бывают, а что не является причиной вовсе.

Это — очередная (уже третья) ревизия главы 11 мой книги о разработке API. Если вы найдёте этот текст полезным, я буду очень благодарен за рейтинг на Амазоне.

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

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

Прим. перев.: автор этой статьи — технический архитектор Sudhir Jonathan — рассказывает об одном из тех базовых механизмов, с которым сталкивается каждый пользователь, разработчик и системный администратор. Однако до возникновения определённых (и иногда довольно специфичных) проблем многие не задумываются о том, как всё работает «под капотом». Автор устраняет этот пробел, используя популярные фреймворки, серверы БД и приложений в качестве понятных примеров.

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

Основы масштабирования

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

Проблема неполной индукции

Знаменитый древнегреческий философ Аристотель в своем трактате «Аналитика» выделяет два вида возможных умозаключений - индуктивное и дедуктивное.

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

Классическим примером дедукции, которую сам Аристотель называл силлогизм, является следующее рассуждение: все люди смертны (общее правило), Сократ - человек (частный случай), следовательно Сократ смертен (дедуктивный вывод).

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

Когда-то я проходил серию собеседований на Backend-Java-разработчика и записывал вопросы себе на будущее, чтобы потом можно было пробежаться и освежить память. Подумалось, что, вероятно, данный сборник будет полезен не только мне, поэтому сдул с него пыль, набросал ответов и делюсь с сообществом. На оригинальность и исключительность не претендую: подобные статьи уже были и на Хабре, и много где ещё — в конце (во второй части) приведу список ссылок, чтобы шпаргалка была максимально полной.

Точно установить сложность всех вопросов не берусь — на разном уровне их потребуется раскрыть с различной степенью подробности. Я написал ответы где-то на плюс-минус middle, щедро приправив ссылками для дальнейших изысканий. На самые популярные вопросы сразу перенаправляю в источники с готовыми ответами. Заодно посмотрим по ссылкам в статье, насколько Хабр может помочь в подготовке к собесам.

Текста получилось много, поэтому пришлось разбить на две части. В первой поговорим про Java и Spring, а обо всём остальном — во второй. Вторая часть тут

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

Disclaimer
Статья написана для новичков и тех, кому хочется шаг за шагом понять как устроена работа с электронной почтой из Java-приложений. Желающие быстро понять как отправлять электронные письма из Spring-приложений могут сразу переходить к 3 части.

Эту статью я решил написать, потому что не нашел русскоязычных источников про работу c электронной почтой из Java, описывающих имеющиеся библиотеки достаточно полно. На хабре существует статья, посвященная очень узкой задаче по чтению писем (и выводу их содержимого в консоль) и статья с how-to по отправлению
письма с вложениями при помощи Spring Email. Также существует несколько статей (например) на тематических ресурсах, которые приводят порядок действий при работе
с электронной почтой. В этих источниках мне не хватало объяснения основ, на которых стоит
электронная почта и взгляда с высоты на существующие библиотеки для работы с почтой в Java.

Для таких же лапкообразных, как я, написана эта статья. Она дает общие представления о работе электронной почты, разъясняет основные сущности библиотеки Jakarta Mail и дает советы о том, как работать с электронной почтой в Spring-приложениях.