Продать новую идею может быть тяжело, особенно в случае, если аудитория может ее не принять. Возможно, ей интересно было бы попробовать новый продукт, но только если усилия окажутся минимальными. Люди хотят, чтобы при первом признаке опасности у них под рукой была кнопка «Выход». Последние 20 лет это было практически девизом Linux Live CD: вставьте этот диск (или USB-флэшку) в свой компьютер, попробуйте систему, посмотрите, понравится ли она вам. Если она вам понравится, установите ее. Возможно, вам трудно представить, как мы пришли к такому вполне привычному сейчас формату, когда частью Linux является физический компонент. Это было огромным конкурентным преимуществом Linux. В сегодняшней статье мы расскажем о необычной истории самых первых live CD Linux

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

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

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

Привет! Мы продолжаем проводить QIWI Server Party.

На этот раз — 22 апреля (четверг). Обсудим сразу много полезных штук — продуктовую разработку и developer experience, спринты и инженерные практики, PlantUML (ага, да) и архитектуру платёжного шлюза, разберемся, как разрешать вечные конфликты между разработкой и бизнесом.

А ещё немного похоливарим — стоит ли просить кандидатов писать код на собеседовании? Затронем и эту тему в формате круглого стола. Кстати, аргументированные мнения с радостью почитаем и в комментах.

В общем, будет интересно. Как всегда, вход бесплатный, главное — зарегистрируйтесь заранее.

Программа под катом

Технический долг: он есть у всех, и каждый достойный своего звания разработчик хочет его выплатить, но как же организовать этот процесс?

Реализуем севооборот

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

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

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

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

Привет, Хабр! Предлагаю вашему вниманию перевод статьи The Languages Which Almost Became CSS автора Zack Bloom про языки, которые могли бы стать CSS, сложись история немного иначе.

На протяжении всего прошлого года неисчерпаемым источником удовольствия для меня было то, что я постоянно общался с толпами (в буквальном смысле) людей, желавших (держитесь крепче) контролировать внешний вид своих документов так, как это можно тривиальным образом делать в TeX, Microsoft Word или любой другой среде обработки текстов. Я говорил всем им: "Простите, но вам ничем не помочь".

— Марк Андриссен, 1994 год

Когда в 1991 году Тим Бернерс-Ли объявил о создании HTML, способов стилизации страниц не существовало. Способ рендеринга тегов HTML определялся браузером и на него значительно влияли пользовательские настройки. Однако хорошей идеей казалось создание стандартного инструмента, позволяющего страницам «намекать» об их предпочтительном стилистическом рендеринге.

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

Хотя эти языки, очевидно, сегодня мало где используются, мне интересно поразмышлять над тем, каким бы мог стать мир. Ещё более удивительно то, что многие из этих языков имеют функции, которые разработчики с радостью использовали бы в CSS даже сегодня.

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

Проблема в том, что локальные учетные записи чаще всего не имеют срока действия, не проверяются на сложность, и при этом имеют привилегированный доступ. Плюс ко всему парольные политики не всегда позволяют гибко настроить требования, к примеру, не запрещают использовать словарные пароли (вспомните всеми любимый P@ssw0rd).

У нас в QIWI были похожие проблемы, и в попытках их решить мы перепробовали разные решения для полноценного сканирования баз данных. Увы, они нацелены в основном только на проверку конфигурации СУБД и ничего более. При этом цена такого сканера довольно внушительна.

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

В этом посте я расскажу о том, что мы использовали для своих задач и как в процессе пришли к выводу, что лучше и проще сделать своё. И поделюсь решением со всеми желающими.

Искать утечки и уязвимости в своих продуктах не только интересно и полезно, но и необходимо. Еще полезнее подключать к таким поискам внешних специалистов и энтузиастов, у которых не настолько замылен глаз, как у сотрудников. Поэтому в свое время мы в QIWI запустили программу bug bounty — исследователи писали нам об уязвимостях и получали вознаграждение, а мы — закрывали эти уязвимости. 

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

- разработчик писал тестовый пример кода для себя, используя конфигурации “боевого” сервиса — не тестовую среду;

- админ выкладывал скрипты автоматизации и миграции базы данных — потенциально чувствительной информации;

- стажер неосознанно размещал код в своем публичном репозитории, считая, что это не несет рисков.

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

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

И в целом безопасность компаний — не абсолютна: хорошо защищая свой периметр и информационные системы с помощью с помощью Firewall, SOC, IDS/IPS и сканеров безопасности, компании все равно подвержены многим источникам утечек — от внешней разработки и аудиторов до вендорских решений. Конечно, невозможно отвечать за безопасность других компаний, но мониторить случаи утечки вашей информации с их стороны — можно и нужно.

Поэтомы мы озаботились вопросом утечек по всем источникам. Автоматизировав их поиск, мы сначала сделали продукт для себя, а теперь готовы предлагать его рынку. Так появился QIWI Leak-Search — сервис, который ищет утечки вашего кода на Github и не только. 

Как мы его делали и что он умеет — читайте в посте.

На дворе 2020 год и фоновым шумом вы уже привыкли слышать: «Кубернетес — это ответ!», «Микросервисы!», «Сервис меш!», «Сесурити полиси!». Все вокруг бегут в светлое будущее.

Подходы в том, что касается баз данных, в нашей компании более консервативны, чем в прикладных приложениях. Крутится база данных у нас не в кубернетесе, а на железе или в виртуалке. Для изменений базы данных процессинга платежных сервисов у нас есть устоявшийся процесс, который включает в себя множество автоматических проверок, большое ревью и релиз с участием DBA. Количество проверок и привлекаемых людей в этом случае негативно влияет на time-to-market. С другой стороны, он отлажен и позволяет надежно вносить изменения в продакшен, минимизируя вероятность что-то сломать. А если что-то сломалось, то нужные люди уже включены в процесс починки. Этот подход делает работу основного сервиса компании стабильнее.

Большинство новых реляционных баз данных для микросервисов мы заводим на PostgreSQL. Отлаженный процесс для Oracle хоть и надёжный, но несет с собой избыточную сложность для маленьких БД. Тащить тяжёлые процессы из прошлого в светлое будущее никто не хочет. Проработкой процесса для светлого будущего заранее никто не занялся. В итоге получили отсутствие стандарта и разножопицу.



Если хотите узнать, к каким проблемам это привело и как мы их порешали, — добро пожаловать под кат.

Введение

NestJS — стремительно набирающий популярность фрeймворк, построенный на идеях IoC/DI, модульного дизайна и декораторов. Благодаря последним, Nest имеет лаконичный и выразительный синтаксис, что повышает удобство разработки.

Декораторы или аннотации — наследники аспектов, которые позволяют декларативно описывать логику, модифицировать поведение классов, их свойств, аргументов и методов.

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

Предлагаем вам перевод поста «Unit Testing is Overrated» от Alex Golub, чтобы подискутировать на тему юнит-тестов. Действительно ли они переоценены, как считает автор, или же являются отличным подспорьем в работе? Опрос — в конце поста

Результаты использования юнит-тестов: отчаяние, мучения, гнев

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

В процессе развития отрасли разработки ПО совершенствовались и методики тестирования. Они постепенно сдвигались в сторону автоматизации и повлияли на саму структуру ПО, порождая такие «мантры», как «разработка через тестирование» (test-driven development), делая упор на такие паттерны, как инверсия зависимостей (dependency inversion), и популяризируя построенные на их основе высокоуровневые архитектуры.

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

Однако, несмотря на существование различных подходов, современные «best practices» в основном подталкивают разработчиков к использованию конкретно юнит-тестирования. Тесты, область контроля которых находится в пирамиде Майка Кона выше, или пишутся как часть более масштабного проекта (часто совершенно другими людьми), или полностью игнорируются.

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

Привет!

Меня зовут Алексей, я разработчик в компании QIWI.

TL;DR

Как перебросить из мессенджера сразу на платежную форму:

1. В манифест помещаем пустую Activity c intent-filter вида ACTION_VIEW и ACTION_DIAL со схемой “tel”.
2. В activity перебрасываем на форму оплаты через существующий deeplink, обогатив его данными из оригинального intent-а “tel:XXXXX”

Профит: по клику на подсвеченный номер телефона в мессенджере человек попадает на форму перевода с заполненным полем получателя перевода.
Бонус: расскажу, как красиво включать эту фичу, не имея возможности изменить список intent-filter в манифесте в рантайме.

Зачем?

Привет!

Пару недель назад мы бодренько перевелись на удаленку. Как и большинство из вас.

Главные сложности были в самые первые дни, когда в срочном режиме надо было быстро организовать удаленные рабочие места для многих пользователей. На сегодня у нас онлайн (читай «работают удалённо и в сети») в среднем 1100 пользователей. До всеобщего перехода на удаленку это число редко превышало 400.



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

Привет!

Через 2 недели, 5 марта, мы проведем нашу новую QIWI Кухню.

.
Как это было в 2019

В этот раз собираемся в AGLOFT, это м. Тульская, Варшавское шоссе, 33с3. Вход бесплатный, но регистрироваться лучше заранее (регистрация закрывается 29 февраля). Сделать это можно по ссылке.

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

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

Сегодня поговорим на специфическую тему: автоматизация тестирования ПО для терминалов самообслуживания QIWI.

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

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

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


QIWI-терминал в 2020. На заднем фоне можно увидеть его начинку.

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

Меня зовут Миша Бутримов, я хотел бы хотел немного рассказать про Cassandra. Мой рассказ будет полезен тем, кто никогда не сталкивался с NoSQL-базами, — у нее есть очень много особенностей реализации и подводных камней, про которые нужно знать. И если кроме Oracle или любой другой реляционной базы вы ничего не видели, эти вещи спасут вам жизнь.

Чем хороша Cassandra? Это NoSQL-база данных, cпроектированная без единой точки отказа, которая хорошо масштабируется. Если вам нужно добавить пару терабайт для какой-нибудь базы, вы просто добавляете ноды в кольцо. Расширить ее на еще один дата-центр? Добавляете ноды в кластер. Увеличить обрабатываемый RPS? Добавляете ноды в кластер. В обратную сторону тоже работает.



В чем еще она хороша? В том, чтобы обрабатывать много запросов. Но много — это сколько? 10, 20, 30, 40 тысяч запросов в секунду — это немного. 100 тысяч запросов в секунду на запись — тоже. Есть компании, которые говорили, что они держат 2 млн. запросов в секунду. Вот им, наверное, придется поверить.

И в принципе у Cassandra есть одно большое отличие от реляционных данных — она вообще на них не похожа. И об этом очень важно помнить.

Привет! Меня зовут Паша Черняк, я ведущий разработчик в QIWI, и сегодня я хочу поговорить о неизбежном. О Legacy.

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



Прежде чем переходить к тому, как мы в QIWI работаем с нашими Legacy-сервисами, я расскажу, как мы навели порядок с сервисами в Кошельке. Вот уже два года я отвечаю за его работоспособность. Если есть какая-то проблема, то всегда в первую очередь звонят мне. Мне обычно не хватает наглости в 11 часов вечера позвонить кому-то еще, поэтому приходилось садиться и разбираться во всех сервисах нашего домена.

Но я, как и любой человек, люблю спать по ночам, поэтому пытался разобраться с эксплуатацией: «Ребята, а почему вы мне звоните?». На что получил вполне лаконичный ответ вида «А кому еще?». Потому что я сервисы чиню, а еще ребята банально не знают, кому звонить.

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

Привет!

Мы собираем QIWI Server Party в пятый раз — уже через 10 дней, 17 октября, мы соберемся на улице Правды, дом 24 стр. 3.

Остаёмся привержены традициям — бесплатное участие для тех, кто заранее зарегистрировался, трансляция и интересные выступления спикеров (которых будет целых 8).

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

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


Когда подарил сотруднику поддержки кружку с флешкой на день программиста

Во вторник, 24 сентября, мы поговорим именно об этих ребятах и их деле. В офисе QIWI (м. Чертановская), вход свободный, но надо зарегистрироваться.

Под катом — программа митапа.

Всем привет!

Меня зовут Лидия, я тимлид небольшой DataScience-команды в QIWI.

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

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

Однако, откуда берется тот самый контент или предложение? Если вы впервые погружаетесь в темные воды машинного обучения, то наверняка столкнетесь с вопросом – с чего начать и как выявить те самые интересы клиента. Чаще всего при наличии большой базы пользователей и отсутствии знаний об оных возникает желание пойти по двум популярным путям:

1. Разметить вручную выборку пользователей и обучить на ней модель, которая позволит определять принадлежность к этому классу или классам – в случае мультиклассового таргета.

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



2. Обжегшись на варианте #1, часто выбирают вариант unsupervised-анализа без обучающей выборки.

Изначально весь проект был написан на Objective-C и использовал ReactiveCocoa версии 2.0

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

И вот настало время использовать Swift. Поначалу мы решили попробовать вообще без реактивщины.