Всем привет, мы – Таня и Лиза, системные аналитики в МТС. В этой статье мы поделимся опытом внедрения структурированного шаблона функциональных требований (ФТ) к разработке ПО в нашей команде.

Статья будет полезна тем, кто работает с фронтовым функционалом – системными и бизнес-аналитикам. Неважно, Junior вы или Lead, в большой работаете компании или в стартапе, – наш рассказ вас наверняка заинтересует. Поговорим не только о том, как мы докатились до такой жизни, приняли единый формат ФТ, но и том, какие именно артефакты аналитик готовит в ходе своей работы. А еще мы подробно расскажем про причины поиска подходящего формата, сложности перехода и составляющие наших ФТ. 

Добро пожаловать под кат!

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

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

Администратор баз данных в Southbridge и ведущий инженер компании Data Driven Lab Иван Чувашов занимается базами данных 15 лет и сегодня хочет поговорить про оптимизацию запросов. Разбирать все будет на примере PostgreSQL, так как именно с этой базой он сейчас работает плотнее всего.

Эта статья — конспект бесплатного вебинара об оптимизации PostgreSQL от «Слёрма». Если вам удобнее смотреть, а не читать, переходите на YouTube.

Как выглядит идеальная работа программиста? Что делает делает хорошую работу хорошей? Хотя бы не плохой?

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

А сталкивались ли вы с такой ситуацией?

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

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

• Простота. Стажёр или студент, приходя к нам, может уже через неделю написать и отправить в продакшен новый микросервис.
• Надёжность. Многие ошибки, в том числе и связанные с многопоточностью, можно поймать на этапе компиляции. Кроме того, фреймворк даёт подсказки по исправлению проблем.
• Полнота. В userver есть всё необходимое для тестирования, работы с разными базами данных, кеширования, логирования, трейсинга, распределённых блокировок, работы с JSON, BSON, YAML, изменения параметров сервиса на лету и так далее.

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

Нагрузочное тестирование является важной частью жизненного цикла разработки программного обеспечения (software development life cycle, SDLC) для современных корпоративных приложений. В этом руководстве мы рассмотрим использование коллекций Postman для написания нагрузочных тестов.

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

Ответ положительный, чему и посвящена данная статья.

Какие средства в принципе есть для решения задачи? Их сейчас два: выделение именованных сущностей (NER) и объекты ГАР ФИАС. NER даёт разбиение на адресные элементы и их нормализацию, ГАР ФИАС может дать уникальные идентификаторы. Задача решается, если в качестве нормализации взять множество строк из возможных нормализаций наименований элементов, добавив к ним GUID-идентификаторы ГАР, если получится. Два адреса эквивалентны, если хотя бы одна строка из множеств таких их строк совпадает.

А одними объектами ГАР ФИАС можно обойтись, используя только их идентификаторы? Конечно, нет. Во-первых, это не полный классификатор, особенно в части помещений и строений, хотя и постоянно пополняемый. Во-вторых, в адресах бывают специфические элементы, которые в ГАР отсутствуют (например, Московская область, Можайский район, примерно в 0,1 км по направлению на юг от ориентира середина д.Бараново, или пересечение улиц).

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

На большей части проектов сейчас востребованы знания по тест-дизайну и тестированию API.

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

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

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

Действительно, по общему правилу, исключительные права на произведения принадлежат работодателю, если иное не установлено в договоре (к примеру в трудовом договоре), но только если оно разработано работником (автором) в пределах его трудовых обязанностей. Однако, если работник вдруг обратится в суд, посчитав что исключительное право на произведение принадлежит ему, т.к. создано оно вне рамок исполнения им своих трудовых функций, сможете ли вы доказать суду документально, что этот работник создал произведение именно в рамках своих трудовых обязанностей? Если нет, то суд с большой долей вероятности может принять решение в сторону работника, тем более не следует забывать что работник в данном случае является "слабой стороной", а значит спрос с работодателя в суде будет максимальным. Исходя из личного профессионального опыта могу с уверенностью сказать что многие работодатели не уделяют кадровым документам надлежащего внимания и зачастую даже название должности не соответствует тому, чем фактически занимается работник. Ни в трудовом договоре, ни еще где-либо отсутствуют функциональные обязанности или прописаны так абстрактно, что судью становится очень сложно убедить в том, что имелось ввиду в таких «рукописях».

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

Начиная новый проект, хорошо вспомнить полезные принципы программирования, которые помогут правильно расставить приоритеты и избежать многих ошибок. Рекомендациями от автора с опытом программирования в 20 лет делимся к старту курса по Fullstack-разработке на Python.

Доклад Алексея Лесовского про то, что нового есть в PostgreSQL в плане мониторинга.

Охватывать Алексей будет 13 и 14 версии. Далее от его лица.

1. Блокировки отношений (эта статья);
2. Блокировки строк;
3. Блокировки других объектов и предикатные блокировки;
4. Блокировки в оперативной памяти.

Читайте и другие серии.

Индексы:

1. Механизм индексирования;
2. Интерфейс метода доступа, классы и семейства операторов;
3. Hash;
4. B-tree;
5. GiST;
6. SP-GiST;
7. GIN;
8. RUM;
9. BRIN;
10. Bloom.

Изоляция и многоверсионность:

1. Изоляция, как ее понимают стандарт и PostgreSQL;
2. Слои, файлы, страницы — что творится на физическом уровне;
3. Версии строк, виртуальные и вложенные транзакции;
4. Снимки данных и видимость версий строк, горизонт событий;
5. Внутристраничная очистка и HOT-обновления;
6. Обычная очистка (vacuum);
7. Автоматическая очистка (autovacuum);
8. Переполнение счетчика транзакций и заморозка.

Журналирование:

1. Буферный кеш;
2. Журнал предзаписи — как устроен и как используется при восстановлении;
3. Контрольная точка и фоновая запись — зачем нужны и как настраиваются;
4. Настройка журнала — уровни и решаемые задачи, надежность и производительность.

Отношения (relations)

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