Общепринятый и проверенный временем подход к построению Data Warehouse (DWH) — это схема «Звезда» или «Снежинка». Такой подход каноничен, фундаментален, вотрфоллен и совсем не отвечает той гибкости, к которой призывает Agile. Чтобы сделать структуру DWH гибкой, существуют современные подходы к проектированию: Data Vault и Anchor modeling — похожие и разные одновременно. Задавшись вопросом, какую из двух методологий выбрать, мы в Яндекс Go пришли к неожиданному ответу: выбирать надо не между подходами, а лучшее из двух подходов.

Темы доклада, который вместе со мной прочитал Николай Гребенщиков:
— DV и AM: в чем разница и где точки соприкосновения
— Гибридный подход к построению хранилища
— Сильные и слабые стороны этого подхода
— Примеры кода
— Дальнейший вектор развития hNhM

— Меня зовут Евгений Ермаков, я руководитель Data Warehouse в Яндекс Go.

Как правило, программисты хотят минимизировать время выполнения кода. Но в 1962 году венгерский математик Тибор Радо поставил противоположную задачу. Он задался вопросом: как долго может выполняться простая компьютерная программа, прежде чем она закончит работу? Радо назвал эти максимально неэффективные, но все же функциональные программы «усердными бобрами».

Поиск таких программ — жутко отвлекающая головоломка для программистов и других любителей математики с тех пор, как она была обнародована в колонке Computer Recreations в журнале Scientific American в 1984 году. Но за последние несколько лет игра в усердного бобра, как её называют, сама по себе стала объектом изучения, поскольку она связана с самыми возвышенными понятиями и открытыми проблемами в математике.

Цель игры «Усердный бобёр» — найти компьютерную программу, которая работает максимально долго. Её поиски удивительным образом связаны с некоторыми глубочайшими вопросами и понятиями в математике.

В свое время из-за немного громоздкой политики по выпуску обновлений для Microsoft SQL Server путался какой же из дистриубтивов нужно установить и откуда его скачать. Углубившись в данную тематику, в интернете нашел замечательные систематизирующие ресусры, которые отвечали на мои вопросы (они приведены в начале статьи).

Надеюсь собранная информация будет полезна не только мне.

Во время общения с медиа мы в Relap.io часто сталкиваемся с массой заблуждений, в которые все верят, потому что так сложилось исторически. На сайте есть блоки типа «Читать также» или «Самое горячее» и т.п. Словом, всё то, что составляет обвязку статьи и стремится дополнить UX дорогого читателя. Мы расскажем, какие заблуждения есть у СМИ, которые делают контентные рекомендации, и развеем их цифрами.
 

 
 

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

Неприятности случаются… Неожиданно плохой фидбек, проблемы с заказчиком или коллегами, не повысили зарплату, странные баги, внезапный овертайм или закрытие проекта — подобные события запускают цепочку реактивных реакций:

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

В этой цепочке человек ведет себя реактивно, предсказуемо… и, часто, совершает глупости. Это напоминает машину состояний, входом в которую являются неожиданное событие. Состояния машины — цепочка психологических защит: отрицание, гнев, торг и депрессия, а выход — принятие новой информации.
Из подобных состояний часто приходится вытаскивать коллег, заказчиков, и себя самого.
Под хабракатом, кроме описания этапов, есть ответы на вопросы:

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

На конференции NDC 2013, недавно прошедшей в Лондоне, Мадс Торгерсен (Mads Torgersen), являющийся одним из разработчиков спецификации языка C#, рассказал в своём докладе “The Future of C#” о возможных нововведениях в нём.