Привет, на этой неделе с вами Александр Тавген, из Тарту. В индустрии 17 лет. На данный момент Software Architect в крупной компании.

Основные интересы: Data Science, Java, Python Stack, Machine Learning, Distributed Systems. В последнее время все больше в Python экосистеме

На этой неделе хотел бы поговорить: разработка концептов, дизайн систем, ML системы, и так далее.

На этой неделе будем записывать видео, где несколько моделей нейронных сетей импровизируют вместе живыми музыкантами on-the-fly.

Две модели. Одна слушает человека, а вторая импровизацию первой.
youtu.be/rpIWMNGKqic

Оставили их как-то минут на обеде, когда вернулись уже играл какой то транс >) Звуки и уровни, еще не отстроены.
youtu.be/BQZDYHkRX94

Из ранних экспериментов.
habrahabr.ru/post/249229/

Немного музыки на селф мейд столе.
habrahabr.ru/post/249399/

Последний проект полностью Python stack, и для меня ясно, что разные инструменты предназначены для разного типа задач. Stable vs Research.

Тот же TDD не особо применим в research. Все меняется на лету, и если писать сразу тесты, то количество времени на девелопмент растет вдвое.

Отсюда и Python, и dev в Jupyter. Понимание структуры данных, после кусочки функциональности собираются в IDE. Тогда уже и тесты.

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

Если интересно, то могу рассказать об анализе time-series metrics и автоматическом детектировании проблем. bit.ly/2lp1F6h

Очень точно все написал Andrew Clegg. Кастомное и дорогое решение страдает от тех же недостатков. pic.twitter.com/L3S92Ff3pg

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

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

Экономические процессы имеют ярко выраженную регулярность. Это покупки, транзакции, логины, сессии и так далее. Это… twitter.com/i/web/status/9…

Проблема в том, что Алерты это больше чем поиск outliers. Outliers не работают. Тысячи метрик осцилируют статистически. Прорывы будут всегда

Как результат огромное число False Positives and Alert Flood. Увеличиваешь сигму и трешхолды и пропускаешь важную информацию.

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

То есть существуют два концептуально разных уровня. Один даёт информацию о нарушениях, второй принимает их и применяет некие правила.

Архитектура напрашивается сама собой. Один компонент выстреливает события. Другой из слушает, реорганизовывает и пр… twitter.com/i/web/status/9…

Rules Engine study. И ещё я люблю whiteboard documentation. Это идёт в доки. Мне самому очень помогает такое распис… twitter.com/i/web/status/9…

Если я храню все наборы events от моделей, и потом размечаю где у меня были инциденты, то decision trees алгоритм может вывести правила.

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

Есть ещё интересная математика. Как мы можем доказать, что наша модель схватила сигнал адекватно?

Сегментная регрессия. Разбиваем ряд на кусочки, интерполируем. Плюсы - малое число параметров у модели. Бритва Окка… twitter.com/i/web/status/9…

Стыки на данных. И variance в любом случае надо тоже писать. В конце видно, что ряд уходит от стационарного состоян… twitter.com/i/web/status/9…

Скользящие статистики. Moving Average and Variance. Они сдвинуты на размер окна, если брать окно и вперед и назад,… twitter.com/i/web/status/9…

Тут тестовые данные в данных bounds. Можно брать несколько недель и с разными весами высчитывать усредненные по вре… twitter.com/i/web/status/9…

Twitter Seasonal ESD. Not tuned appropriate, just test. pic.twitter.com/mOwS10LbuT

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

И итеративно иду к решению. Во всем этом итеративный процесс must be. Это похоже на поход по болоту, и прощупывание перед собой твердь.

Как вы считаете? Нужен ли банку блокчейн, как он есть? Если банк контролирует инфру, и Proof-of-Work по сути не нужен.

Если банк доверяет своей инфраструктуре, то Proof-of-Work не нужен. Это очень неэффективно греть датацентры, и медленно проводить транзакции

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

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

Графы, это прекрасная возможность переключить мышление в части persistance.

А существуют ли любители whiteboardinga? Может, его просто неправильно готовят?

У многих инженеров существуют проблемы с делегированием. Все надо сделать самому. Но это работает, только до определенного уровня. Problem.

Декомпозиция должна проводиться не только, и не сколько, на уровне кода, но и на уровне организации. На второе уделяется меньше внимания.

Софт, концептуально самое сложное, что создавало человечество. И все сводится по сути к борьбе со сложностью (помимо Business Goals)

Это все трюизмы, но бывает так например... И достаточно часто. pic.twitter.com/DDC5f3TEyF

Немного писал о теории сложности и адаптации к меняющимся условиям.
habrahabr.ru/post/327138/

Computation, which we initially described as just “what a computer does,” has turned out to be something of a force of nature. Tom Stuart.

Shortly, we can describe it like here. pic.twitter.com/SRtVD9c65w

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

Понимание математики и понимание Computer Science, в общем то, требуют похожей заточки мозгов.

Я рад, что вызвал вас на дискуссию. Уровень сложности софта в ином. Он принципиально другой...

Строя вышки, рано или поздно упрешься в физические законы. Вышки нельзя реплицировать, и так далее. Ограничения софта в ином мире.

Я не говорю про конкретный софт. Сам концепт вычислимости имеет ограничения много плана. Это как континуум сравнить со счетными множествами.

Теоретическое ограничение сложности вычислимости, задаёт совершенно иные рамки. Все остальное из этого следует.

То что мы упираемся в ограничения этого мира при постройке физических машин, это не относится к концерту вычислимости.

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

Я платонист в математике.

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

Есть даже такая шутка. Вопрос на собеседовании, чем отличается квадратичная сложность по памяти от линейной? Ничем.

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

pic.twitter.com/q3OujJxyGF

Извиняюсь, мы сегодня снимаем видео, и это будет по сути первая совместная репетиция. Немного материала постараюсь выложить.

Preparing for the shooting :) pic.twitter.com/bfcsOLClFq

pic.twitter.com/IEd0H8pKqD

Первый сет. К середине ритм более менее стабилизировался. youtu.be/cO8KhWZvxcA

facebook.com/aleksandr.zede…

You face, when you hear that, we should create own crypto-algorithm. pic.twitter.com/fQTiPhoh9Y

Только что из диалога. Когда идёт что-то не так. pic.twitter.com/2kpCGNnLsr

5 попытка. Ритм ведут две модели TensorFlow. На браузер выведены каналы MIDI, можно видеть как идет ритм. youtu.be/juRhB-f-FNA

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

Очень полезная штука, подписка Safari на O’Reilly. Это как Spotify в мире книг. Плюс доступ к обучающим видео. Требуйте в своих компаниях.

Правильное кафе в Хельсинки. pic.twitter.com/spZ4gq4efw

Монтаж с раб моментами. Две сети ведут ритм, после примеров. youtu.be/oj0u-WOqtdU

Спасибо за внимание. Это был интересный опыт. Низкий поклон .