Сейчас, перед релизом 3-й части Diablo, в сети начали всплывать интересные материалы.

Один из таких материалов — это постмортем Diablo 2 от 2000 года. Желающие могут его изучить.

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

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

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

Именно так выглядит Data Mining в клиентской аналитике. И именно так это уже работает на практике в сотнях крупных компаний по всему миру и в нашей стране.

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

Внимание! Данная статья рассчитана на людей, имеющих представление о том, что такое инспекции кода, и желающих внедрить эту методику в своей компании.


Когда мы начинали заниматься процессом внедрения инспекций кода (code review) в своих проектах, то были неприятно удивлены отсутствием толковых материалов по организации этого процесса с нуля. Еще один крайне скудно освещенный аспект — это масштабирование процесса инспекций.

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

Итак, начнем.

Когда я вижу друзей, которые вкалывают в два раза больше, а зарабатывают в четыре раза меньше, каждый раз начинается разговор:
— А ты бы не хотел поработать программистом? Ты же реально умный. Может ты просто не на своем месте?

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

Здравствуйте.
Еще осенью на 2 курсе в качестве лабораторной работы по «Теории автоматов» преподаватель на ходу придумывал нам задания, ориентируяюсь на наши пожелания в оценке. В основном это были игры. Кому-то достался хоккей, кому-то теннис, мне же досталась не столь известная логическая игра «Быки и коровы».

Процесс выката новых версий ETL на продуктив всегда процесс волнующий. Редко когда среда разработки полностью соответствует среде эксплуатации, в моем предыдущем проекте различались в том числе ОС и железо, на которых велась разработка и эксплуатация ХД.

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

После такого сравнения и унификации многие, зачастую неожиданные, проблемы при деплое должны будут найтись немного раньше, на этапе тестирования, т.е. при деплое с ДЕВа на СИТ. А определенное количество устаревших маппингов OWB или таблиц можно будет удалить с ПРОД системы.

Возможности сравнения нескольких БД присутствуют в некоторых утилитах разработки и администрирования БД, в частности данный набор скриптов получен из Toad. Мой коллега просто выбрал необходимые параметры для сравнения, которых, я думаю, будет достаточно для начала и вам, а уж если вы используете кластеризацию таблиц или что-то более сложное добавить вывод этих объектов для сравнительного анализа сможете сами.

Сформированные файлы (db_info.txt с ДЕВа и такой же с ПРОДа) можно, в дальнейшем, сравнивать утилитами типа WinDiff и решить, где значение вернее и какое из них оставить.

Автор оригинальной статьи — Майкл Эбраш, человек и пароход. Для тех, кому лень изучать википедию, отмечу, что это программист с более чем 30-летним стажем работы, который в свое время помог Кармаку сделать Quake, разработал GDI для Windows NT, приложил руку к созданию первых двух версий Xbox, а сейчас работает в R&D-отделе компании Valve.
В своей заметке он вспоминает, как зарождалась индустрия 3D-игр вообще и Valve в частности, рассказывает про свой опыт работы в различных корпорациях, приоткрывает завесу внутренней кухни Valve и ищет новых сотрудников. Статья большая, и я посчитал ее достаточно интересной для того, чтобы перевести на хабр.

---

Всё началось с Лавины*.

Если бы я не прочел её и не влюбился в идею Метавселенной, если бы она не заставила меня представить, насколько распределенная 3D сеть близка к воплощению в жизнь, если бы я не подумал я могу сделать это и, что более важно, я хочу сделать это, я бы никогда не встал на путь, который в конечном счете привел меня в Valve.

В 1994 году я уже несколько лет как работал на Microsoft. Однажды вечером, когда моя дочка рассматривала книги в магазине Little Professor в Sammamish Plateau, мне посчастливилось заметить Лавину на полке. Я взял книжку, прочитал первые страницы, решил купить и в итоге проглотил её за день. Параллельно я начал задумываться о том, что 80 процентов описанного в ней осуществимо прямо сейчас, и мне захотелось реализовать это сильнее, чем когда-либо вообще хотелось сделать что-то с компьютером — я всю жизнь читал научную фантастику, и вдруг мне выпал шанс превратить её в реальность. Так я попытался начать в Microsoft проект по созданию технологии сетевого 3D.