Всем привет! На этой неделе с вами @alexkorotkikh из пасмурного Гамбурга. Я работаю в компании @Kreditech на позиции VP Engineering

Я бы хотел поговорить про: работу зарубежом; о финтеке вообще и что это значит для разработчиков в частности;

о том, как отличается работа в компании из 5 человек, 50 и 350, даже если это одна и та же комания :)

Из технических тем интересно обсудить где место RDBMS в мире, захваченом NoSQL, и нужны ли ORM'ы

Напишите, плиз, на какие ещё темы хочеться поговорить вам, а я пока на митинг убежал :)

Раз уж тема БД так всем понравилась, давайте начнём с неё. Кстати, а какую БД используете вы на текущем проекте, и сколько там данных?

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

На тему выбора БД в зависимости от проекта мне нравится статья medium.baqend.com/nosql-database… и короткий алгоритм из неё cdn-images-1.medium.com/max/2000/1*qP4…

У нас в качестве основной БД используется PostgreSQL, и за 5 лет работы с ним я влюбляюсь всё больше и больше.

Отдельно приятно, что разработка идёт очень активно, мажорные релизы примерно раз в год (имхо 9.5 > 9.6 в случае постгреса - мажорный релиз)

практики code review, и весь код by default считается хорошим. Не уверен, что это хорошая практика, но возможно некоторым командам так проще

В данном случае я бы сел вмечте с автором кода и тем, кто будет рефакторить, и постарался конструктивно обсудить спорные места.

Кстати, в данном случае ревью - это частный случай performance feedback, который тоже желательно чтобы был регулярный, и тогда =>

такой проблемы - обиды - быть не должно. Отличной практикой при подаче фидбека есть "правило бургера" - фидбек начинается И заканчивается =>

в положительном ключе, а критика идёт по середине (конструктивная конечно). Мол, ты очень круто запилил фичу в последнем спринте, молодец =>

только мне кажется что вот тут и тут можно зарефакторить, чтобы перформанс улучшить и читабельность. А вообще круто что ты такую фичу =>

сдал в срок, заказчик очень доволен.

Возвращаясь к постгресу - например, в 9.6 запилили parallel seq scan postgresql.org/docs/9.6/stati… Мы конечно сек сканы не любим, и про индексы =>

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

Чуть не забыл - хорошая стать про культуру code review hypothes.is/blog/code-revi…

При удаче, через пару таких просьб начинание подхватит ещё пару человек, и так оно может разойтись по команде "само".

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

@backendsecret вот здесь подробней и с важными уточнениями: infoq.com/presentations/…

Если кода много, то большинство, в лучшем случае, просмотрит "по диагонале" и укажет на опечатки и ошибки стиля. А для этого есть линтер :)

Но вернёмся к БД. Упоминание ORM вызвало какой-то нездоровый ажиотаж. Так они нужны или нет?

Лично мне ОРМ кажется "дырявой абстракцией". Нам как бы говорят "с реляционными данными можно работакть так же как с объектами", и =>

показывают какой-то простой пример, где действительно всё просто. ПО итогу складывается впечатление что знать SQL и как работают БД =>

вроде и необязательно. А потом приходят первые сто пользователей, генерят первую 1000 записей, и те запросы, которые генерит ОРМ, кладут БД

По итогу работая с ОРМ нужно понимать и как работает база, и как работает этот конкретный ОРМ. Так зачем тогда нам лишняя абстракция?

Мы у себя по итогу остановились на ScalikeJDBC (scalikejdbc.org). Максимально простой DSL, который поверх SQL добавляет =>

только минимальную проверку типов, чтобы в маппинге глупые ошибки не допускать.

на месяцы, чтобы их исправить. Проще всего, конечно, в новый проект.

Данные тудакопируются из PostgreSQL и некоторых другиз источников, и уже BI-engineers составляют нужные вьюхи и репорты

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

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

Там, конечно, мастер ия со скала-макросами, и IDE могут сходить с ума, но всё лучше, чем в рантайме

Мастер ия = магия :) #долбанаяавтозамена

Кстати, не могу не воспользоваться положением - we’re hiring! #scala/#java, #nodejs, #devops. Релокейт в Германию :) kreditech.com/careers

@backendsecret Яндекс.Метрика решает задачу аналитики по сайтам и приложениям. В твите не опишешь. Наша статья: m.habrahabr.ru/company/yandex…

Всем доброе утро! Вопрос к аудитории - интересно ли поговорить про работу в Германии, или все и так уже подписаны на @abroadunderhood ?

Пол года назад я про работу уже рассказывал в @abroadunderhood, вот тут архив abroadunderhood.ru/alexkorotkikh/…

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

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

С другой стороны, аутсорс от продукта отличается вне зависимости от страны, кмк :)

Главное отличие - здесь очень многие ИТ компании сильно интернациональные. У нас на 200 человек в немецком офисе - около 40 национальностей

Причём немцев дай бог чтоб четверть. Инжиниринг на 70% русскоязычный, но тут своя причина - первый офис разработки был в Украине

И многие (я в том числе) переехали из того самого офиса. Он кстати до сих пор работает, разработчиков примерно пополам здесь и в Украине

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

Это потом сказывается на скоросте/простоте найма.

Учитывая немецкую программу для high-skilled migrants (blue card), компаниям не так дорого/геморно релокейтить откуда угодно, даже не из ЕС

Поэтому почти все более-менее вставшие на ноги стартапы уже открыты к relocation support, про крупные я вообще молчу, для них это копейки

а на национальность, учитывая количество мигрантов, тут не смотрят. По крайней мере, ни я, ни мои знакомые не сталкивались

Ещё несколько офферов в Берлине знаю на 80-100к. Это Senior Engineer позиции в достаточно успешных стартапах (либо profitable, =>

либо хорошо проинвестированные, со стабильными показателями роста)

Тут ещё надо понимать разницу в ценах на всё между бывш. ГДР и ФРГ. Берлин заметно дешевле, чем Гамбург, з/п соответственно

Зачем НЕ надо ехать работать в Европу? За деньгами. Тут социализм, по сути, имхо за деньгами - это в штаты (хотя и не уверен)

Зачем надо? Я ехал в первую очередь за новым жизненным опытом. В добавок получил хорошую медицину, чувство безопасности и ->

Удивительное ощущение от понимания, на что идут твои налоги :)

@backendsecret в Швейцарию: высокие ЗП и низкие налоги. Если детей нет, то денег много оставаться будет.

Не везёт мне с коллективными твиттерами. Вёл эброад - отправили в командировку, веду бэкенд - а у нас реорганизация отдела. Завал :(

И снова здравствуйте. Вроде есть немного времени, давайте расскажу немного про работу в финтехе

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

Учитывая, что мы сейчас оперируем на 5 разных рынках - у нас 5 разных регуляторов + немецкое data privacy agency, т.к. компания-то немецкая

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

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

А потом приходит госрегулятор и говорит "а почему вы не спрашиваете у своих клиентов есть ли у них или членов их семьи страховка имущества?"

а ещё ипотека, кредитные карты, другие займы и пр. Банки это спрашивают, чтобы оценить риски. Мы риски оцениваем с помощью ML, и практика =>

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

Отдельный геморой с data privacy, В отличии от многих других бизнесов, нам недостаточно минимальной информации о клиенте вроде мейла и имени

И для наших нужд, и для соблюдения законов приходится собирать много sensitive data - номер счёта, паспорта, ssn, сканы доков

Соответственно, всякие DPA нас очень не любят и регулярно приходят посмотреть, не нарушаем ли мы чего. Кто-то в запаре забыл удалить =>

логгирование номера счёта и это нашли - привет, вот штраф. Круче всего станет в EU с 2018го - новые правил (GDPR) по которым штраф может =>

достигать 4% годового ревенью (даже не профита!). Для небольших фирм это может стать смертью.

Отдельная тема - анонимизация. Если пользователь взял кредит - его данные обязаны храниться не менее 10 лет (опять же зависит от страны)

А вот если мы ему отказали, или он передумал (напр. условия не устроили) то его данные надо физически удалить. насовсем.

Что-что? у вас immutable data? CQRS? No update/delete policy? Расскажите об этом регуляторам, только сначала штраф заплатите.

Неделя вне твиттера выдалась насыщенная, писать практически не успевал, за что прл у прощения. У меня ещё есть несколько часов =>

Рад буду ответить на вопросы, если есть. Финтех, Германия, scala, нужность orm’ов ;) спрашивайте!

Ребята, мне пора прощаться. Надеюсь, кому-то понравилось и было полезно. Рад пообщаться на любые темы - @alexkorotkikh

Не могу не напомнить - @Kreditech is hiring :) если вам интересен финтех + релокейт в Европу - буду рад помочь!