И снова здравствуйте. Специально для студентов курса «Разработчик на Spring Framework» подготовили перевод интересной статьи.

---

В моей статье «Specifications to the Rescue» я показал как можно использовать JPA Specification в Spring Boot для реализации фильтрации в RESTful API. Затем в статье «Testing those Specifications» было показано как протестировать эти самые спецификации.

Следующим шагом я решил продемонстрировать, как добавить планировщик заданий в это же приложение Spring Boot.

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

Зачем всё это и для чего?

У нас было: 10 самых простых конфигураций серверов на DigitalOcean, мобильные устройства на базе iOS, сервер для сбора статистики, никакого опыта в настройке VPN-серверов, а также неукротимое желание сделать быстрый, надёжный и простой в использовании VPN-сервис, которым будет приятно пользоваться. Не то, чтобы всё это было категорически необходимо, но если уж начали, то к делу надо подходить серьёзно.

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

Docker — это платформа, которая предназначена для разработки, развёртывания и запуска приложений в контейнерах. Слово «Docker» в последнее время стало чем-то вроде синонима слова «контейнеризация». И если вы ещё не пользуетесь Docker, но при этом работаете или собираетесь работать в сферах разработки приложений или анализа данных, то Docker — это то, с чем вы непременно встретитесь в будущем.

→ Часть 1: основы
→ Часть 2: термины и концепции
→ Часть 3: файлы Dockerfile
→ Часть 4: уменьшение размеров образов и ускорение их сборки
→ Часть 5: команды
→ Часть 6: работа с данными



Если вы пока не знаете о том, что такое Docker, сейчас у вас есть шанс сделать первый шаг к пониманию этой платформы. А именно, освоив этот материал, вы разберётесь с основами Docker и попутно приготовите пиццу.

10 августа в Слёрм стартовал видеокурс по Docker, в котором мы разбираем его полностью — от основных абстракций до параметров сети.

В этой статье поговорим об истории появления Docker и его основных абстракциях: Image, Cli, Dockerfile. Лекция рассчитана на новичков, поэтому вряд ли будет интересна опытным пользователям. Здесь не будет крови, аппендикса и глубокого погружения. Самые основы.

Почему люди предпочитают не давать деньги в долг? Потому что сперва даёшь, затем нервничаешь, чтобы вернули в срок, затем, когда не возвращают, как-то неловко намекнуть, а заёмщик и так всеми силами морозится. А если дать в долг государству, крупному банку, любимой ИТ-компании или своему городу? Надёжный заёмщик, гарантированный процент, точные сроки — это заставит задуматься даже самого далёкого от инвестиций человека.

Если бы я ранжировал инструменты фондового рынка и иные инвестиции по степени их консерватизма, то облигации занимали бы уверенное второе место после банковского депозита. Это популярный консервативный инструмент, который направлен на сохранение средств и получение небольшой доходности (+-значение инфляции, если нет кризиса). Однако если бы всё было так просто, то не стоило посвящать облигациям целую большую статью, всё ограничилось бы инструкцией: облигации РЖД и ОФЗ хорошие, а облигации компаний микрозаймов плохие, выбирайте хорошие, ждите доход. Предлагаю отвлечься от всех дел на 20-30 минут и погрузиться в тему облигаций, тем более что вопрос сохранения денег стоит перед многими нашими читателями. 

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

Для упрощения буду использовать аннотации lombok'a:

@Value
@Builder

Недолго погуглив, получаем, что builder — Отделяет конструирование сложного объекта от его представления так, что в результате одного и того же процесса конструирования могут получаться разные представления. Только ли для сложных объектов?

Рассмотрим на простом примере:

@Value
public class Info {
    @Nullable String uuid;
    @Nullable String email;
    @Nullable String phone;
}

Довольно-таки простой класс. На деле получаем иммутабельный объект, который инициализируется через конструктор.

Но, как мы видим, все поля nullable, и создание такие объектов будет выглядеть не очень красиво:

        final Info info1 = new Info(null, "email@email.com", "79998888888");
        final Info info2 = new Info("3d107928-d225-11ea-87d0-0242ac130003", null, null);
        final Info info3 = new Info("3d107928-d225-11ea-87d0-0242ac130003 ", "email@email.com", null);
...

Безусловно, есть варианты:

1. Объекты, где немного полей разных типов, можно завезти несколько конструкторов. Но это не решает проблему класса выше.
2. Использовать setter'ы — субьективно, нагромождает код.

Введение

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

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

Для начала, разберем создание базы данных в MS SQL Server для сервиса поиска соискателей на работу.

Этот материал можно перенести и на другую СУБД такую как MySQL или PostgreSQL.

Спортивный блоггер из YouTube: "Делай это упражнение всего 5 минут в день и у тебя будет стальной пресс"
Твой менеджер проекта: "Чтобы пройти этот опрос нужно 2 минуты, неужели так сложно?"
Онлайн-школа английского языка: "В изучении английского языка - главное регулярность!"
Тренинг по тайм-менеджменту: "Просто заносите все в список задач и проводите еженедельные обзоры."

Часто вам приходится слышать такое, а иногда и говорить другим? Почему сколько бы раз мы не повторяли подобные мантры мы так редко переходим от слов к делу? Как все просто в формулировках… от этого чувство вины от очередного похода к холодильнику вместо пробежки еще сильнее. А помните как хорошо все начиналось? Как плавно шел новый язык программирования, с каким энтузиазмом мы оповещали окружающих о начале здорового образа жизни и утренних пробежек? Методично, но не без усилий, мы разберемся в этом вопросе и сформируем практические советы в ситуации, когда очень хочется начать что-то новое (свой проект, привычку и т.п.), но мы соответствуем этому желанию и сбиваемся с пути. Будет много полезных ссылок, без изучения которых, опыт от прочтения статьи не будет полным.

В данной статье я попытаюсь описать несколько способов, а точнее 6, как добавить security для rest сервиса на Java.

Перед нашей командой была поставлена задача найти все возможные способы добавить security к rest сервису. Проанализировать все за и против и выбрать наиболее подходящий для нашего проекта. Когда я начал искать такую статью в Гугле ничего подходящего не нашел, а были лишь фрагменты и мне пришлось собирать эту информацию по крупицам. Так что думаю, данная статья будет полезна и другим Java разработчикам, пишущим back-end. Я не буду утверждать, что какой-то из этих способов лучше или хуже, все зависит от поставленной задачи и конкретного проекта. Поэтому какой из шести способов подходит больше всего вашему проекту решать только Вам. Я постараюсь описать принцип каждого из подходов и дать небольшой пример с использованием Java и Spring Security.

Иногда получается, что при выполнении очередного проекта, я случайно открываю какие-то обстоятельства, которые, вроде, никто не скрывает, можно даже найти документацию, поясняющую суть… Но многие, включая меня, находятся в плену заблуждений, поэтому не ищут ту документацию, полагаясь на совершенно неверную картину мира. У меня уже намечается целый цикл из статей, в которых я просто сообщаю, что всё, оказывается, не так, как многие (включая меня) думали. Была у меня статья про DMA, была статья про производительность шины PCI Express. К этому же циклу можно отнести статью про конфигурационные ПЗУ для ПЛИС Altera.

Сегодня мне хотелось бы рассказать пару слов про работу Windows Firewall, или, как его называют в русифицированной ОС – брандмауэра. В целом, это очень хорошая штука, но в частности… Оказывается, по умолчанию он работает в достаточно интересном режиме. Как говорится: «А пацаны и не знают». Итак, начинаем разбираться, что там к чему.

Когда я начинал свою карьеру разработчика, моей первой работой стала DBA (администратор базы данных, АБД). В те годы, ещё до AWS RDS, Azure, Google Cloud и других облачных сервисов, существовало два типа АБД:

• АБД инфраструктуры отвечали за настройку базы данных, конфигурирование хранилища и заботу о резервных копиях и репликации. После настройки БД инфраструктурный администратор время от времени «настраивал экземпляры», например, уточнял размеры кэшей.
• АБД приложения получал от АБД инфраструктуры чистую базу и отвечал за её архитектуру: создание таблиц, индексов, ограничений и настройку SQL. АБД приложения также реализовывал ETL-процессы и миграцию данных. Если команды использовали хранимые процедуры, то АБД приложения поддерживал и их.

АБД приложений обычно были частью команд разработки. Они обладали глубокими познаниями по конкретной теме, поэтому обычно работали только над одним-двумя проектами. Инфраструктурные администраторы баз данных обычно входили в ИТ-команду и могли одновременно работать над несколькими проектами.

Автор статьи, перевод которой мы сегодня публикуем, хочет поделиться советами по профессиональной работе с инструментами разработчика браузера. А именно, эти советы рассчитаны на программистов, которые по какой-то причине решили, что их основным браузером будет Google Chrome.

Привет, Хабр.

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

Контроль сессий актуален для большого количества проектов. В нашем приложение необходимо было реализовать ограничение количества активных сессий для одного пользователя. При входе в систему (login) для пользователя создается активная сессия. При входе этого же пользователя с другого устройства необходимо не открывать новую сессию, а проинформировать пользователя об уже существующей активной сессии и предложить ему 2 варианта:

• закрыть прошлую сессию и открыть новую
• не закрывать старую сессию и не открывать новую сессию

Так же при закрытие старой сессии необходимо отправить уведомление администратору об этом событие.

И нужно учесть 2 возможности инвалидации сессии:

• разлогин пользователя (т.е. нажатие пользователем кнопки logout)
• автоматический разлогин после 30 минут бездействия

В этой статье мы рассмотрим пример GraphQL на Java и создадим простой сервер GraphQL со Spring Boot.

Таким цыпочкам тоже нравятся примеры GraphQL на Java со Spring Boot!

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

В этой статье мы рассмотрим пример GraphQL на Java и создадим простой сервер GraphQL со Spring Boot.

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

TL;DR: обзорная статья-руководство по сравнению сред для запуска приложений в контейнерах. Будут рассмотрены возможности Docker и других схожих систем.

Zettelkasten — крутой метод хранения идей и знаний — сейчас на слуху, его уже обсуждали на Хабре. Я веду такой в Notion уже год, потому что Notion лучше всех воплощает три главных принципа Zettelkasten: взаимосвязанность, категоризацию, актуальность. Метод улучшил качество моего обучения и исследований, и без него как-то уже не так. 

Я почитал русскоязычные и англоязычные ресурсы и не нашел ни нормального шаблона для Notion, ни объяснения как реализовать главные преимущества метода Zettelkasten. Под катом и то, и другое. 

UPD: На текущий момент, статья безбожно устарела, потому что за еще один год я набрался опыта, помогая другим людям организовать их Цеттели и наблюдая за чужим опытом. А еще Notion выпустил несколько фич, заточенных именно под Цеттель. И теперь мне совестно, как новички страдают, разбираясь в теме после меня.

Эту статью можно почитать для понимания основ, но актуальные источники информации тут:

• У меня в Психотронке можно следить за подготовкой обновленной версии, ну и написать мне за помощью. А можете не следить: версия 2.0 выйдет на Хабре.
• В русскоязычном сообществе Zettelkasten в Телеграме сидят люди, которые хорошо разбираются в теме. Мы обожаем помогать новичкам.

Дисклеймер: ни Notion, ни автор метода мне за статью не платили.

От переводчика: данная статья написана Дядюшкой Бобом в августе 2012 года, но, на мой взгляд, вполне актуальна до сих пор.



За последние несколько лет мы видели целый ряд идей относительно архитектуры систем. Каждая из них на выходе давала:

1. Независимость от фреймворка. Архитектура не зависит от существования какой-либо библиотеки. Это позволяет использовать фреймворк в качестве инструмента, вместо того, чтобы втискивать свою систему в рамки его ограничений.
2. Тестируемость. Бизнес-правила могут быть протестированы без пользовательского интерфейса, базы данных, веб-сервера или любого другого внешнего компонента.
3. Независимоcть от UI. Пользовательский интерфейс можно легко изменить, не изменяя остальную систему. Например, веб-интерфейс может быть заменен на консольный, без изменения бизнес-правил.
4. Независимоcть от базы данных. Вы можете поменять Oracle или SQL Server на MongoDB, BigTable, CouchDB или что-то еще. Ваши бизнес-правила не связаны с базой данных.
5. Независимость от какого-либо внешнего сервиса. По факту ваши бизнес правила просто ничего не знают о внешнем мире.

Диаграмма в начале этой статьи — попытка объединить все эти идеи в единую эффективную схему.

Вступление

Наверняка первый вопрос, который возник у вас при взгляде на заголовок, был "Шта?". На самом деле я просто перевел фразу "Инверсия управления, внедрение зависимости" в Google Translate на китайский, а затем обратно. Зачем? Затем, что на мой взгляд, это хорошая иллюстрация того, что происходит на самом деле. Люди вокруг путают, коверкают и извращают эти понятия. По долгу службы я провожу много интервью, и 90% того, что я слышу, когда задаю вопрос про DI — честно говоря, откровенный бред. Я сделал поиск по Хабру и нашел несколько статей, которые пытаются раскрыть эту тему, но не могу сказать, что они мне сильно понравились (ладно, ладно, я проглядел только три первых страницы, каюсь). Здесь же на Хабре я встречал в комментариях такую расшифровку IoC, как Injection of Container. Кто-то всерьез предполагает, что есть некий механизм инъекции контейнеров, который сосуществует где-то рядом с DI, и, видимо, даже делает нечто похожее. Только с контейнерами. Мда. На самом деле понять внедрение зависимости очень просто, надо всего лишь…