CTO
Собеседование Backend-Java-разработчика: вопросы и где искать ответы. Часть 1
Когда-то я проходил серию собеседований на Backend-Java-разработчика и записывал вопросы себе на будущее, чтобы потом можно было пробежаться и освежить память. Подумалось, что, вероятно, данный сборник будет полезен не только мне, поэтому сдул с него пыль, набросал ответов и делюсь с сообществом. На оригинальность и исключительность не претендую: подобные статьи уже были и на Хабре, и много где ещё — в конце (во второй части) приведу список ссылок, чтобы шпаргалка была максимально полной.
Точно установить сложность всех вопросов не берусь — на разном уровне их потребуется раскрыть с различной степенью подробности. Я написал ответы где-то на плюс-минус middle, щедро приправив ссылками для дальнейших изысканий. На самые популярные вопросы сразу перенаправляю в источники с готовыми ответами. Заодно посмотрим по ссылкам в статье, насколько Хабр может помочь в подготовке к собесам.
Текста получилось много, поэтому пришлось разбить на две части. В первой поговорим про Java и Spring, а обо всём остальном — во второй. Вторая часть тут
Собеседование Backend-Java-разработчика: вопросы и где искать ответы. Часть 2
Публикую продолжение сборника вопросов-ответов с собеседований на Backend-Java-разработчика. В первой части мы прошлись по Java и Spring. А в этой поговрим о Hibernate, базах данных, паттернах и практиках разработки, об одной популярной библиотеке, поддержке и сопровождении наших приложений, а также посмотрим на альтернативные шпаргалки и подведём итоги.
Внедрение рекомендаций по структуре кода с использованием ArchUnit
При создании программного обеспечения все мы, как команда, соглашаемся следовать набору рекомендаций, которые обычно считаются лучшими практиками. Но во время разработки разработчики могут нарушить эти правила по незнанию или нежеланию. Обычно мы полагаемся на ревью кода или инструменты проверки качества кода, такие как SonarQube , PMD и т.д. для проверки таких нарушений. Но некоторые из рекомендаций могут быть решениями, которые нельзя автоматизировать с помощью SonarQube, PMD и т.д.
Например, обычно я хочу следовать приведенным ниже рекомендациям для моих приложений на основе Java:
1. Следуйте трехуровневой структуре (уровни веб, сервис, репозиторий), где любой уровень может взаимодействовать только с непосредственным нижним уровнем, а нижний уровень не должен взаимодействовать с верхним уровнем. т.е. веб-уровень может взаимодействовать с уровнем сервиса, уровень сервиса может взаимодействовать с уровнем репозитория. Но уровень репозитория не может взаимодействовать с сервисным или веб-уровнем, сервисный уровень не может взаимодействовать с веб-уровнем.
2. Если приложение большое, мы могли бы захотеть следовать структуре Package-By-Feature, где только компоненты Web и Service являются public, а остальные компоненты должны быть package-private.
3. При использовании внедрения зависимостей Spring не используйте внедрение на основе поля и предпочитайте внедрение на основе конструктора.
Таким образом, может быть много правил, которым мы хотим следовать. Хорошая новость заключается в том, что мы можем проконтролировать выполнение этих рекомендаций с помощью JUnit тестов с использованием ArchUnit.
12 причин не идти в стартап
Я адресую эту статью начинающим программистам, которые либо не имеют опыта работы вообще, либо имеют небольшой опыт (до 5 лет). Как показывает практика, именно эта категория людей имеет максимально искаженные представления о стартапах в сфере IT. Искаженные – в том смысле, что на вопрос «что можешь сказать положительного о стартапах?», они могут долго пересказывать чужие и в немалой степени устаревшие мысли, а на вопрос «что не так со стартапами?» — в ответ могут лишь неуверенно вопросить: «они могут не выстрелить?»
Эта статья предназначена тем, кто просто никогда не задумывался над вопросом, почему не стоит идти работать в стартап в качестве сотрудника. Поехали!
Международная ИТ-конференция Devoxx 2020: эксклюзивно в Украине и полностью бесплатно
Конференции и другие тематические события под брендом Devoxx и аффилированным Voxxed Days проходят в Британии, Бельгии, Франции, Польше, Греции, Марокко и Беларуси.
Однако в этом году Devoxx — эксклюзив для Украины. Только в этой стране партнеры и организаторы осмелились перенести такое масштабное событие в онлайн-формат. И сделать участие полностью бесплатным.
Используем Ansible вместе с Terraform
Недавно я начал применять Terraform для создания облачной лабы для тестов, и это довольно круто. Буквально за несколько дней я поднялся с «никогда не использовал AWS» до «я умею декларативно создавать изолированную инфраструктуру в облаке». Я поставил парочку серверов в выделенной сети в VPC с security group и отдельными ключами SSH, все это заняло у меня несколько сотен строк кода.
Все приятно и прельстиво, но после создания сервера из некоторого базового AMI мне надо его развернуть. Мой типовой инструмент для этого — Ansible, но, к сожалению, у Terraform нет встроенного модуля для Ansible (есть обратный, начиная с Ansible 2.5, прим. переводчика), в отличие от Chef и Salt. Это не похоже на Packer, имеющий ansible
(удаленный) и ansible-local
, который я использовал для сборки образов Docker.
Так что я потратил немножко времени и нашел несколько способов подружить Terraform и Ansible, о чем расскажу в этой статье. Но сначала — поговорим о развертывании.
Выгорание и стресс — это когда жизнь проходит без нас
Альфрид Лэнгле (фото: Артем Лапшин, discours.io)
Как предотвратить выгорание и как помочь себе, если это уже с вами произошло? Об этом была лекция доктора медицинских и философских наук Альфрида Лэнгле, которую он недавно прочел в НИУ ВШЭ в Санкт-Петербурге.
Опционы: пут-колл парити, броуновское движение. Ликбез для гика, ч. 7
Будет немного математики, чтобы получше разобраться в деталях.
Передовой опыт тестирования в Java
Чтобы покрытие кода было достаточным, а создание нового функционала и рефакторинг старого проходили без страха что-то сломать, тесты должны быть поддерживаемыми и легко читаемыми. В этой статье я расскажу о множестве приёмов написания юнит- и интеграционных тестов на Java, собранных мной за несколько лет. Я буду опираться на современные технологии: JUnit5, AssertJ, Testcontainers, а также не обойду вниманием Kotlin. Некоторые советы покажутся вам очевидными, другие могут идти вразрез с тем, что вы читали в книгах о разработке ПО и тестировании.
Ускоряем Ansible
Ни для кого не секрет, что с настройками «по умолчанию» Ansible может делать своё дело не слишком быстро. В статье я укажу на несколько причин этого и предложу полезный минимум настроек, которые, вполне возможно, реально увеличат скорость работы вашего проекта.
Как Spring Data работает с Redis
Redis (Remote Dictionary Server) - заслужено считается старичком в мире NoSql решений. Этот пост про то, как Spring Data с ним работает. Идея написания данного поста возникла потому, что Redis не совсем похож на привычную базу, он поддерживает типы данных, которые не удобно использовать для хранения объектов(Кеш не в счет) и выполнять поиск по определенным полям. Здесь на примерах я постараюсь описать как с ним работает Spring Data посредством привычного CrudRepository и QueryDSL. Это не пример HowTo, которых множество. Кому интересны внутренности идем дальше.
Правда ли то, что скрам уничтожает отличных программистов, или дело в том, что его неправильно применяют?
Основная идея фреймворка скрам заключается в организации процесса разработки для более быстрого выполнения работ на различных этапах жизненного цикла проекта. Но всегда ли такой подход подталкивает разработчиков к правильным моделям поведения? Многие пользователи, присоединившиеся к обсуждению вышеупомянутого вопроса на Stack Overflow, сталкивались с похожими вещами, когда разработчики «срезают углы», слишком большое значение придают высоким баллам, назначенным их тикетам, или даже прикидываются перед менеджерами высокопроизводительными сотрудниками. Как избежать этих опасностей?
Вопрос, о котором идёт речь, перешёл с workplace.stackexchange.com на softwareengineering.stackexchange.com. Это говорит о том, что программисты рассматривают соображения, связанные со скрамом и с его эффективностью, как нечто достаточно серьёзное, выходящее за рамки управления циклом разработки ПО. Они ощущают воздействие этого метода управления проектами на рабочую обстановку в целом.
Как я веду Zettelkasten в Notion уже год: стартовый набор и полезные трюки
Zettelkasten — крутой метод хранения идей и знаний — сейчас на слуху, его уже обсуждали на Хабре. Я веду такой в Notion уже год, потому что Notion лучше всех воплощает три главных принципа Zettelkasten: взаимосвязанность, категоризацию, актуальность. Метод улучшил качество моего обучения и исследований, и без него как-то уже не так.
Я почитал русскоязычные и англоязычные ресурсы и не нашел ни нормального шаблона для Notion, ни объяснения как реализовать главные преимущества метода Zettelkasten. Под катом и то, и другое.
UPD: На текущий момент, статья безбожно устарела, потому что за еще один год я набрался опыта, помогая другим людям организовать их Цеттели и наблюдая за чужим опытом. А еще Notion выпустил несколько фич, заточенных именно под Цеттель. И теперь мне совестно, как новички страдают, разбираясь в теме после меня.
Эту статью можно почитать для понимания основ, но актуальные источники информации тут:
- У меня в Психотронке можно следить за подготовкой обновленной версии, ну и написать мне за помощью. А можете не следить: версия 2.0 выйдет на Хабре.
- В русскоязычном сообществе Zettelkasten в Телеграме сидят люди, которые хорошо разбираются в теме. Мы обожаем помогать новичкам.
Дисклеймер: ни Notion, ни автор метода мне за статью не платили.
Как GitLab помогает делать бэкапы больших хранилищ NextCloud
Привет, Хабр!
Сегодня я хочу рассказать о нашем опыте автоматизации резервного копирования больших данных хранилищ Nextcloud в разных конфигурациях. Я работаю СТО в «Молния АК», где мы занимаемся конфигурационным управлением IT систем, для хранения данных используется Nextcloud. В том числе, с распределенной структурой, с резервированием.
Проблемы вытекающие из особенностей инсталляций в том, что данных много. Версионирование которое дает Nextcloud, резервирование, субъективные причины, и другое создает много дублей.
Предыстория
При администрировании Nextcloud остро встает проблема организации эффективного бэкапа который нужно обязательно шифровать, так как данные ценны.
Мы предлагаем варианты хранения бэкапа у нас или у заказчика на его отдельных от Nextcloud машинах, что требует гибкого автоматизированного подхода к администрированию.
Клиентов много, все они с разными конфигурациями, и все на своих площадках и со своими особенностями. Тут стандартная методика когда вся площадка принадлежит тебе, и бэкапы делаются из крона подходит плохо.
Для начала посмотрим на вводные данные. Нам нужно:
- Масштабируемость в плане одна нода или несколько. Для крупных исталляций мы используем в качестве хранилища minio.
- Узнавать о проблемах с выполнением бэкапа.
- Нужно хранить бэкап у клиентов и/или у нас.
- Быстро и легко разбираться с проблемами.
- Клиенты и установки сильно отличаются один от другого — единообразия добиться не получается.
- Скорость восстановления должна быть минимальна по двум сценариям: полное восстановление (дизастер), одна папка — стерто по ошибке.
- Обязательна функция дедупликации.
Для решения задачи управления бекапами мы прикрутили GitLab. Подробнее подкатом.
Как получить 100% зрения и даже больше
В древние времена остроту зрения проверяли по созвездию Большой Медведицы в ночном небе. Это созвездие напоминает «ковш с ручкой» и практически всегда видно на ночном небе. Так рядом со второй звездой от конца «ручки ковша» (Мицар) находится малозаметная небольшая звезда Алькор («забытая, незначительная»). Способность видеть эту малозаметную звезду считалась традиционным способом проверки зрения, условной нормой. То есть, система была бинарная – «вижу» и «не вижу».
Эра починки зрения началась несколько столетий назад, использовать для этого лазер стали всего пару десятилетий назад и совершили технологический скачок до эндоскопической коррекции зрения ReLEX SMILE, о ней писала здесь.
В мире с 1985 года выполнено более 60 миллионов процедур по лазерной коррекции зрения! И все эти люди счастливы, что получили 100% зрение, спросите вы? А теперь самое интересное – нет, не все счастливы. И уж точно не у всех 100%.
Что может быть причиной не 100% зрения, почему люди «щурятся», как оценивать показатели приборов, которые измеряют параметры глаза, в том числе после лазерной коррекции, можно ли им доверять, как избежать багов при тестировании, какие исследования, зачем и когда необходимы, чтобы прояснить картину?
Поделюсь тем, что должен знать офтальмолог, и как правило, о чем не в курсе пациент.
Прямая передача файлов между устройствами по WebRTC
Новый сервис WebWormHole работает как портал, через который файлы передаются с компьютера на другой. Нажимаете кнопку New Wormhole — и получаете код для входа. Человек с другой стороны вводит такой же код или URL — и между вами устанавливается эфемерный туннель, по которому напрямую передаются файлы. Очень просто и эффективно. Исходный код на Github.
Эффективен ли TDD?
Есть полно исследований, демонстрирующих эффективность TDD
Действительно. Если зайти на Google Scholar, забить ключевые слова «TDD» и «Эффективность» — будет много научных статей, но так ли все просто? Хоть я сам и являюсь большим фанатом TDD, но я так же считаю себя скептиком, и решил проверить, доказано ли научно, что TDD так крут.
Несколько советов о том, как ускорить сборку Docker-образов. Например, до 30 секунд
Прежде чем фича попадет на прод, в наше время сложных оркестраторов и CI/CD предстоит пройти долгий путь от коммита до тестов и доставки. Раньше можно было кинуть новые файлы по FTP (так больше никто не делает, верно?), и процесс «деплоя» занимал секунды. Теперь же надо создать merge request и ждать немалое время, пока фича доберётся до пользователей.
Часть этого пути — сборка Docker-образа. Иногда сборка длится минуты, иногда — десятки минут, что сложно назвать нормальным. В данной статье возьмём простое приложение, которое упакуем в образ, применим несколько методов для ускорения сборки и рассмотрим нюансы работы этих методов.
Как стать DevOps инженером за полгода или даже быстрее. Часть 2. Конфигурирование
Освежим память по-быстрому
В первой части я утверждал, что работа инженера DevOps заключается в создании полностью автоматизированных цифровых конвейеров, которые перемещают код от машины разработчика к производству. Для эффективного выполнения этой работы требуется понимание основ, которыми являются ОС, язык программирования и облачный сервис хранения данных, а также хорошее понимание базирующихся на этой основе инструментов и навыков.
Напомню, что ваша цель состоит в том, чтобы сначала слева направо изучить вещи синего цвета, а затем также слева направо изучить вещи фиолетового цвета. Сейчас мы рассмотрим первый из 6 месяцев обучения, посвященный конфигурированию.
Information
- Rating
- Does not participate
- Date of birth
- Registered
- Activity