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

Хотелось создать статью, которая поэтапно раскроет базовые концепции аутентификации и авторизации на практике, после чего можно применять эти знания, чтобы реализовать свою кастомную аутентификацию и примерно понимать, как она работает в очередном пакете для django-rest-framework, flask или fastapi. А вообще в целом эти концептуальные знания должны пригодиться(надеюсь) и для реализации аутентификации в других экосистемах. В статье есть упрощения, код для учебных целей.

Почему не стоит занижать свои зарплатные ожидания

Недавно мой знакомый Project повысил свой ценник в резюме до 300+ тыс. руб. И ему сразу начали поступать интересные предложения от крупных компаний. Год назад мы с ним занимались планированием карьеры и стабилизацией самооценки. В итоге занятий он осознал свою ценность и уникальность, и уже 3й раз за год поднимает ценник и желаемую должность - и получает офферы. А ведь 1,5 года назад у него был руководитель, который повышал его только через шантаж увольнением.

И его уникальный набор компетенций (бизнес-аналитик + архитектор + разработчик + …) был не востребован. Компании, в которой он работал, была нужна 1/3 от его способностей - и только за них они были готовы платить.

И так происходит со всеми, кто не понимает свою уникальность и ценность и находится не на своем месте.

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

Хочу поделиться опытом создания системы автоматизации функционального тестирования на языке на Kotlin.
Основой для создания / конфигурирования / запуска / контроля выполнения тестов — будет набирающий популярность молодой фреймворк Kotest (в прошлом Kotlin Test).
Проанализировав все популярные варианты для Kotlin — выяснилось, что есть всего два "нативных":

• Spek
• Kotest

Либо бесконечное кол-во из Java мира: Junit4/5, TestNG, Cucumber JVM или другие BDD фреймворки.
Выбора пал на Kotest с бОльшим кол-вом "лайков" на GitHub, чем у Spek.

Руководств по автоматизации тестирования на Kotlin, особенно в сочетании с Kotest — немного.
Думаю, что написать цикл статей про Kotest, а также про организацию проекта авто-тестов, сборку, запуск и сопутствующие технологии — хорошая идея.

Все части руководства:

• Часть 2. Kotest. Deep Diving
• Часть 3. Расширения и Spring Test

Работаю в IT больше 15 лет. Чем только не занимался, но всегда следовал правилу - каждые майские праздники я пытаюсь применить на практике что-то новое.

В этом году я прочитал книгу Event Driven Microservices и загорелся потрогать Kafka как настоящий брокер событий, а не сообщений.

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

Я все детство провозился с ASCII играми в DOS и идея пришла сама собой.

В прошлой статье “QA-обучение без границ” мы поговорили про возможное превращение карьерной лестницы начинающего тестировщика “обучение → получение первого опыта на русскоязычном проекте → получение опыта на англоязычном проекте” в более стремительное “обучение → получение опыта на англоязычном проекте”.
И про то, как с задачей обучить специалиста, на выходе способного работать QA-джуном сразу в международной компании справляются самообразовательная, массовая и менторская модель обучения.
Сегодня мне как специалисту, который более 15 лет занимается подготовкой QA с нуля, хочется продолжить эту тему и поговорить собственно про обучение тестировщиков английскому. Сначала рассмотрим существующие на рынке решения, а потом обрисуем нечто идеальное.

Итак, наша задача - максимально короткое вхождение в QA-английский для обучающегося тестированию или трейни/джуна.

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

Данная заметка - микс различных приемов работы с базой данных, мейнтененса, встречающихся проблем. В общем это чистой воды винегрет и что-то вроде шпаргалки. Я не являюсь гуру PostgreSQL, но могу поделиться своими наработками, которые использую достаточно часто являясь простым java разработчиком. Может кому-то что-то пригодиться.

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

Что наихудшее может случиться в плане софта и коммуникаций?

И что делать?

Привет, хабровчане!

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

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

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

Началось все как обычно: одним прекрасным утром ко мне подошел менеджер и спросил, не хочу ли я заняться одной интересной задачей. К тому времени у меня уже был опыт организации перфоманс-тестирования и вообще улучшения процессов в команде, так что я, конечно, согласился. А когда он объяснил, чем именно предстоит заняться, глаза у меня загорелись!  Только подумайте: построить HA тестирование целой подсистемы —  есть где развернуться, проявить изобретательность!

Привет! Меня зовут Артемий Окулов, я lead центра компетенций CI/CD в X5 Group.

То, чем мы с командой занимаемся, можно отнести к области под названием Developer Experience. В какой-то момент ИТ в компании достигает такой зрелости, что появляются tools team, enabling team и инициативы, направленные на повышение developer experience. Одной из таких инициатив мы и занимаемся. Если вкратце, мы хотим упростить старт новых продуктов в компании за счет предоставления шаблонов.

В X5 Group много web-сервисов, и с переходом на продуктовый подход виден рост количества команд, которые все чаще прибегают к их созданию. Конечно, каждая команда должна быть кросс-функциональной, чтобы успех реализации продукта зависел в большей степени от самой команды. Но часто мы сталкиваемся с тем, что найти инженера с ролью devops в команду — это задача нескольких месяцев. А терять столько времени на старте — непозволительная роскошь. Поэтому в компании ведутся работы по созданию “стартовых наборов”, решающих задачу минимум — быстрого старта разработки и создания dev-окружения силами самих разработчиков.

В поставку такого “стартового набора” входит и CI/CD pipeline. В этой статье, в частности, мы бы хотели поделиться подходом шаблонизации GitLab Pipelines, который мы стараемся продвигать у себя в компании, и рассказать про инструмент, который для этого разработали.

Вторая статья из цикла о функциональном программировании на Kotlin с разбором принципа работы, концепции и способов применения каррирования на практике.

С 2016 года, после того, как я начал использовать Kotlin в Android-разработке, то ни разу не скучал по Java. В целом, Kotlin дал мне большее удовлетворение от разработки, чем Java для Android.

Тем не менее, время от времени я натыкаюсь на такие вещи, которых мне очень не хватает; того, как они были реализованы в Java. Ниже представлены 5 из них.

Куинси Ларсон

freeCodeCamp

В материале приводится продолжение перевода на русский язык стандарта IETF - RFC 5246, описывающего работу протокола безопасности транспортного уровня TLS версии 1.2. Данная часть перевода охватывает вторую половину описания работы рукопожатия TLS версии 1.2, а также завершает перевод основной части Стандарта.

Задумывались ли вы когда-нибудь над тем, что заставляет работать ваш ПК? Я имею в виду по-настоящему работать, а не просто дежурную фразу вроде «процессор загружает операционную систему». Сейчас это стало также очевидно, как и то, что предметы состоят из атомов.

Речь идёт о главных компонентах: когда вы нажимаете кнопку включения и блок питания подаёт напряжение через свои 12, 5 и 3-вольтные линии к материнской плате. Откуда процессору вообще знать, что запускать, и как происходит загрузка в память, когда загружать пока, по сути, нечего?

Такой ход мыслей сложился у нас после мысленного эксперимента: окажись вы в комнате с одной только дискетой и ПК с пустым жёстким диском, смогли бы вы загрузить компьютер и запустить операционную систему? И более того, что надо делать, чтобы запустить ОС?

Ответы на эти вопросы содержатся в данной статье. Она состоит из двух частей. Сначала мы взглянем на мысленный эксперимент, о котором писалось выше, и попытаемся ответить на вопрос: что нужно программировать в первую очередь, чтобы заставить систему загружаться? А потом соберём настоящую операционную систему при помощи дистрибутива Arch Linux, чтобы наглядно показать слаженную работу компонентов нижнего уровня. Сделайте глубокий вдох, мы погружаемся…

Наверняка у читателя есть свои любимые сайты и блоги, посвящённые программированию на языке С++. Сегодня ваша коллекция пополнится.