Это глава 30 моей бесплатной книги про API.

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

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

Для джуна поиск работы похож на полосу препятствий. Тот, кто успешно преодолел ров с крокодилами, катящиеся шары, лаву и дротики с ядом, получает приз — классную работу. 

Всем привет, это Макс Кравец. В 2021 году я написал серию статей о том, почему джуны никому не нужны и куда катится рынок зарплат разработчиков в IT. В них я посмотрел на вопросы со стороны нанимателя. Рассказал, почему джуны — это рисковая инвестиция. Дал общие советы, как новичку не застрять на начальном уровне, прокачать самостоятельно soft- и hard-скиллы и достигнуть желаемого роста в зарплате. Спустя полгода я решил дополнить эти материалы. 

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

Руководитель проектов Валерий не всегда успевает на митапы — тогда он слушает записи в х1,5 с заботливо проставленными таймкодами. В этот раз он смотрит доклады с Пиэмной — онлайн-митапа ЮMoney для руководителей ИТ-проектов. Из видео он узнает:

◾️ на каком уровне организационной зрелости находится его команда и как использовать формулу эволюции для её прокачки;

◾️ почему менеджер проектов — это уже не управляющий, а «масло», которое нужно не каждой команде;

◾️ особенности проектного менеджмента в финтехе и подкапотные процессы банковских операций;

◾️ и какие роли могут быть у пиэма в команде, межкомандном взаимодействии и на уровне отдела;

Если вы — как Валерий, добавляйте в закладки этот пост и смотрите любой доклад под катом в ближайший двадцатиминутный перерыв.

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

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

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

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

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

Методы проверки гипотез. Результаты беседы с продактом из ВТБ. Разговор с продактом из ВТБ

Недавно я готовил курс для Нетологии для новичков-продактов. Есть ощущение, что у всех разное представление о том, какие бывают инструменты проверки гипотез и для чего они используются. Информация из статей в медиа разнится между собой. Хочется создать некую универсальную “памятку”, которая разложила бы по полочкам все по этой теме. В рамках статьи я подчеркнул базовые мысли и выводы, к которым мы пришли в рамках стрима с автором канала https://t.me/productgames.

Об оптимизации закупочной деятельности мы впервые задумались ещё в 2019 году. Создавать облачный сервис для некоммерческих закупок (закупок для нужд компаний) B2B Altis мы решили в нестандартном для российского рынка партнерстве, когда ритейлер выступает не просто заказчиком решения, но и его соразработчиком. В качестве партнера была выбрана крупнейшая коммерческая площадка электронных торгов B2B-Center. Партнерство открывало доступ к проверенной базе российских поставщиков - 574,6 тысячам контрагентов.

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

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

Расскажу, как мы с одногруппником бросили работу в сфере IT и финансов и через год стали зарабатывать вдвое больше, работая на себя. Сначала напишу первую часть — о том, как мы бросали работу. А дальше посмотрим.

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

Начнем с того, что вся продуктовая часть Сравни делится на кроссфункциональные команды. В каждой продуктовой команде есть свой разработчик, аналитик, тестировщик и тд. Сейчас в разных продуктовых командах работает 21 тестировщик. Вместе с развитием продуктов у нас появилась проблема, которая заключалась в рассинхронизации команды тестировщиков: коллеги не знали, кто чем занимается внутри маленьких команд, каждый тестировщик находился в своем “мире” внутри команды. Мы поняли, что начинать работу по улучшению нам надо с командообразующего инструмента. 

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

Лого взято из Github репозитория FastAPI

FastAPI — относительно новый веб-фреймворк, написанный на языке программирования Python для создания REST (а если сильно постараться то и GraphQL) API, основанный на новых возможностях Python 3.6+, таких как: подсказки типов (type-hints), нативная асинхронность (asyncio). Помимо всего прочего, FastAPI плотно интегрируется с OpenAPI-schema и автоматически генерирует документацию для вашего API посредством Swagger и ReDoc

FastAPI построен на базе Starlette и Pydantic.
Starlette — ASGI микро-фреймворк для написания веб-приложений.
Pydantic — библиотека для парсинга и валидации данных основанная на Python type-hints.

Привет! На связи компания KODE. Мы занимаемся разработкой цифровых продуктов для государства и крупного бизнеса в России и Европе с 2013 года.

Руководители наших отделов собрали полноценную библиотеку IT-компании: сайты, блоги, книги, онлайн-курсы, подкасты, Telegram- и YouTube-каналы. Подборка будет полезна менеджерам, аналитикам, разработчикам, дизайнерам и QA.

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

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

Проблема текущих VPN решений в том, что их тяжело правильно настроить, дорого обслуживать, а так же в них полно legacy кода сомнительного качества.

Несколько лет назад канадский специалист по информационной безопасности Jason A. Donenfeld решил, что хватит это терпеть, и начал работу над WireGuard. Сейчас WireGuard готовится к включению в состав ядра Linux, он даже получил похвалы от Линуса Торвальдса и в американском сенате.

Заявленные преимущества WireGuard над другими VPN решениями:

• Простой в использовании.
• Использует современную криптографию: Noise protocol framework, Curve25519, ChaCha20, Poly1305, BLAKE2, SipHash24, HKDF и т.д.
• Компактный читаемый код, проще исследовать на уязвимости.
• Высокая производительность.
• Четкая и проработанная спецификация.

Неужели найдена серебрянная пуля? OpenVPN и IPSec пора закапывать? Я решил с этим разобраться, а заодно сделал скрипт для автоматической установки личного VPN сервера.