Новое будущее, картину которого мы описали в предыдущей статье о подключении человека к Интернету по предположению ряда исследователей ожидает человечество в ближайшие 20 лет. В чём в целом вектор развития человечества?
Значительные финансовые потоки вкладывают в развитие качества жизни человека. Основные источники ухудшения качества жизни в целом — это всевозможные заболевания и смертность. Работа над решением этих проблем идёт по семи главным направлениям:
«Ученый может открыть новую звезду, но не может создать её. Для этого ему пришлось бы обратиться к инженеру». Гордон Линдсей Глегг, «Дизайн дизайна» (1969)
Несколько месяцев назад я писал о различиях между специалистами по теории и методам анализа данных (data scientist) и специалистами по обработке данных (data engineer). Я говорил об их навыках и общих отправных точках. Произошло кое-что интересное: data scientist'ы начали наступать, утверждая, что они на самом деле так же компетентны в области инженерии данных, как и специалисты по обработке данных. Это было интересно, потому что специалисты по обработке данных не высказывали возражений и не говорили, что они являются специалистами по теории анализа данных.
Поэтому последние несколько месяцев я занимался сбором информации и наблюдением за поведением специалистов по теории анализа данных в их естественной рабочей среде. В этом посте я подробнее расскажу о том, почему data scientist не является data engineer'ом.
В этой статье я расскажу о нескольких ошибках, которые я допустил, взяв один проект на управление, что привело к не самым лучшим последствиям. Так же я озвучу свои рекомендации, как уйти от рисков репутационных и финансовых потерь. Для опытного и даже неопытного менеджера озвученные мною вещи выглядят вполне очевидными. И всё же вижу, что я не первый и не последний, кто наступает на грабли.
Каждый в IT-индустрии знает, насколько сложно оценить срок выполнения проекта. Трудно объективно оценить, сколько времени займёт решение трудной задачи. Одна из моих любимых теорий заключается в том, что здесь имеет место просто статистический артефакт.
Предположим, вы оцениваете проект в 1 неделю. Предположим, есть три одинаково вероятных результата: либо он займёт 1/2 недели, либо 1 неделю, либо 2 недели. Медианный результат фактически такой же, как и оценка: 1 неделя, но среднее значение (aka average, aka expected value) составляет 7/6 = 1,17 недель. Оценка фактически откалибрована (беспристрастна) для медианы (которая равна 1), но не для среднего.
В данной статье мы рассмотрим, как можно в одном потоке обрабатывать другой, для чего это нужно, и как нам в этом помогут операторы Higher Order Observables (дальше HOO).
Серия статей «Основы реактивного программирования с использованием RxJS»:
При работе с потоками часто возникает ситуация, когда необходимо в качестве значения одному потоку передать результаты работы другого. Например, мы хотим выполнить ajax запрос и его ответ обработать в текущем потоке, или запустить несколько параллельных запросов, реализовать pooling. Думаю, многие привыкли решать подобные задачи, используя такой механизм как promise. Но можно ли решать их используя RxJS? Конечно, и все куда проще чем вы думаете!
