Главный блог dev.by

В этом посте мы продолжаем изучать вопрос инфографики и визуализации данных. Первая часть материала лежит тут.

Самая известная гейм-девелопмент компания Беларуси второй раз за последние шесть месяцев отметилась крупной сделкой на игровом рынке, без лишнего шума и несколько неожиданно для всех купив чикагского разработчика игр Day 1 Studios, которому вскоре предстоит переименоваться в Wargaming West. В августе 2012 года, напомним, Wargaming.net приобрела австралийскую компанию BigWorld, потратив на это внушительные $45M. Сейчас сумма сделки выглядит несколько скромнее – $20M, хотя скромность может показаться излишней, когда речь идёт о десятках миллионах долларов в достаточно узкоспециализированной отрасли. Однако её воздействие на дальнейшее развитие компании обещает быть не менее, а может даже и более значительным.

В чем заключается базовая мотивация работника: желание заработать побольше денег, удовлетворение своего чувства самореализации, подчас противоречивые личные амбиции или мужское желание быть всегда первым? Ответ на этот вопрос не так однозначен, согласно канонам поведенческой психологии существует несколько устойчивых стереотипных групп движимых взаимоисключающими по отношению друг к другу мотивациями при построении своих карьерных стратегий.

Я предлагаю поближе рассмотреть эти бурлящие человеческие течения в теории и на практике, выбрав в качестве яркого иллюстративного примера - Google. С одной стороны эта поисковая компания символ офисного конформизма – туда стремятся попасть на работу тысячи молодых программистов со всего мира, с другой - интернет захлестнули множественные “открытые письма” бывших сотрудников ”империи добра”, которые покидают эту компанию с чувством глубокого разочарования.

Когда редакция Девбая готовит к выпуску материал, в котором ожидается куча статистики, различных циферок и процентов, то пытается систематизировать такую информацию удобным для понимания способом – с помощью графиков. Скромные возможности Numbers вполне подходящи в этом деле, но принятая во внимание критика жж-юзера 9zloy, более известного как Михаил Дубаков, подтолкнула нас к изучению вопроса инфографики и визуализации данных.

Уверен очень многие .Net-разработчики знают и уважают известное расширение для MS Visual Studio – ReSharper (R#). Этот продукт, созданный питерской софтверной фирмой JetBrains, сумел получить воистину мировое признание. В конце минувшего года вышла его седьмая версия, которая помимо всего прочего обеспечивает полную поддержку новой Visual Studio 2012, при этом сохраняя совместимость со старыми версиями VS. Второй важной особенностью нового ReSharper 7 стала поддержка приложений для Windows 8 и WinRT.

Вслед за 7-мой версией вскоре последовало обновление 7.1, которое привнесло огромное количество улучшений и доработок (более подробно с которыми лучше ознакомиться отдельно здесь и здесь). В связи с выходом этого важного мажорного релиза Resharper мы решили побеседовать с Сергеем Шкредовым, product manager’ом JetBrains, чтобы из “первых рук” узнать все последние новости и ближайшие перспективы в развитии этого сверхпопулярного отечественного инструмента.

Прим. ред.: мы взяли на себя смелость перевести статьо о feature toggling из цикла эссе The ThoughtWorks Anthology. 

Один из самых распространенных способов параллельной (конкурентной) разработки нескольких функций – применение при контроле версий самостоятельных функциональных веток. В каждой из таких веток конкретная функция разрабатывается отдельно от других, а потом интегрируется в основной рабочий поток, когда разработка данной функции будет завершена. Такой паттерн называется «Feature Branch» (ветвление функций), см. тут

При применении такого подхода возникает проблема: дело в том, что функциональные ветки кода, разрабатываемые в изоляции друг от друга, сравнительно редко интегрируются. При этом упускаются все преимущества, связанные с непрерывной интеграцией. Чем дольше ветка отделена от основного цикла разработки, тем более значительный риск накапливается из-за откладывания интеграции. Обычно такие проблемы проявляются при попытке интегрировать функциональную ветку в основной цикл разработки. Действительно, не кажется ли насмешкой ситуация, когда приходится сразу интегрировать все наработки, сделанные за пару месяцев?

Иногда наступает момент, когда начинаешь задавать вопрос: А как лучше хранить исходный код, чтобы он в итоге не превращался в кучу файлов с циклическими зависимостями?

Всё началось несколько лет назад, когда я решил попробовать сделать свою библиотеку. Уже тогда я попробовал Boost и его The Unit Test Framework, и начал вливаться в CMake, как для кроссплатформенности, так и для простоты перехода между компиляторами. В общем к данному времени вопрос как хранить исходные коды, файлы сборки, вспомогательные и тестовые файлы получил несколько ответов и вариантов из которых по объективным, а иногда и по соображениям удобства, был сделан выбор.