Единая фронтальная система сбербанк

Заказчики: Сбербанк

Технология: ИТ-аутсорсинг

подрядчики – 498 проекты – 1511

системы – 75 вендоры – 66

Содержание

Команда проекта со стороны Заказчика	Интегратора-Консультанта
не указана

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

2018: Результаты разработки за год

В 2018 году были усовершенствованы архитектура ЕФС, процессы разработки и вывода функционала в промышленную среду, сообщил Сбербанк в отчете о своей деятельности за 2 квартал 2019 года. Также была внедрена возможность многоверсионности, благодаря которой технологические сервисы и клиентский функционал могут развиваться независимо и итерационно в собственных релизных циклах.

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

Еще одним ключевым событием в области ЕФС Сбербанк называет начало этапа массового тиража системы на всех клиентов в трех каналах дистанционного банковского обслуживания в 2018 году.

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

2017: Новая версия ЕФС

В 2017 году была разработана новая версия платформы ЕФС 7.0 с более высоким уровнем надежности и производительности за счет поддержки режима развертывания в многоблочной архитектуре и режима Stand-In, обеспечивающего повышение отказоустойчивости и бесшовное обновление функциональных подсистем платформы. Также было начато массовое внедрение нового целевого процесса разработки ЕФС с использованием «инструментальных средств разработки. В Сбербанке поясняют, что это позволит одной команде реализовывать решения для всех каналов, максимально переиспользовать уже реализованные объекты и сервисы, уменьшить число ошибок за счет авто-генерации типовых функциональных блоков, а также сократить время обучения новых сотрудников.

Ожидаемый эффект от внедрения целевого процесса разработки ЕФС – сокращение объема ручной разработки в два раза.

Практики DevOps были внедрены для всех приложений ЕФС. Использование DevOps сокращает время на обновление приложений и позволяет избежать ошибок ручной установки параметров. Покрытие кода автоматическими модульными тестами достигло 80%, что привело к снижению количества ошибок на этапе тестирования в два раза, заявляет Сбербанк.

Кроме этого, в 2017 году банк определил стандарт качества платформы ЕФС. Его выполнение контролируется по 12 метрикам. Использование стандарта вдвое сократило количество ошибок на этапе тестирования и позволило добиться того, что 50% ошибок устраняются в течение 8 часов.

2016: Определены разработчики Единой фронтальной системы Сбербанка

В мае 2016 года Сбербанк определил подрядчиков по созданию "Единой фронтальной системы" (ЕФС), которая позиционируется как новая платформа трансформации банковского бизнеса [1] .

Компания "Техносерв Консалтинг" выбрана разработчиком фронтальной системы для блоков «Розничный бизнес» и «Управление благосостоянием», AT Consulting – для блоков «Корпоративный бизнес» и «CIB».

Максимальная цена первого лота составляла 297 млн рублей, "Техносерв Консалтинг" предложила выполнить работы за 178,2 млн рублей.

Второй лот был оценен в 198 млн рублей. Сумма, за которую согласилась выполнить работу AT Consulting, составила 131,5 млн рублей.

Генеральным подрядчиком Сбербанка по созданию Единой фронтальной системы является компания "Сбербанк-Технологии".

К участию в закупке были приглашены компании, имеющие опыт реализации не менее трех проектов по разработке фронтальных систем в период с 2013 г. (при этом пользовательская аудитория проекта должна составлять не менее 10 000 пользователей). Участники конкурса должны иметь не менее 40 разработчиков со знаниями языка программирования Java, 20 системных аналитиков, 20 разработчиков со знанием языка программирования JavaScript, css, html и 5 архитекторов. Специалисты проектной команды участника должны обладать сертификатами Java Senior Specialist (не менее 10 специалистов) и Oracle Professional (не менее 1).

Отдельно в документации оговаривались максимальные ставки специалистов:

№ п/п Роль в проекте Стоимость оплаты чел./дня специалистов, руб. без НДС Стоимость оплаты чел./дня специалистов, руб. с НДС 1 Главный разработчик не более 18 980,00 не более 22 396,40 2 Ведущий аналитик/разработчик не более 14 440,00 не более 17 039,20 3 Ведущий аналитик/Бизнес-аналитик не более 14 440,00 не более 17 039,20 4 Аналитик/разработчик не более 10 690,00 не более 12 614,20 5 Ведущий разработчик (Java Script) не более 10 690,00 не более 12 614,20

Общая оценка заявки участников зависела на 50% от предложенной стоимости выполнения работ и на 50% от качества выполнения тестового задания.

Задачи системы

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

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

Еще одна задача ЕФС – ускорить вывод на рынок новых продуктов банка. В нынешних условиях, когда за управление интернет- и мобильным банком, процессингом, банкоматами, терминалами отвечают разные приложения, обновление услуг и продуктов Сбербанка (например, изменение ставки по вкладу) по всей стране может занимать несколько недель. Цель – сократить сроки до одного дня.

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

Руководство программы ЕФС

В конце 2018 года руководителем программы «Единая фронтальная система» стал Алексей Поддубный. По информации TAdviser, он был назначен на эту должность после того, как из Сбербанка ушла Елена Батурова, которая ранее руководила проектом ЕФС, а также Вадим Шаробаев, который под ее руководством отвечал за этот проект в Сбертехе. Подробнее здесь.

В этой статье мы расскажем о библиотеке компонентов Единой фронтальной системы (ЕФС) и как в целом устроен фронтенд платформы.

Одной из основных задач программы ЕФС является трансформация всех фронтальных систем к единому технологическому стеку. Фронтальная система в нашем контексте это интерфейс, через который любой пользователь взаимодействует с банком. Это может быть интернет-банк — многим известны приложения Сбербанк Онлайн и Сбербанк Онлайн для бизнеса, — банкоматы, терминалы, интерфейсы операторов в отделениях и call-центрах и другие системы, которыми пользуются многие тысячи клиентов и сотрудников банка в России.

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

Очевидно, что это неудобно для всех: для клиентов, сотрудников и банка в целом.
Поэтому главная миссия фронтенда ЕФС – заменить существующую сборную солянку и привести все к единой кодовой базе, к единому технологическому стеку с удобным и понятным пользовательским сценарием.

Какие задачи стоят перед разработкой?

Надежность и безопасность, ведь мы говорим о банковском ПО.

Отказоустойчивость. Здесь фигурирует такая цифра, как 99,99%, это примерно 52 минуты в год, когда мы можем приостановить работу системы.

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

Быстрота работы и внедрения, так называемый time-to-market.

До эры ЕФС время вывода нового технического продукта на рынок могло составлять до 1 года. С ЕФС мы ставим себе задачу сократить time-to-market до 1 месяца.
И это только начало!

Как устроен фронтенд в ЕФС?

У нас есть команда разработчиков платформы ЕФС, а также прикладные разработчики, задача которых – реализовать бизнес-логику.

Команда платформы разрабатывает библиотеку UI-компонентов для внутреннего использования. Примеров подобной разработки довольно много — у таких компаний, как Google, Yandex, Avito, Mail.ru и др. также есть библиотеки компонентов. Команды же прикладных проектов используют эту библиотеку для реализации своих проектов, предоставляя фидбек в случае проблем.
В команде платформы сейчас 8 человек. Мы работаем двухнедельными спринтами, в конце каждого из них выпускаем новую версию библиотеки, в которой содержатся фиксы и, возможно, новые компоненты. У нас, разумеется, есть code review, свой code style – мы взяли лучшие практики программирования и адаптировали их под себя.

В качестве инструментария мы используем набор инструментов от компании Atlassian: JIRA для постановки задач, BitBucket для git-репозиториев и Confluence для документации.

Из чего состоит библиотека?

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

Способы вывода информации, например, таблицы или панели с кнопками и заголовками

Сетка. Мы посмотрели, как ее реализовал Bootstrap, а затем создали подобное для своих целей. По нашей сетке компоненты строятся на формах.

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

Компонент загрузки файлов

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

Поддержка браузеров

Целевыми браузерами являются IE8+. Сейчас IE8, если кто-то помнит, это как в свое время был IE6: ужасное API и ужасная отладка. Конечно, время, проведенное за дебагом в IE8, бесценно. Были случаи, когда разработчики проводили несколько дней в попытках найти, в каком месте возникала ошибка, потому что в IE8 очень скудный инструментарий для дебага и он показывает порой, что ошибка возникла совсем в другом месте.

Поддержка IE не случайна, нам приходится работать с железом из браузера: RFID-таблетки, различные принтеры, сканеры и т.д. В вебе нет единого стандарта по работе с железом: в далеком прошлом технологией для работы с ним был выбран ActiveX. Количество ПО, написанного с использованием ActiveX, колоссально, и это не дает нам в одночасье отказаться от поддержки IE и перейти в сторону современных браузеров. В планах — перевод устаревшего ActiveX на Java-апплеты и отказ от IE8.

Стек технологий

Мы своего рода стартап внутри крупной организации и наш стек технологий фронтенда не сильно отличается от большинства мировых стартапов: react, redux и PostCSS. Все эти технологии зарекомендовали себя с лучшей стороны, к тому же, они позволяют нам поддерживать IE8. Однако, мы не можем резко менять стек технологий, т.к. вокруг него завязана определенная архитектура приложений, например, именно React позволил нам разбить одно огромное приложение на сотни маленьких и подгружать их по требованию, используя SystemJS.

React

Это первая технология, которую мы выбрали по следующим причинам:

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

Легок в изучении — мы не требуем от нового коллеги, чтобы он знал React, мы просто даем ему пару дней разобраться в проекте.

Поддержка IE8. С этого, на самом деле, можно было начинать, т.к., если посмотреть, какие фрэймворки и библиотеки поддерживают IE8, окажется, что таких крайне мало. Самые популярные — Angular, Ember, Vue.js — его не поддерживают, поэтому с React нам повезло.

Также в процессе разработки мы начали экспериментировать с React Native, что позволило нам выпустить кросс-платформенную библиотеку UI-компонентов. Прочитать об этом вы сможете в нашей первой статье.

Как мы подружили React и IE8 ?

Во-первых, мы не обновляем версию React, потому что с какого-то момента они тоже отказались от поддержки IE8. Во-вторых, мы используем es3ify — это loader для webpack, который берет наш ES5 код и перегоняет в ES3. Он просто заменяет некоторые вещи, которые в IE8 не работают.

TypeScript

Второй технологией, которую мы выбрали, был TypeScript, вот почему:

Строгая типизация
По нашим стандартам тип any запрещен, однако, бывают исключения из правил, т.к. далеко не всё можно покрыть generic’ами.

Защита от дурака
Все мы люди и иногда используем не те типы, передаем не те данные, и компилятор выводит простые и понятные ошибки.

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

Сейчас в библиотеке порядка 70 компонентов. Когда мы только начинали разработку, у нас все компоненты были «умные», то есть содержали state и вся логика была внутри. Особых проблем мы не испытывали. Но, как только компоненты стали сложнее, они начали вкладываться друг в друга, их стало много, мы поняли, что все-таки у нас есть проблемы с производительностью, расскажем, как мы их решали.

Производительность

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

Есть библиотечный компонент Input, у него в state хранится value, в render он возвращает input и в onChange он меняет state. Не много ли кода для такого компонента? Однозначно много, давайте отрефакторим этот пример:

Код компонента стал короче, а на уровне выше есть компонент Form, который сам решает, как управлять состоянием компонента: через redux или через простейший setState. Input стал проще, и, соответственно, производительнее.

Второе, мы придерживаемся архитектуры чистых компонентов (PureComponent), т.е. все внешние свойства, внутренний state и контекст проходят проверку соответствия предыдущему состояния. Если состояние не изменилось, то нет смысла вызывать render лишний раз. Эту проверку мы осуществляем в методе shouldComponentUpdate, который добавили во все наши компоненты.

И третье, мы избавились от утечек памяти в коллбеках.

В данном примере у компонента есть коллбек onClick и в него передается стрелочная функция.
Если ее так задать, то здесь возникает утечка. В IE8 ее особенно видно, потому что при каждом повторном вызове render эта функция создается, она накапливается и возникают тормоза в компоненте. Немного изменим наш пример:

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

В планах на будущее — прекращение поддержки IЕ8, что позволит использовать более прогрессивные фронтенд-технологии. Кроме того, мы уже приступили к работе над масштабным проектом интеграции с мобильной платформой ЕФС, приступили к разработке гибридной библиотеки, позволяющая один и тот же код использовать и для web, и для мобильных устройств, используя React Native.

В следующий статье про фронтенд программы ЕФС мы расскажем про то, как мы используем Redux и как он стал сердцем нашей архитектуры, подписывайтесь на наш блог, чтобы не пропустить!

Идеи, предложения и пожелания – пишите, будем рады пообщаться с вами в комментариях к статье.

Компания

Профиль

Блог 161

Новости

Вакансии 24

Подписчики 8,5k

Сотрудники 128

• Rybolos 16 октября 2019 в 14:52

Sberbank AI Journey. Как мы учили нейросеть сдавать экзамен

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

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

Кто ты без своего кода: киберпанк-тест

Вакансии компании Сбербанк

Тест к празднику: а ты правда тестировщик?

DzyubenkoVS 6 августа 2019 в 09:53

Как мы организовали первый электронный лизинг и к чему это привело

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

Чем сложнее сделка, тем меньше вероятность того, что ее удастся провести в рамках ЭДО. Например, лизинговая сделка сложна тем, что в ней как минимум участвуют три стороны — банк, лизингополучатель и поставщик. К ним часто прибавляются еще поручитель и залогодатель. Мы решили, что и такие сделки можно полностью оцифровать, для чего создали систему E-Leasing — первый в России сервис, который полностью обеспечивает ЭДО в подобных сценариях. В итоге на начало июля 2019 года через E-Leasing проходит 37% от общего количества заключаемых по лизингу сделок. Под катом мы разберем E-Leasing с точки зрения функциональности и технической реализации.

Как мы внедрили ML в приложение с почти 50 миллионами пользователей. Опыт Сбера

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

Дизайн главного экрана мобильного приложения с рекомендациями

У нас было 2 сотни тысяч возможных вариантов платежей, 55 миллионов клиентов, 5 различных банковских источников, полсолонки разработчиков и гора банковской активности, алгоритмов и всего такого, всех цветов, а ещё литр рандомных сидов, ящик гиперпараметров, пол-литра поправочных коэффициентов и две дюжины библиотек. Не то чтобы это всё было нужно в работе, но раз начал улучшать жизнь клиентов, то иди в своём увлечении до конца. Под катом история о сражении за UX, о правильной постановке задачи, о борьбе с размерностью данных, о вкладе в open-source и наших результатах.

regno 17 июля 2019 в 09:38

Custom refactoring tool: Swift

Любой инженер стремится сделать процесс своей работы максимально оптимизированным. Нам, как мобильным разработчикам iOS, очень часто приходится работать с однообразными структурами языка. Компания Apple улучшает инструменты разработчиков, прилагая много усилий, чтобы нам было удобно программировать: подсветка языка, автодополнение методов и многие другие возможности IDE позволяют нашим пальцам успевать за идеями в голове.

Что делает инженер, когда необходимый инструмент отсутствует? Верно, сделает всё сам! Ранее мы уже рассказывали о создании своих кастомных инструментов, теперь поговорим о том, как модифицировать Xcode и заставить его работать по твоим правилам.

Зачем мы делаем Enterprise Service Mesh

Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.

erarkh 15 июня 2019 в 09:00

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

Роботы уже перестали быть героями фантастических фильмов и много лет живут среди нас. Просто мы не всегда это замечаем.

Однако задач, которые мы готовы отдавать в их металлические (или пластиковые) «руки», все больше. В результате растет эффективность многих процессов, а вместе с этим появляются и страхи сокращения рабочих мест. По прогнозам McKinsey Global Institute, уже к 2025 году «вооруженные искусственным интеллектом» роботы могут заменить до 100 млн работников.

Fraiman 5 июня 2019 в 09:00

Оружие осторожного инвестора: считаем справедливую стоимость инвестиционных облигаций

Привет, Хабр! Сегодня мы хотим поднять довольно нестандартную для блога тема — инвестиционные облигации. Почему мы решили об этом написать? Тема структурных финансовых продуктов, к которым относятся инвестиционные облигации, в последнее время становится все популярнее, а понятной информации о том, что это и как работает такой инструмент, крайне мало. Заинтересовались? Добро пожаловать под кат.

Fraiman 28 мая 2019 в 09:26

Практика разработки в крупных проектах: митап SberPractice iOS #1

Друзья, вечером 30-го мая мы, команда DevTeam «Сбербанк Онлайн», проводим бесплатный митап по iOS, где выступят парни из Вконтакте и EPAM Systems, а также пройдет круглый стол с представителями Сбербанка, Авито, Mail.ru и «Лаборатории Касперского», на котором обсудим организацию процесса мобильной разработки и много того, что наболело и за что хочется похоливарить. Задавать вопросы коллегам смогут все желающие, а равно как и активно дискутировать.

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

Зарегистрироваться на митап можно здесь, а если мы вас пока не убедили — добро пожаловать под кат.

DzyubenkoVS 21 мая 2019 в 09:00

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

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

Готового решения, которое могло решить все три проблемы, на рынке не существовало, так что мы начали работу над собственным проектом «Электронный DOC.офис». О том, что получилось, расскажем в этом посте.

Custom instruments: когда signpost недостаточно

Instruments для Xcode компании Apple — это инструменты для анализа производительности iOS-приложения. Их используют для сбора и отображения данных, которые необходимы в отладке кода. В прошлом году Apple презентовала Custom Instruments. Это возможность расширить стандартный набор инструментов для профилирования приложений. Когда существующих инструментов недостаточно, вы сможете самостоятельно создать новые — они соберут, проанализируют и отобразят данные так, как вам потребуется.

Прошел год, а новых публичных инструментов и информации по их созданию в сети почти нет. Так что мы решили исправить ситуацию и поделиться тем, как создавали собственный Custom Instrument, который определяет причину слабой изоляции unit-тестов. Он базируется на технологии signpost (мы писали о ней в предыдущей статье) и позволяет быстро и точно определять место возникновения мигания теста.

Robot Operating System Meetup Russian 2019

В мире робототехники давно и успешно развивается программный фреймворк, позволяющий быстро прототипировать робототехнические системы — Robot Operating System (ROS). Мы в Лаборатории робототехники Сбербанка активно применяем его в разработке собственных проектов. Накопив определенный опыт и заметив, что в России еще не проходило ни одного практического митапа по ROS, мы решили его организовать и поделиться знаниями, а заодно познакомиться c сообществом робототехников. Уже 16 апреля в Сколково в рамках Форума Skolkovo Robotics 2019 пройдет ROS Russian Meetup 2019 – это возможность для разработчиков ROS и робототехников всех уровней посвятить один день живому обмену опытом и общению с сообществом. Если вы знакомы с ROS, то можно смело переходить на форму регистрации, там же размещена программа и организационная информация. На митапе мы обсудим историю ROS и принципы сообщества, уделим много времени практическим докладам про SLAM и навигацию по лазерному лидару внутри помещений, про планировщик пути робота. Покажем как управлять промышленными манипуляторами через ROS, как использовать данные сенсоров, как работать с машиной состояний SMACH. И даже расскажем, как без проблем установить себе ROS и начать разработку робота.
Кстати, участие в митапе бесплатное, но поскольку количество мест ограничено, то мы просим дождаться подтверждения. А для тех, кто не знаком с ROS, предлагаем небольшой обзор.

Ignite Service Gr >

26 февраля мы проводили митап Apache Ignite GreenSource, где выступали контрибьютеры open source проекта Apache Ignite. Важным событием в жизни этого сообщества стала перестройка компонента Ignite Service Grid, который позволяет развернуть пользовательские микросервисы прямо в кластере Ignite. Об этом непростом процессе на митапе рассказал Вячеслав Дарадур, старший разработчик Яндекса и уже более двух лет контрибьютер Apache Ignite.

erarkh 4 апреля 2019 в 08:00

ИИ, школьник и большие призовые: как в 8 классе заняться machine learning

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

Простой пример – прошлогодний хакатон Академии искусственного интеллекта для школьников. Его участникам нужно было предсказать исход игры Dota 2. Победителем соревнования тогда стал Александр Мамаев — десятиклассник из Челябинска. Его алгоритм точнее всего определил команду победителя схватки. Благодаря этому Александр получил солидные призовые — 100 тыс. рублей.

Как стать коммиттером и действительно ли вам это нужно

Привет! Меня зовут Дмитрий Павлов, я работаю в GridGain, а также являюсь коммиттером и участником PMC в Apache Ignite и контрибьютором в Apache Training. Недавно я выступал c докладом о работе коммиттера на митапе Сбербанка по open source. С развитием opensource-сообщества у многих все чаще стали возникать вопросы: как стать коммиттером, какие задачи брать и сколько строчек кода надо написать, чтобы получить эту роль. Когда мы думаем о коммиттерах, нам сразу представляются всемогущие и всезнающие люди с короной на голове и томиком «Чистый код» вместо скипетра. Так ли это? В своем посте я постараюсь ответить на все важные вопросы о коммиттерах, чтобы вы могли понять, действительно ли вам это нужно.

Code review: вредные советы для контрибьютера и ревьювера

Привет! Меня зовут Николай Ижиков. В этом посте я хочу рассказать об одном важном элементе взаимодействия, с которым мы сталкиваемся в процессе разработки ПО, особенно в open source. Это прохождение и проведение code review.

Тестирование на примере ReactJS: насколько глубока кроличья нора

Всем привет, меня зовут Ярослав Астафьев, и сегодня я хотел бы провести обзорную экскурсию в тестирование ReactJS. Я не буду углубляться в сложности тестирования веб приложений с использованием определенных библиотек (руководствуясь подходом «сложно тестировать только плохой код»), взамен постараюсь разнообразить ваш кругозор. Так что в этой статье React — скорее повод собрать воедино подходы к тестированию, отправная точка, объединяющая хипстеров и технологии. Корректнее будет даже сказать, что речь пойдет о принципах тестирования вообще с иллюстрациями на ReactJS (и не только).

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

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

regno 14 марта 2019 в 09:15

Signpost: когда брейкпоинтов недостаточно

В предыдущей статье мы узнали о причинах нестабильности unit-тестов и способах борьбы с этим. Теперь мы хотим рассмотреть один из новых инструментов Apple для отладки и профилирования кода. Речь о представленном на WWDC 2018 фреймворке для логирования os_log, который был расширен инструментом для анализа производительности — os_signpost.

В одном из спринтов нам поставили задачу реализовать генерацию pdf-документа на client-side. Мы выполнили задачу и успешно продемонстрировали результаты команде. Но нам захотелось убедиться в эффективности технических нюансов принятого решения. В этом нам помог signpost. С ним нам удалось ускорить отображение документа в несколько раз.

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

olegabu 6 марта 2019 в 08:00

Блокчейн без посредников: как мы отправили ценные бумаги в распределенный реестр

Вся экономическая деятельность исторически построена на посредниках. Любая, даже несложная сделка между двумя сторонами сопровождается привлечением разнообразных посредников — банки, биржи, клиринговые палаты и т.д. Исключение посредников, возможно, сделало бы взаимодействие более эффективным. Так почему бы не попробовать построить на базе блокчейна новую, децентрализованную инфраструктуру, где участники сделки могут работать напрямую? В этом посте мы расскажем о том, как начали путь к такой инфраструктуре: развивали у себя блокчейн-сделки и в итоге провели РЕПО — займ денег под обеспечение ценными бумагами.