Привет! Мы — команда тестирования производительности в Тинькофф, и мы любим инструмент Gatling. В цикле статей мы расскажем об использовании Gatling и дополнительных инструментов, упрощающих разработку скриптов.
Возможно, вы уже читали наши статьи про Gatling: первую и вторую. Они успели устареть, поэтому мы решили вернуться с обновленной информацией.
Меня зовут Сергей Марков, я системный аналитик бэковой части в Академии Инвестиций Тинькофф.
Системные аналитики работают в разных направлениях: сбор и управление требованиями, проектирование бизнес-процессов, техническое проектирование системы. Список задач можно расширять и детализировать дальше. В зависимости от сферы, размера и культуры компании обязанности системного аналитика могут быть разными. У нас в Тинькофф для системного аналитика делается довольно сильный акцент на технические знания и навыки.
Привет! Меня зовут Михаил Иванов, я работаю архитектором DWH в Тинькофф и занимаюсь развитием Batch ETL направления платформы обработки данных. Я расскажу о направлении data engineering в Тинькофф, о том, чем занимаются data-инженеры и как попасть к нам в команду.
Среди дизайнеров есть мнение, что оптимальная длина строки — около 60 знаков. Строку такой длины проще всего читать. Чем длиннее строка, тем сложнее удержать фокус. Когда человек прочитывает ее до конца, взгляд уходит слишком далеко и начало следующей строки теряется. Читать слишком короткие строки тоже неудобно. Вроде весь текст перед глазами, но приходится часто перепрыгивать со строчки на строчку.
Роберт Брингхерст в книге «Основы стиля в типографике» говорит, что оптимальное значение длины строки составляет от 45 до 75 знаков. 66 — идеальный вариант, а для многоколонного набора — 40—50 знаков.
Максим Ильяхов пишет, что за максимум берет 75 знаков, — столько помещается на страницу А4 с полями при наборе 12-м кеглем.
Smashing Magazine в 2009 году провели исследование и выяснили, что средний результат символов на строку равен 88,74, а среднее значение изменяется от 75 до 85.
Я решила узнать, подтверждается ли мнение дизайнеров исследованиями, и нашла статьи, где ученые проверяли изменение параметров читаемости в зависимости от длины строки.
Привет! Я Тамара, дизайнер навыков голосового финансового ассистента Олега. Сегодня я расскажу, из чего состоит работа дизайнера диалогов и какое будущее ждет голосовых ассистентов. Это будет полезно тем, кто интересуется голосовыми интерфейсами, работает в этой сфере или думает попробовать.
Привет! Я Максим Коробов, руководитель отдела разработки мобильного приложения Тинькофф. В статье расскажу о том, как проходит отбор кандидатов на вакансии разработчиков iOS и Android, что спрашивают на первичном и техническом интервью и какие задачи предлагают решать во время практической секции.
Материал будет полезен разработчикам, которые ищут точки роста, интересуются проектами в крупных компаниях или хотят работать именно в Тинькофф. Если это про вас, не переключайтесь.
Я работаю в Тинькофф и часто провожу собеседования. Это полезное занятие: я не только помогаю нанимать разработчиков, но и поддерживаю теоретические знания в неплохом состоянии. Если где-то обнаруживаются пробелы, это хорошая мотивация их заполнить, чтобы не быть сапожником без сапог.
Раньше совершенствование навыков было для меня единственной серьезной мотивацией участвовать в собеседованиях. Но недавно я понял, что в проведении интервью есть еще один полезный момент. Ниже я расскажу несколько историй, которые заставили меня взглянуть на проведение собеседований с другой точки зрения.
Меня зовут Дмитрий Масленников, и я руковожу Центром надёжности информационных систем в Тинькофф. Недавно я выступал на вебинаре Слёрма «Особенности SRE в России». В поддержку своего курса по «SRE: внедряем DevOps от Google» Слёрм собирает интересные кейсы внедрения SRE в российских компаниях. Я рассказал, как устроена наша экосистема SRE, зачем мы используем самописные сервисы, почему в SRE должна работать инженерная элита и как примкнуть к этой элите за один день. А теперь делюсь этим здесь.
Меня зовут Евгений Подивилов, я фронтенд-разработчик в команде «Лайфстайл». Я разрабатываю раздел «Развлечения». В этом разделе можно купить билеты на мероприятия или забронировать столик в ресторане.
Многие недолюбливают бесконечные индикаторы загрузки, потому что по ним не видно реального прогресса выполнения задачи. Мне кажется, вывести какой-то спиннер пользователю и уведомить, что работа идет и результат ожидается, намного лучше, чем ничего.
Иногда спиннер вместо того, чтобы успокоить пользователя, тормозит и забирает больше ресурсов, чем сама задача. Про один такой индикатор я и расскажу.
Мы с коллегой @Methaqualone несколько раз столкнулись с утверждением, что в России цифровые сервисы лучше, а мобильные банки дружелюбнее. Якобы наши государственные порталы удобнее, а интерфейсы интернет-магазинов интуитивно понятнее.
Ни одна из нас не жила за границей, но стало интересно проверить: это как сакраментальное «русские девушки самые красивые» или зарубежные пользователи тоже считают, что наши интерфейсы самые классные? И если да, то почему?
Меня зовут Юля, я разработчик команды ETNA. Расскажу о том, как мы запустили открытый инструмент для аналитики и прогнозирования бизнес-процессов, как он устроен и как его использовать.
В Тинькофф мы часто решаем задачи по прогнозированию: хотим знать количество звонков на линии обслуживания или сколько наличных клиенты снимут в банкомате на следующей неделе. Специалисты по обработке данных и аналитики, которые сталкиваются с проблемами прогнозирования, могут использовать целый ряд различных инструментов для своей работы. Это неудобно и требует времени. Чтобы упростить задачу, мы разработали наш фреймворк.
Работа над общей библиотекой сильно отличается от работы в продуктовой команде. Но разработчики библиотек тоже проходят длинный путь становления своего продукта, причем, в отличие от приложений, часто без помощи менеджеров или бизнес-аналитиков.
Давайте посмотрим, из чего может состоять путь крупной библиотеки, как планировать действия команде разработки и какие челленджи могут встретиться на нем.
Статья написана по опыту разработки фронтовых библиотек и с советами вокруг JS-экосистемы, но часть идей будет полезна и для других направлений.
Можете представить Новый год без мандаринов, елки и подарков? А что насчет фильма «Один дома»? Каждый год мы наблюдаем за судьбой мальчика, который забаррикадировался дома и обороняет его от двух бандитов. Эта история стала неотъемлемой частью каждого Нового года, и предстоящий праздник не будет исключением. А что, если мы предложим вам помочь Кевину в обороне дома?
Мы решили написать небольшую игру в жанре Interactive Fiction на базе телеграм-бота. Целевой аудиторией стали разработчики. Участники игры будут две недели общаться с Кевином и помогать ему программировать устройства в умном доме, чтобы разрушить планы грабителей. Для работы выбрали NestJS. Расскажу подробнее, что из этого получилось.
Статья не станет учебным пособием о том, как писать телеграм-бота на Node.js с нуля. Весь базовый обучающий контент находится в свободном доступе. Эта история про наши подходы к решению проблем, с которыми пришлось столкнуться.
Привет! Меня зовут Аркадий. Последние пару лет я в основном занимаюсь развитием поиска по тексту в команде TQM (Tinkoff Quality Management) в банке Тинькофф. Наш продукт — это речевая аналитика по звонкам, чатам и другим активностям, контроль качества, анализ и прочее. Более подробно о продукте можно прочитать на странице бизнес-решений. Примерный объем нашего индекса в проде — 16 Тб, около 450 млрд сущностей.
Каждый раз, когда встает вопрос о полнотекстовом поиске, команда оказывается перед выбором: а надо ли? Уже есть полнотекстовый поиск в Postgres, а тут придется заказывать серверы, строить кластер. Но чем чаще пользователю требуется что-то найти, тем чаще приходится смотреть в сторону специализированных поисковых движков.
Как пишут сами разработчики Elasticsearch, он нужен именно «для поиска, вы же знаете» (you know, for search) и не сможет заменить полноценное хранилище данных. Зато достаточно быстрый, очень надежный и хорошо горизонтально масштабируется (при наших объемах).
Мы в TQM используем Elastic потому, что он гибкий, широко известный, имеет удобный и простой синтаксис, множество библиотек для работы как на Python, так и на C# (NEST). Хорошо скейлится под наши объемы (1—30 Тб). Kibana также очень удобна, мы используем ее для мониторинга, консоль Kibana применяем для запросов. А еще по сравнению с тем же Sphinx, Elastic удобно масштабировать (просто добавляем шарды, ноды, и он сам распределяет данные по ним). В случае с тем же Sphinx нам пришлось бы писать этот распределенный поиск самим, и не факт, что у нас получилось бы хорошо с первого раза.
Я всегда старался выносить в опенсорс все, что может быть полезно людям вне моей компании. Помимо стремления не только брать от сообщества, но и отдавать, это приносит ряд бенефитов для самой компании.
Всю статью я построил на примерах опыта Taiga UI — огромной библиотеки компонентов под Angular, которая долго развивалась внутри компании, а 10 месяцев назад была выложена в опенсорс. Несмотря на то, что примеры взяты из опыта фронтовой библиотеки, все пункты применимы и актуальны для любого другого стека.
На днях я смотрел кино, где оператор использовал телеграф. Он знал наизусть азбуку Морзе и очень быстро нажимал свою единственную кнопку. Я задумался: с RxJS мы способны на большее! Давайте запилим телеграф, используя единственный fromEvent и массу интересных трюков. Потренируемся с Dependency Injection, директивами и операторами RxJS, чтобы собрать демо, которое выглядит круто и звучит аутентично.
Привет, я Евгений Степченко, delivery-менеджер Тинькофф. В октябре мы провели Tinkoff Agile Conference про масштабирование изменений и изменения при масштабировании, развитие команд и инженерные практики. Нам важно, чтобы тимлиды, техлиды, менеджеры и эксперты развивались как единое сообщество. Поэтому мы собрали конференцию, позвали профессионалов из разных областей и постарались создать площадку для нетворкинга. Спикеры рассказывали о методах управления, метриках, технических аспектах гибкой разработки и о том, как безопаснее проводить изменения.
Шесть тысяч зрителей смотрели конференцию онлайн, а двести пятьдесят человек присутствовали в новом для нас формате — живого общения. Участники активно задавали вопросы и вовлечённо работали на воркшопах. Писали в чате, как не хватало живых мероприятий во время пандемии, увозили домой инсайты, а кто-то даже поменял представление о Тинькофф в лучшую сторону.
Я участвовал в подготовке программы мероприятия и помогал с организацией на месте. Хочу поделиться с вами атмосферой конференции и рассказать подробнее про несколько докладов. В конце статьи оставлю ссылки на все записи и подборку фотографий.
Меня зовут дядя Вова, я ведущий инженер по автоматизации тестирования и, как писал уже несколько раз, неизменный фанат Robot Framework. Даже когда-то контрибьютил в его исходный код и иногда помогаю новичкам в официальном slack-чате этого инструмента.
Но, как я уже упоминал в одной из статей, есть у него один пробел по сравнению с pytest — это отсутствие адекватной параметризации тестов. Справедливости ради, у Robot Framework есть надстройка, которая позволяет генерировать тесты на основе внешней таблицы. Но это не совсем то, что нам подходит.
После прошлой статьи многие спрашивали меня, как именно делается параметрическая генерация автотестов. В этой статье отвечу на вопрос.
Привет, меня зовут Макс, я продакт команды Self-Service в мобильном приложении Тинькофф. У моей команды три основные цели по созданию сервиса: contactless, proactive и self-service.
Это значит, что мы стараемся сделать незаметными процессы для пользователя: убрать то, что можно убрать, и сделать незаметным то, что можно сделать незаметным. Проблемы решаем проактивно, если можем предсказать проблему, и упрощаем процесс за счет технологий.
Сегодня хочу рассказать о том, как мы в команде подходим к оценке задач и их приоритизации. А еще о том, как не делать лишнюю работу в условиях сложного продукта с большим количеством зависимостей.
Если вы отвечаете за разработку продукта, то в процессе изучения конкурентов, качественной и количественной аналитики, общения с коллегами или стейкхолдерами у вас появляются идеи, да и желающих накинуть их всегда хватает.
Представим, что вы всё записываете в заметки или блокнотик. У здорового продакта возникает логичный вопрос: какие задачи решать в первую очередь?
Главная задача хорошего бэклога — снизить уровень неопределенности и дать пользователю как можно больше ценности за меньшее время. Главное здесь — не ставить на первый план только цифры. Иначе за год у вас не появится ничего, кроме бэклога, если продукт большой и сложный. А через год бэклог уже устареет.
Раньше я использовал классическую ICE-методику, но в Тинькофф пришлось ее адаптировать. Сейчас расскажу как.
