Здарова! Короче, последнее время на хабре было много срачей вокруг Go: хороший-плохой, нужен-ненужен, много сравнивали с питоном, много сравнивали с растом, divan0 даже додумался перевести высер «Go vs Haskell» ну и в таком ключе. У меня сложилось ощущение, что из-за хайпа и агрессивного маркетинга языка некоторыми Иванами Данилюками очень мало кто понял, кому и зачем вообще Go может пригодиться, зачем его делали и стоит ли вообще его учить. Я тоже долгое время участвовал в этих срачах, принимая посменно сторону «фанов» языка и сторону оппозиции, но в конце-концов допер, в чем фокус. Сегодня немного потупил у дивана в посте и решил написать вот эту заметочку.
Давайте, пацаны, проходим в пост.
Кому нужен Go?
Я только сегодня понял, что почти никто толком-то и не понимает, зачем вообще Go нужен. Если коротко, то Go нужен для того, чтобы проектировать robust software. Я не знаю, как правильно перевести это слово на русский, но это скорее всего что-то вроде «надежный». Так вот, Go сделали, потому что гуглу нужен был инструмент для написания надежного кода. На самом деле не сколько гуглу, сколько Робу Пайку, который последние две декады, как минумум, одержим идеей сделать сишку с каналами и зелеными потоками. Так получилось, что Роб Пайк попал в нормальную компашку с другими штрихами из Bell Labs, крутейшим Russ Cox, Фицпатриком и т.д. Этим ребятам несложно было убедить гугл, что им нужен новый язык и вобщем-то, бабосики они на него выбили.
Так, это было небольшое лирическое отступление, давайте вернемся к теме. Да, зачем же все-таки гуглу был нужен новый язык? Ну, тут все понятно, давайте послушаем слова самого Роба Пайка:
Фишка в том, что наши программисты гуглеры, а не ученые. Это обычно молодые, только выпустившиеся пацаны, которые возможно выучили Java, возможно даже C/C++ и может быть Python. Они не в состоянии понимать пробздетый язык, но мы все равно хотим, чтобы они делали хороший софт. Таким образом, мы даем им легкопонимаемый язык, к которому они быстро привыкнут.
А теперь давайте попытаемся понять, что же он имел ввиду. Если грубо говоря, то он сказал, что в гугле работают не самые умные ребята («не способные понимать крутой язык»), так что они придумали такой язык, который просто невозможно не понять. Это на самом деле очень круто для менеджмента. Посудите: можно нанять 100 посредственных программистов, дать им в руки Go и эта армия обезьян будет генерить вам много «неплохого» и очень даже поддерживаемого кода! Go это фантастический инструмент для менеджмента, лучше не придумать: моментально заганяем всех программистов в рамки go-fmt (никто не сможет пропихнуть свой стиль форматирования), забираем у них любые абстракции сложнее интерфейса и получается такой конвеер кода, в котором developer is just another brick in the wall. По-моему, очень круто! Ну, программистам скорее всего такой расклад не очень понравится — мало кто любит быть винтиком в системе.
Так вот, Go нужен корпорациям. Если у вас в компании работает много людей, большие проекты и все такое, то Go это идеальный вариант! Но для того, чтобы понять, действительно ли вам нужен Go, надо разобраться ЗАЧЕМ его все-таки стоит использовать. Давайте узнаем.
Зачем нужен Go?
С технической стороны, ниша у Go довольно скромная: сеть, утилиты, бэкенды. Если у вас сложные сети или много нод, которые надо как-то навороченным образом оркестрировать, то Go это хороший выбор (судя по опыту CloudFlare). Если вы хотите сделать какую-то классную консольную утилиту, вроде докера или консула, то Go тоже нормульок подойдет (судя по опыту оных). Я вот сейчас тоже делаю интересную утилиту и пишу ее на Go, потому что вписывается. Ну и в конце-концов. Если вам нужен быстрый и в принципе, эффективный бэкенд, то тоже можно выбрать Go. Я не представляю, как народ пишет бизнес-логику на Go, но как-то пишут же! Короче, тут все довольно сложно. С одной стороны, делать CRUD в Go это достаточно болезненно, с другой стороны есть 350 разных роутеров и фреймворков, которые здорово облегчают работу.
Что касается других ниш, то я с уверенностью могу вас заверить: полная профанация. Если Go где-то всерьез и используется, то в консольных утилитах, на сетях и бэкендах. Больше юскейсов нет. И давайте не будем их выдумывать. Go изначально язык, который сделали в гугле, чтобы студенты могли придти и писать код для навороченной сетевой инфраструктуры гугла. Тут можно сформировать своеобразный rule of thumb: "Если ты не пишешь софт для сети, консольную утилиту или хайлоад бэкенд, то Go тебе скорее всего не нужен". Тем не менее, полно народу продолжает писать софт на Go ради собственно говоря, самого Go.
Cтоит ли учить Go?
Это вопрос, на который можно дать короткий и однозначный ответ. Go стоит учить в любом случае. Во-первых, потому что это как два пальца обоссать — проще язык сложно придумать. В Go очень мало грамматик и абстракций, освоить его можно на начальном уровне за выходные. Конечно же, в языке есть полно дырок и «ловушек для лошпетов», о которых я писал в своей последней статье, но они довольно быстро резолвятся.
Во-вторых, потому что Go так или иначе очень глубоко проникнет в наши жизни. За последний год на гитхабе было написано ооочень много проектов на Go, все больше и больше корпораций подсаживаются на него и т.д. Иметь такой популярный инструмент в запасе всегда хорошо, как не крути. Вдруг тебя с работы выгонят и совершенно случайно упадет классный оффер на должность Go программиста. А тут фигасе и ты подходишь, потому что выходные его подрочил годик назад.
Для тех, кто прямо не могут сдерживаться и УЖЕ выпригивают из трусов, сразу кидаю несколько ссылок на материалы:
Дерзайте, Go вам точно не навредит. Ну может будете потом скучать по gofmt, но это не очень страшно на самом деле.
Заключение
Go так или иначе уже здесь, он уже взлетел. Его уже используют, его уже котируют, он уже нужен. Можно очень долго воротить жопу и ругаться на отсутствие дженериков, но час Go уже настал. Тем не менее, важно понимать кто и зачем должен употреблять Go в еду. Если ты не корпорация или стартап, который занимается разработкой умных сетевых петакластеров метапарадигм, то тебе Go скорее всего не нужен, конкретно тебе. Ноооо стоит тебе оказаться в одной из таких контор, Go однозначно пригодится. Учите Go, пацаны, оно того стоит.
Спасибо за твое внимание,
Илья.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
В предпросмотре не надо рендерить всё рабочее окно
При виде из камеры в предпросмотре рендерится даже та область экрана, которая не попадает в камеру. Это лишняя работа компьютера.
Можно задать собственный размер участка рендера нажав в рабочем окне Ctrl+B (Render Border). Сбросить размеры этого участка Ctrl+Alt+B. Когда я первый раз увидел, что в Cycles материал не просто светится сам, но и освещает всё вокруг, то подумал, что светильники как класс объектов уже не нужны. Я ошибался.
В сложных сценах источник света (Lamp > Point) даёт качество значительно лучше чем объект со светящимся материалом. Обратите внимание, что у источника света есть настройка размера (рядом с настройкой яркости).
Обратите внимание на формат OpenEXR
Он позволяет сохранять изображение в 32 бита (обычно 8 бит). С помощью фотошопа вы можете вернуть пересвеченные детали. Откройте отрендеренный кадр в фотошопе и переведите его в 8 бит. При переводе появится диалог в котором можно будет поправить яркость.
Мы не можем видеть одновременно весь диапазон яркости, что предлагает нам природа. Но полный диапазон яркости можно сохранить и поправить его после рендера.
Почему не работает модификатор Bevel?
Потому что Bevel часто попадает в очередь после модификатора Edge Split. По началу это не очевидно. Надо менять местами.
Анимировать можно почти любой параметр или галку
Например надо, что бы объект в первом кадре был, во втором исчез.
В итоге анимация пропадания куба. Прошу заметить — пропадания в рабочем окне, а не при рендере. За видимость при рендере отвечает иконка фотоаппарата.
Можно анимировать и слайдеры:
Переключение камер
0 (ноль) (цифровая клавиатура) – вид из активной камеры
Ctrl+0 (ноль) (цифровая клавиатура) – вид из выбранной камеры. Делает эту выбранную камеру главной, т.е. активной. Смотреть так же можно из объектов и источников света.
Переключение камер в анимации
В рабочем окне создаём камеры и расставляем.
В окне таймлайна нажимаем M (Marker) и добавляем маркеры там где хотим переключать камеры.
Выбираем камеру. Выбираем маркер. В окне таймлайна давим Ctrl+B (Bind Camera to Markers). Поступаем так с каждой камерой.
Должно получится что-то вроде этого:
Применение материалов на основе их номера
Например. Есть колпак настольной лампы. Снаружи он чёрный, а внутри белый. А ешё у колпака есть толщина металла.
Моделируем внешнюю оболочку
Применяем модификатор Solidify (Толщина)
Создаём 3 материала: внешний (чёрный), внутренний (белый), край металла (голубой)
Рендерфермы, которые использую я RayPump — одним кликом отправляется сцена в сеть и автоматом скачивается результат. Каждый день даётся 80 условных денежных единиц на которые реально посчитать бесплатно 3 картинки. Ограничение качества в 200 сэмплов. Разрешение максимум 1280х720. То что у меня считается час, там считается пару минут. Водяного знака нет. Ставится маленький логотип рендерфермы в углу и не портит изображение. Можно положить денег и рендерить без ограничений.
Sheepit-Renderfarm — распределённая бесплатная рендерферма. Все помогают всем. За помощь другим начисляется рейтинг который определяет приоритет твоих сцен в очереди.
Как настроить автоматический рендер сцены на нескольких машинах?
Настраиваем сцену:
Назначить путь до папки рендерёных кадров. Он должен быть относительным т.е. плясать от папки сцены, а не от корня диска.
Галку Overwrite снять — запретить заменять уже созданные кадры.
Галку Placeholders поставить — когда кадр взят в обработку то создаётся фальшивый файл имитирующий созданный кадр.
Сцену копировать на каждую машину не нужно. Открываем доступ по сети к папке со сценой.
Блендер не может открыть сетевые папки собственным диалогом. Открываем сцену через проводник операционной системы и рендерим.
Бывает по разным внешним причинам, что некоторые кадры не просчитываются. Обычно легко эти кадры отсортировать в проводнике по размеру в мегабайтах. У бракованных кадров размер маленький. Надо просто их выкинуть и пустить рендер заново, машины сами заполнят образовавшиеся пробелы.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Это не тостер, но проблема проявилась по всей России пару часов назад. Адрес 8.8.8.8 не работает, хотя пингуется. Может кто знает, что случилось? Адрес 8.8.4.4 тоже не отдаёт записи.
P.S. Если кто увидит этот пост, хоть у себя на серверах поправит, если использовался сей DNS. Проверять либо dig @8.8.8.8 google.com либо nslookup google.com 8.8.8.8
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Привет, это снова Без слайдов. Я Алексей Федоров, и на этот раз в гостях у меня побывал Сергей Шкредов, руководитель всего .NET-направления в компании JetBrains.
С Сергеем мы говорили:
о последних релизах ReSharer;
о новой схеме подписок и лицензий;
про непростые отношения с Microsoft;
о рантайме и развитии языка;
о том, как поменял ситуацию выход Roslyn;
о работе с фидбеком пользователей для улучшения продукта;
о планах развития других продуктов .NET стека;
о важности внутриотраслевого общения и обмена опытом;
про разработку продуктов для С++;
немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft;
О том, как пользователи почувствуют изменения;
Как ReSharper будет развиваться дальше.
Вот видео
Под катом — текстовый вариант интервью.
О новых релизах ReSharer и Update Rate
—Сергей, у вас недавно был большой релиз, даже два.
— Да.
— Ты можешь мне немного рассказать, что у вас там нового в новом ReSharper? Так, очень коротко. И, собственно, почему релиза было сразу два?
— За предыдущий год мы сделали три больших релиза — это ReSharper 9.1, 9.2 и 10.0. И мы на этот год взяли себе такой темп — делать релизы раз в четыре месяца, и в каждом релизе не прятать фичи, выпускать всё как можно раньше. Это лучше соответствует тому, как развивается Visial Studio — там происходят все время какие-то новые события. И с этой точки зрения релиз 10.0 мало чем по количеству фич отличался от релиза 9.2. Единственное, что на этот релиз у нас было строгое ограничение: мы вместе с выпуском всех продуктов меняли систему лицензирования всех наших IDE, поэтому дата релиза была зафиксирована задолго до этого релиза. Собственно, из-за зафиксированной даты релиза получилось два.
— То есть, это был багфикс?
— Да, багфикс-релиз, который вышел через две недели после 10.0.
— Много багов пофиксили?
— Много, порядка сотни. В основном, конечно, пользователи жаловались на Unit Testing и плохой резолвинг UWP-приложений.
— Ну сейчас пользователи уже успокоились? Все в порядке?
— Сейчас уже да. На самом деле следует смотреть не на то, что пишут в Твиттер, а на update rate (процент людей, которые перешли на новую версию), то он в два раза лучше, чем был для ReSharper 9. То есть, за первые три недели существования ReSharper 10 на него проапдейтилось в два раза больше людей, чем год назад.
— А много вообще по вашим данным людей пользуется старыми версиями?
—Я думаю, нет. То есть, к моменту релиза следующей версии предпоследней версией пользуется порядка 30%, а 70% людей уже на новой сидят. И готовы перейти на следующую, самую новую, версию.
—То есть сейчас есть 30% которые пользуются ReSharper 8?
— Да.
— Понятно. А вы как-то пытались с ними общаться, понять, почему они не хотят переходить?
— Я думаю, что это нормальное распределение такой активности разработчиков. И это мало связано с какими-то внутрепродуктовыми причинами.
О хитрой схеме подписок и лицензий
— Cтарая лицензия — она была по времени или она была по версии? Я мог, имея ту лицензию, бесплатно проапгрейдится?
— Где-то около двух–трех лет назад мы стали продавать подписки, которые позволяли в течении года обновляться на любую версию. Покупаешь, и у тебя в течение года есть все версии, которые мы выпускаем, вне зависимости от того, как мы их называем. Таким образом мы отвязались от версионирования, что есть это позволило нам выпускать более частые релизы, не опасаясь за то, что мы не получим достаточный Upgrade Rate на мажорной версии. Ну и для коммерческих пользователей у нас еще оставались perpetual (бесконечные по сроку действия — прим. автора) лицензии без подписки на обновления. Сейчас такие лицензии уже ушли. Я могу, конечно, прокомментировать новую подписочную схему.
— Да, расскажи, пожалуйста. У вас всё еще раз изменилось, об этом много писали и говорили. Ты можешь коротко подытожить, что в итоге получилось. Мне кажется, это будет для наших зрителей не лишним.
— IDE — это продукт, развивающийся вместе с рынком, вместе с технологиями, вместе с нашими пользователями. Он развивается одной большой лавиной. Мы как компания, конечно, хотели бы, чтобы все пользователи имели возможность пользоваться самой последней версией нашего продукта, и чтобы лицензии не были ограничением на этом пути.
Соответственно, когда мы это поняли, мы ввели подписки. Подписки всем хороши, но подписка – это штука, которую ты должен обязательно себе купить. То есть ты покупаешь себе perpetual-лицензию и к ней подписку. Мы к этому не сразу пришли. Мы на самом деле разделили сейчас плату за подписку на год вперед, и плату за perpetual-лицензию.
Первый наш вариант схемы подписочной был такой: вы покупаете лицензию на год, и через год у вас все отнимают. И мы, конечно, встретили массу негативного фидбэка по этому поводу. Я думаю, это заслуга большая наших маркетологов, наших СЕО, что среди всего этого фидбека мы смогли понять, что именно в этой ситуации волнует пользователей. А пользователей волнует отсутствие гарантий того, что они смогут продолжить пользоваться продуктом.
Например, были компании, которые явно писали нам, о том, их бюджет утверждает, например, конгресс Соединённых Штатов. И если он не утвердит бюджет на обновление версии, мы просто на следующий год останемся без продукта. Это самая показательная, думаю, история, которая помогла понять, что надо оставить perpetual-лицензию.
Теперь ты покупаешь у нас год подписки. В течение этого года ты можешь принять решение о том, что хочешь обновиться. Ты обновляешься и пользуешься, а платишь потом, через год, путем продления этой подписки. Таким образом, когда ты покупаешь версию — ты покупаешь ее на данный конкретный момент времени вообще без возможности обновиться на следующую. Но ты можешь отложенно докупить себе обновления на версию, которая выйдет в течение этого года.
— Если не купишь, то что происходит?
— Тебе придется пользоваться через год той версией, которую ты купил.
—То есть происходит откат назад, на версию, актуальную в момент покупке?
—Да. Можно рассматривать это как откат, а можно рассматривать как то, что ты в течение года принимаешь решение о том, что «я хочу новую». И в таком случае платишь через год, когда продляешь подписку.
— Слушай, эта схема какая-то не простая. Вы ее у кого-то взяли или сами придумали? Работает ли по такому принципу кто-нибудь еще на рынке?
— Компания Adobe. Но там история проще, конечно. Мы много слушаем пользователей, и из-за этого наши решения иногда становятся иногда сложнее.
— Окей, ну-то есть довольно уникальная история.
— Я могу привести еще больше примеров. Два дня назад Microsoft перешел на такую же схему.
— Интересно.
— Абсолютно на такую же. Причем на эту тему не было ни единого большого поста в интернете.
— А как так вышло? Почему в вашем случае были обсуждения?
— Мы компания, которая больше работает с сообществом. И даже когда мы вводили подписки опционально для коммерческих пользователей и неопционально для наших персональщиков, мы получали очень много фидбека.
—То есть можно сказать, что ваш продукт-менеджмент живет фидбеком?
— Да, в большой степени.
Про непростые отношения с Microsoft
— А какие у вас вообще отношения с Microsoft? Сам я — человек из мира Java, а там довольно давно, уже лет десять как, платформа более-менее открытая. Разговаривая с ребятами из JetBrains, я понял, что они в принципе хорошо осознают, что происходит внутри самой Java-платформы и могут в любой момент посмотреть любой сложный код, разобраться, даже что-то где-то попатчить.
— Там не нужно коммуницировать с вендором.
— Именно. А у вас, в .NET-мире, как это происходит?
—То, как мы работаем, как мы планируем наши релизы, сильно поменялось за последние несколько лет. И поменялось из-за того, что поменялось отношение Microsoft к экосистеме, к работе с партнерами, к уровню открытости компании. Три года назад ситуация была такая: были приватные билды Visual Studio, которые выдавались только партнерам — была партнерская программа, по которой мы тесно коммуницировали с Microsoft. Мы имели право сабмитить более приоритетные баги на Visual Studio.
То есть Microsoft целенаправленно поддерживал избранных производителей расширений для Visual Studio, порядка ста или двухсот компаний, и для этого были всякие приватные программы. Cейчас большинство фидбека, большинство изменений и билдов можно получить абсолютно легально через открытые источники, а большинство команд с которыми мы общаемся, разрабатывают в Open Source. Сейчас всё меньше и меньше Visual Studio становится закрытым продуктом, который требует достукиваться до Microsoft для того, чтобы принести фидбэк, или что-то поменять, или что-то узнать новое.
—Получается, что многие вещи вы стали делать самостоятельно?
— Visual Studio Industry Partner (VSIP) Program, можно сказать, перестала быть каким-то большим бенефитом для нас. Мы ездим на мероприятия, где можно пообщаться с командой, и это практически единственная просьба от VSIP Program.
— А почему они так изменили свой подход, как ты думаешь?
— Они стали терять разработчиков. Microsoft долго был вендором, который представлял инструменты для разработчиков, которые покрывали все нужды для всех сценариев. С появлением мобильных платформ все изменилось. Инструментария Microsoft стало не хватать, чтобы клиентам Microsoft свои программы писать под Android, под iOS. Это первая причина, которая запустила этот сдвиг.
Второй, наверное, фактор, который повлиял на открытость, это наверное, Azure. Чтобы затащить как можно больше разработчиков, причем не только .NET, а Java, Python, PHP, Ruby — всех разработчиков в свой Cloud, нужно представлять им инструменты. Есть четкая политика — инструменты для разработчиков Microsoft предоставляет сейчас условно бесплатно. Хотя есть случаи, когда не бесплатно (например, Visual Studio), а есть случаи, когда далеко не бесплатно (например, Visual Studio Enterprise). Хотя 6000 долларов это не 14000 долларов, как она стоила год назад.
— Год назад и рубль был другой. А вот, допустим, приход в Microsoft нового СЕО год назад повлиял ли на ситуацию?
— Я думаю, что сильно повлиял, и он в таком смысле продолжил, дал дальше делать инструменты для разработчиков более открытыми. И двигаться в сторону того, что Microsoft – это облачный провайдер и будет укреплять эту свою позицию. Развивать именно экосистему на базе тулов Microsoft, экосистему разработки под все платформы.
— Была еще очень интересная история, связанная с кросс-платформенностью. Вот есть Mono, который под Linux, и есть что-то в этом месте от Microsoft, которая как-то будет конкурировать. Ничего про это не знаешь?
— С Mono история такая, что это как раз та самая дырка в стеке технологий Microsoft, про которую я говорил. Так же как дела обстоят: в Microsoft приходит клиент с тремя тысячами лицензий на Visual Studio, говорит: «нам нужно программу под iOS писать. Я сижу на ваших инструментах уже 10 лет, что мне делать?» Обращается к консультанту Microsoft, и тому нужно дать ответ. Поэтому у Microsoft есть бизнес-задача – обеспечить разработку под iOS.
Соответственно, какие есть варианты? Есть Xamarin, вполне работающая штуковина, есть Apache Cordova, есть нативная компиляция С++ под разные устройства. Вот три инструмента, которые будем развивать, для того, чтобы покрыть этот сценарий. То есть кроссплатформенная разработка — это такое затыкание дырок с помощью внешнего партнера.
Обычно в Microsoft это так происходит, что сначала они затыкают дырки с помощью внешнего партнера, потом сами выпускают продукт и занимают это место. Но сейчас я не вижу таких тенденций, не вижу, чтобы Microsoft пытался бы перетянуть кроссплатформенную разработку к себе. Пока они на стадии кооперации находятся. Те библиотеки, которые написаны на Mono, подтягивают к себе. Core CLR, виртуальные машины, какие-то элементы фреймворка…
—То есть это взаимный процесс?
– Да, это сейчас очень взаимный процесс. Я надеюсь, конечно, что оно унифицируется в какой-то точке.
—Сейчас у них есть собственная реализация виртуальной машины .NET под Linux. Довольно сырая, так?
— У нее есть шанс стать нормальным продуктом.
— Но Microsoft об этом рассказывает как о готовой экосистеме, как будто это готовый продукт, бери и пользуйся. Видимо, это не совсем так?
— Чтобы пользователей на него перетащить, его нужно так позиционировать. Я не вижу перетекания пользователей с классического ASP.NET на ASP.NET на базе Core .NET. Просто еще не готовы. Я думаю, что это будет происходить, но не сейчас. Сейчас есть проблемы с перетаскиванием своего кода.
Дело в том, что сейчас есть существенные проблемы на пути к перетаскиванию своего кода под DNX, под .NET Core. Они связаны с отсутствием вышедшей в релиз версии фреймворка, под который ты можешь таргетить свои библиотеки, чтобы они работали и в классическом ASP, и под полный .NET фреймворк, и в Core CLR. Для этого у Microsoft существует много версий .NET: есть Silverlight в браузерах, есть Windows Phone, есть Desktop-приложения, есть «полный» .NET Framework.
Сейчас появился еще один стек — Core CLR. И в принципе, как отдельная реализация, он ничем не отличается от всех остальных. У Microsoft есть решение для того, чтобы писать код под разные стеки. Эдакий хак, который для каждого варианта сочетаний этих платформ умеет генерировать код, работающий именно на трех или двух из них.
Это не очень работающий сценарий, потому, что количество таких сочетаний растет, грубо говоря, экспоненциально. Сейчас Microsoft активно работает над тем, чтобы от этой экспоненты избавиться и сделать платформу, которую ты можешь таргетить. Чтобы код, который таргетит эту общую платформу, работал у тебя везде. Тогда появятся обновленные версии NuGet-пакетов, которые ты можешь использовать везде и компилировать их подо все, используя одни и те же библиотеки.
— Это у них получается, но, видимо, не очень быстро. Да?
— Очень много дизайн-решений меняется буквально на глазах. Сейчас та версия, которая есть, она не является финальной, Microsoft уже работает над другой версией.
О рантайме и развитии языка
— Насколько, по-твоему, .NET — это legacy-технология, насколько это живая технология? Я сейчас объясню свой вопрос. До какого-то момента, может быть, года до 2008-го, было очень мощное развитие языка. Про Runtime я не могу сказать, мне не хватает экспертизы. Мне кажется, Runtime не очень сильно продвигается вперед. А вот язык в то жесамое время очень сильно развивался. C Java — прямо противоположная история, там язык очень долго тупил, а Runtime развивался дикими темпами. Интересно, что, по моему ощущению, в последнее время с C# тоже ничего глобального не происходит. Изменения были раньше более заметны. Как ты считаешь?
— Совершенно верно. Я думаю, что Runtime отстает от JVM очень сильно. Виртуальная машина в .NET обладает очень плохим сборщиком мусора и очень слабым JIT-компилятором. В итоге получается медленно исполняющийся код, в котором приходится вставлять затычки на затычки, чтобы избежать лишних аллокаций и справиться с теми функциями, которые автоматически не инлайнятся. Код автоматически не оптимизируется на должном уровне. В Java такой проблемы нет.
— А язык?
— Был период, когда язык мало развивался — до выпуска C# 6. Он связан с переходом на новый компилятор Roslyn, который задержался на несколько лет. Года на два, по ощущению.
— То есть, язык не развивался примерно версии с третьей или четвертой?
— С пятой. Пятую версию выпустили, а потом начали писать новый компилятор. Писали его долго и мучительно. В основном, пытались достигнуть той же производительности, которая была в нативном компиляторе, при условии всех архитектурных улучшений.
В итоге заданной цели достигли в режиме компиляции. То есть, когда сейчас С# 6 и C# 5 используешь — Разница в скорости не заметна. По сравнению с остальными этапами сборки компиляция не стала занимать больше времени.
А вот с точки зрения поддержки в IDE — налицо массивный провал. С точки зрения поддержки C# 6 в Visual Studio 2015 — это полный fail. Мы не можем редактировать проект ReSharper Visial Studio в релизе 2015 без ReSharper. Оно выжирает всю память, виснет и все. Такая ситуация.
— Да, это довольно интересно. Особенно на первых этапах, когда вы увидели первые билды, наверно, были бурные эмоции. Как вы жили с этим?
— Волосы дыбом вставали.
— Да. Понятно, что в какой-то момент вы, видимо, там все мажорные проблемы пофиксили и как-то дальше смогли хотя бы внятно с этим жить?
— Сейчас мы поддерживаем Visual Studio 2015, грубо говоря, с закрытыми глазами. Мы сами ей не пользуемся. Планируем переезд потихоньку на нее, там в апдейте стало получше. Мы порезали ReSharper так, чтобы можно было кусочками его запускать. Мы создаем меньшие Solution’ы, чтобы можно было начинать всем этим пользоваться.
— У IntelliJ IDEA, с точки зрения восприятия ее как инструмента, случился колоссальный прогресс в 2007 году, сразу после выхода на рынок процессоров Core 2 Duo. Был очень сильный (по сравнению с Pentium D) performance-рывок. Соответственно, IntelliJ IDEA из положения «IDEA тормозит» перешел в положение «О, IDEA— отличный инструмент. Теперь можно работать!» IDEA стала работать быстрее просто потому, что железо резко стало лучше. Этого хватило. С тех пор люди на производительность IDEA особо не жалуются. Правильно я понимаю, что в .NET стеке производительность IDE— это все еще головная боль?
— К сожалению, да. Мы находимся в довольно тяжелом положении. У нас примерно половина багов с производительностью вызваны работой Visual Studio, а вторая половина — вызвана нами. Мы очень часто не можем отличить одни от других. Может быть, в ReSharper typing происходит медленно, потому что сейчас в бэкграунде Roslyn анализирует файлы и аллоцирует сотни мегабайт в секунду, отчего просто GC помирает?
Когда ты находишься «как бы внутри своего кода», Microsoft сделал некоторые оптимизации специальные, которые учитывают то, как typing в IntelliSense взаимодействует с фоновым анализатором кода. Соответственно, когда мы запускаем наши активности по автодополнению и type assist, мы влияния на то, как работает Roslyn background thread, не имеем.
— Они намеренно так сделали?
— Я думаю, что они решали свою проблему. Конечно же, о нас они не думали. Это естественно.
О том, как поменял ситуацию выход Roslyn
— А насколько выход Roslyn изменил положение дел? Это для вас головная боль?
— Нам стало полегче. Дело в том, что мы лучше стали понимать разные виды проектов, в которых Roslyn используется как Language-сервис. Мы оттуда вытаскиваем модель компиляции, файлы, референсы, идущие в компиляцию. В предыдущих версиях Visual Studio, когда не было Roslyn, это был довольно трудоемкий момент, связанный с вызовом билда, вытаскиванием референсов из Visual Studio напрямую. Это было сложно и с багами. Сейчас это гораздо более прямой процесс. Мы используем Roslyn для того, чтобы создать модули и то, как они будут взаимодействовать с компилятором.
— А как Visual Studio взаимодействует с компилятором? Студия использует для построения собственной модели кода сам компилятор?
— Visual Studio — да. In process загружает Roslyn.
— А в старом случае?
— В старом случае было тоже самое, только в нативном коде на С++. Можно было только догадываться, что он делает и где. Но он не влиял на Garbage Collector никак, мы его не видели никогда в профайлерах. Он, может быть, там был, но он был очень быстрый.
— Связано ли это с тем, что Roslyn — это еще сырая технология? Или связано с тем, что она как-то в корне неправильно спроектирована?
— Да, конечно. Очень сырая. В плане оптимизации конструктора данных, который используется в Roslyn для простейшей функциональности Rename или при нахождения ошибок во всем Solution’е — это прямые алгоритмы, которые тупо работают. Но, понятное дело, влияют на производительность в конце концов.
— То есть, в принципе, шанс того, что разработчики Microsoft ускорят Roslyn, есть?
— Шанс есть, конечно. Но может возникнуть проблема с компанией Microsoft, где такая необходимость может быть не осознана на должном уровне. И не будут выделятся время, и деньги на это.
— Понятно. А тот Open Source, который сейчас происходит, он Open Source только с точки зрения «я могу посмотреть» или «я могу законтрибьютить»?
— Контрибьюшенов я видел очень мало. Сейчас, в основном Core CLR, это все такой показанный исходный код, который ты можешь скомпилировать или просто посмотреть, почитать. Я не слышал, чтоб их массово кто-то принимал.
— То есть, в принципе шансов, что вы придете и поможете им, пофиксите им все проблемы с перформансом, тоже не очень много, судя по всему?
— Эти проблемы с перформансом часто лежат в области компиляции студии именно с Roslyn. Шанс на то, что мы придем и будем в Roslyn что-то изменять есть, конечно. Мы смотрим, анализируем, что и как происходит. Мы имеем представление об архитектуре, об архитектурных проблемах.
Как ReSharper будет развиваться дальше
— Значит, Roslyn строит свою собственную модель, свое собственное дерево, да? Это, видимо, что-то типа Concrete Syntax Tree.
— Да. Очень специфичное, с пробелами, с комментариями… Конкретный ситаксис, так, как он написан в редакторе. То, что в IDE используется — это очень конкретное синтаксическое дерево, ни в коем случае не AST.
— Вы строите модель кода. У вас это свое дерево?
— Да.
— А у Roslyn — своё. Видимо, студия пользуется им — это логично. Собственно, как вы с этим живете? Как вы с этим будете жить дальше?
— У нас сейчас есть несколько направлений. Первое — это не использовать Visual Studio. Второе — это использовать Visual Studio, но запускать ReSharper отдельным процессом. У нас есть видение, есть дизайн, решение, когда все ReSharper’овские модели кода, все синтаксические деревья, индексы, кэши и все, что касается семантической модели, хранится в отдельном процессе.
— Мы с Кириллом Скрыганом это обсуждали, когда он рассказывал, что ReSharper сильно упирается в ограничение по памяти 32-битной Visual Studio. Я ему сказал, что очевидно тогда делать ReSharper out-of-process, на что он ответил, что да, надо, но это чревато Memory Traffic’ом.
— Собственно, дизайн-решение заключается в том, чтобы минимизировать этот Memory-Traffic. Работает это примерно так: мы можем воспринимать студию как UI-приложение. То есть, сделать MVVM. Можно рассматривать, что бэкэнд ReSharper’а — это такая ViewModel для студии, которая является View. Если рассматривать трафик между ними, то это будет трафик тех данных, которые достаточны для того, чтобы отобразить изменения в UI. Ты никогда не найдешь массированную пересылку данных на уровня UI. Всегда надо применять два символа, две подсветочки…
Это все живет на стороне студии, на стороне UI. Данных, которые нужно пересылать для того, чтобы отобразить UI, мало. Тысячи объектов переслать — это мгновенно. Переслать изменения в документе при тайпинге — тоже мгновенно. На этой идее можно так построить код, чтобы синхронизировалось только те данные, которых достаточно для отображения UI.
–– Насколько Visual Studio хорошо спроектирована, насколько она позволит вам это сделать?
–– Это исключительно вопрос нашего кода, то есть интеграция наша со студией никак не поменяется.
–– Ты очень красиво все описал. А в реальности это заработает? Visual Studio позволит вам всю работу с UI куда-то вытащить?
–– Этот вопрос написания наших элементов UI. Давайте приведем пример. Вот, например, показывается «бульбочка». Для того, чтобы показать ее, сейчас используется PSI, синтаксические деревья, документы, вся проектная модель. Если мы оставим то, что есть и будем пересылать эти синтаксические деревья целиком – то это, конечно, никуда не взлетит. Но вообще, чтобы нарисовать «бульбочку», нам нужны иконка, текст и все.
Когда мы нажали Alt + Enter, мы передали item в виде текста и иконы, когда мы нажали «применить какую-то бульбочку», мы на бекэнд, который работает out-of-process, отослали на исполнение одну команду. Все изменения данных в синтаксических деревьях и документах – они все произошли Out-of-process. Теперь на фронтенд в качестве результата нужно вернуть новое положение курсора и поменять те документы, которые были открыты в редакторах. И всё.
–– Задача сводится к тому, чтобы разработать протокол обмена данными между ReSharper’ом и тем, что видит пользователь на UI, причем минимальный по трафику.
– У нас есть наработки по протоколу. Протокол очень интересный, реактивный. Мы синхронизируем одинаковую структуру данных, которая будет работать с обеих сторон. Это большое изменение — нужно изменить весь исходный код ReSharper’а.
Это изменение заключается в том, что ViewModel надо переписать так, чтобы они не держали в себе ссылки на сематические модели кода. Это огромное изменение, поэтому придется делать его постепенно. Мы потихоньку начнем делать так, чтобы наш продукт работал и так и так. И будем архитектуру приводить к тому, что UI не будет зависеть от семантической модели. И это опять инверсия зависимости.
О том, что как пользователи почувствуют изменения –– Насколько для пользователей это будет прозрачным?
–– В конце концов, это должен быть тот же самый User Experience.
–– Пользователь не должен ощущать, что бэкенд другой у всей этой истории?
––Конечно. В какой-то момент мы подменим старый новым. И всё.
–– Обычно когда делают какую-то штуку, которая работает с кодом, то переписывают фронтенд компилятора и этим ограничиваются. Тут же получается, что вы строите уже целое здание, не только фронтенд?
–– Конечно. В ReSharper сейчас кода, который непосредственно парсит, резолвит что-то —порядка 10%.
–– Насколько имеет смысл вообще заниматься всей возней c Visual Studio, учитывая, что у вас в компании офигенный опыт и очень успешный спрос по построению собственных IDE?
–– Visual Studio, конечно, имеет смысл, с нее мы никуда не слезем. Это инструмент, который обеспечивает разработку на всех платформах, которые нужны для Microsoft. Он меняется раз в три месяца и поддерживает новые платформы от Microsoft. Повторять эту работу — вовсе не наш приоритет.
В первую очередь нужно понимать, что Visual Studio решает внутренние задачи Microsoft. Вот, например, вышла Universal Windows Platform, а под нее нужно все программы дебажить, запускать, профилировать, настраивать проекты, которые будут работать под разные платформы… Это мы повторять не будем.
Немного о ReSharper C++, на который должны подсесть даже разработчики Microsoft
–– Пользуются ли разработчики Microsoft, которые все это делают, ReSharper?
–– Мы не разглашаем эту информацию. Понятно, что кто-то пользуется, но не будем говорить, в каких объемах.
–– Значит, разработчики Microsoft заинтересованы в том, чтобы ReSharper работал и развивался. Наверное, это очень большое подспорье — если вы их подсадили на ваш инструмент.
–– А сейчас хотим подсадить их на ReSharper C++ — это наша большая цель.
–– А расскажи, пожалуйста, об этом проекте.
–– Начали мы писать ReSharper С++ года 3-4 назад. Зарелизили весной. Мы его продаем как отдельный продукт, такой фигурно выпиленный язык C++ без всего остального. Из тех, кто пользуется ReSharper C++ — примерно 2/3 пользуются им без ReSharper, а треть ставит себе ReSharper C++ в составе ReSharper Ultimate.
–– Насколько вообще люди, которые пишут на C++ под Windows, пользуются именно Visual Studio?
––Я думаю, очень много людей пользуются Visual Studio для разработки на С++ в абсолютно разных сценариях.
––Это именно Managed С++ или любой?
–– Managed С++ — это абсолютно тупиковая ветвь развития технологий Microsoft, которая была призвана упростить интеграцию Managed кода с не-Managed кодом.
–– А,-то есть нужно было как-то С++, что бывают там какие-то
–– Просто сделать маршаллинг, сделать взаимодействие проще. Когда у тебя есть header, описанный для С++, ты его можешь прямо использовать в Managed С++ проекте — это удобно. Я вижу, что сейчас большинство людей которым нужен interop, используют либо COM, либо Implicit PInvoke. Наш опыт использования Managed C++ скорее негативный — в компиляторе баги и пр.
Возвращаясь к твоему вопросу, люди используют Visual Studio не для Managed C++, а для нативного С++ — это разработка под различные устройства, картографические приложения, игры и т.д. — в общем, для всего, что на C++ пишется.
–– Можно сказать, что для программирования на C++ под Windows Visual Studio — это основной инструмент разработки?
–– Конечно. Да и не только под Windows. Люди, которые программируют под Linux, тоже очень часто сидят в Visual Studio — и это нормально. Просто это хороший редактор.
Про разработку других продуктов для С++
–– У меня есть вопрос, связанный с разработкой других ваших продуктов для С++, в частности CLion — от ведь тоже поддерживает С/C++. А есть еще AppCode для Objective-C. Как ReSharper живет параллельно с этими IDE? Есть ли что-то общее в этих продуктах? Обмениваетесь ли вы опытом с разработчиками этих IDE?
–– Мы ориентируемся на две вещи. Во-первых, на стандарт языка C++, а во-вторых — на компилятор Microsoft. У CLion и AppCode приоритеты немного другие. Опытом c ними мы обмениваемся. Есть довольно много дизайн-решений, которые плавно перетекают в CLion из ReSharper. Когда начинали писать ReSharper C++ — уже был опыт написания ReSharper C++ в CLion.
Вообще, С++ в AppCode начался абсолютно фееричным образом. Там был Objective C, и в какой-то момент мы поняли, что там есть header-файлы, которые используются и для Objective C и для С++. То есть там где-то под define'ами написаны большие конструкции на С++, на которых парсер ломался, просто потому, что их не понимал. И тогда пришлось как-то поддерживать С++ для того, чтобы поддерживать Objective C. И с этого началась поддержка С++ в AppCode.
Разрабочики CLion и разрабочики AppCode между собой общаются, обмениваются опытом?
–– Они, конечно, общаются между собой.
–– У трех ваших инструментов много общего кода?
–– Его вообще нет. ReSharper С++ был написан сильно позже, и его писал человек, который до этого делал поддержку С++ в AppCode. И поэтому изначально ReSharper С++ дизайнился лучше, то есть архитектурно он правильней.
–– А это «правильней» выражается в чем? В том, что меньше костылей приходится вставлять для того, чтобы все работало?
–– Да. В конце концов, просто меньше ошибок кодов и багов в поддержке IDE.
–– А насколько на самом деле компилятор Microsoft поддерживает стандарт языка C++?
–– Уже лучше и постоянно улучшают.
–– Реальность такова, что реализация не всегда соответствует стандарту.
–– С этой точки зрения С# ничем не отличается от языка, который в реализации часто не соответствует стандарту. Сейчас, с открытием исходного кода, стало, конечно, гораздо проще. Когда что-нибудь ведет себя не так, как написано в спецификации — мы смотрим код, как оно написано в компиляторе, и вcё.
–– А для вас, что важнее — соответствовие спецификации или реализации?
–– Смотрим каждый раз на Use Case. В тех местах, где спецификация не соответствует реализации, скорее всего, если мы покажем ошибку там, где ее нет, пользователь ее поправит, просто перепишет код как-нибудь по-другому, это будет совершенно нормально. Т.е. это будет действительно какой-то сложный случай.
–– А как вообще появился сам ReSharper в JetBrains?
–– Он появился еще до меня: я в ReSharper только в 2007 году пришел уже на 3 версию или на 4-ую. ReSharper появился тогда, когда появился Eclipse. То есть, компании потребовалось диверсификация деятельности, поскольку возникла серьезная угроза основному продукту: все-таки бесплатные платформы, бесплатные IDE для Java – это серьезный конкурент.
–– То есть, это было бизнес-решение?
–– Думаю, что да.
–– А сейчас вы с коллегами по JetBrains чувствуете, что выиграли войну у Eclipse?
–– Да, чувствуем.
О важности внутриотраслевого общения и обмена опытом
–– А что насчет ReSharper? Есть разные люди, в том чиcле, в России, которые делают инструменты для разработки на C#: например, ребята из DevExpress делают CodeRush, который с Roslyn работает. Вы с ними общаетесь, обмениваетесь опытом или нет?
–– Я думаю, что DevExpress как-то подзабил на разработку инструментов, разочаровался. CodeRush — это больше сайд-проект: уже в конце 2000-х стало уже понятно, что ReSharper доминирует.
— Вопрос в том, как они у себя решают указанные тобой ранее проблемы. Вы общаетесь с ними? Не общаетесь?
— Они переезжают на Roslyn и пишут те фичи, которые не были написаны на Roslyn. Архитектурно, мне кажется, это невозможно. Написать функциональность ReSharper поверх Roslyn нельзя, не изменяя Roslyn. У нас слишком много структур данных внутренних компиляторных, которые используются для реализации фич анализа. Фича не пишется поверх какой-то код модели, которая зафиксирована. В процессе работы программиста в Visual Studio код модели постоянно немного меняется, меняются индексы, меняется то, что мы храним, то как мы храним. Чтобы корректно производить рефакторинги, мы используем компиляторную инфраструктуру, которая у нас написана. Те проверки, которые мы делаем для проверки ошибок компиляции, мы используем потом в том, чтобы написать предложение о том, что, например, «этот тип может быть заменен на var». И это всюду.
—А теперь у вас есть Roslyn. И вроде как вам нужно жить параллельно.
— Да, мы живем.
— Вы вообще не планируете его использовать?
— Нет.
—На данном этапе вы выиграли войну. И вы доминируете. Но сейчас с выходом Roslyn у остальных появляется шанс.
—У нас нет проблем с производительностью. У нас нет сомнений в том, что мы сможем в том же темпе писать новые анализы или еще более умные completion’ы и еще более умные факторинги.
— У вас и так сложные продукты, а сейчас они будут еще сложнее.
— Сложность поддержки языков не представляет сейчас серьезных проблем. Сейчас самая большая сложность в поддержке платформ Microsoft’овских. Вот этих вот стеков, универсальных приложений, резолвинг ссылок под все платформы. Сложность скорее в том, как работает сборка, чем в том, как работает компилятор.
Компилятор работает просто. И это у нас хорошо написано, хорошо поддержано. Сейчас проблема в платформах. И проблемы с производительностью. Их мы собираемся решать вот таким ультимативным способом – выйти из процесса Visual Studio.
О планах развития других продуктов .NET-стека
— Кроме ReSharper, про которые мы поговорили, у вас в .NET-стеке есть и другие продукты. Что происходит сейчас с ними и что вы планируете с ними делать?
— История началась давно, когда мы написали профилировщик dotTrace. Первую версию профилировщик dotTrace написал Миша Сеньков, который пишет сейчас ReSharper С++. В какой-то момент мы решили форкнуть нашу кодовую базу. В ReSharper’е было много кода, в котором написаны UI, коллекции, примитивы, Application-модели и т.п. Для выпуска продукта dotTrace мы форкнули платформу, и с этого момента у нас происходили несинхронизированные релизы на базе одной и той же платформы разных продуктов: dotTrace и ReSharper.
— То есть, внутри вашей кодовой базы была сущность, которая называется «платформа», и с ней оперировали оба этих продукта?
— Да, репозиторий, там много сборок. Каждый продукт использовал платформу. И у каждого продукта был свой релизный цикл. Накладных расходов, чтобы все это организовать, сделать стабилизацию была просто тьма. Соответственно, когда я пришел к руководству .NET отделом, оно началось с идеи, что платформа должна быть общая, у продуктов должен быть общий релизный цикл и желательно единый Solution, в котором разрабатываются все эти продукты. И мы, соответственно, начали соответственно унификацию нашей кодовой базы так, чтобы из одного солюшена можно было строить новую продукцию.
Если в предыдущих версиях интеграция dotTrace состояла из двух частей: из плагина к ReSharper и отдельного Extension’a для Visual Studio, потому что для того, чтобы интегририроваться с Visual Studio, нужно интегрировать менюшки, сделать манифест, package – все атрибуты Visual Studio экстеншена. В новой схеме мы сделали один продукт, который целиком интегрируется в Visual Studio, но собирается по частям. ReSharper — наверное, единственный Extension, который так делает в Visual Studio. Наш инсталлятор позволяет выбрать несколько продуктов и композирует Extension на лету. То есть, все атрибуты экстеншена у нас генерируются и компилируются. Прямо в инсталляторе написан код, который в Runtime интегрирует несколько продуктов в студию side-by-side.
Мы сделали кнопки, позволяющие включать и выключать каждый продукт. Если рассматривать архитектуру этого решения в принципе, то разные программы, например, ReSharper, Command Line Inspect Code Tool (это утилита для запуска анализа кода на билд-сервере), dotPeek, dotTrace, dotCover, dotMemory, — они запускаются все одинаковым кодом в абсолютно одинаковых условиях, просто с разными параметрами. То есть это фактически одна программа, которая запускается с разными параметрами, и эти программы можно запускать на всех наших сборках.
Когда-то на DotNext я делал доклад про то, как устроена Application-модель, основанная на зонах, которая позволяет все это делать. Собственно, все стало проще. Релизы стали проще. Программы стали все интегрированными теперь. Пользователи теперь не спрашивают: «Какой dotCover соместим с вот этой вот версией ReSharper?» Все это нам позволило выпустить ReSharper C++ как отдельный продукт, который может работать и вместе с ReSharper, и ReSharper без него может работать, и вместе они тоже могут работать.
— Насколько ваша новая модель уже сидит в головах у пользователей?
— В головах у пользователей я вижу, что очень много людей ставят — инсталляции dotTrace в студии выросли в разы.
— Здесь хороший потенциал для всяких там кросс-продаж.
— Кросс-продажи привели к тому, что мы продажи профайлеров прекратили совсем, и их просто не купить как отдельные продукты. Потому, что это больше приводит к проблемам, чем к пользе. Проблема заключается в том, что у меня есть лицензия на ReSharper, отдельно на dotTrace, я хочу поставить новую версию продукта, а версии синхронизированы. И вот эти лицензии на отдельные версии не работали совсем. Они могут быть несовместимы, могут отличаться, могут кончаться – одна позже, другая раньше… Чтобы избавиться от этих всех проблем, просто сделав более дорогую версию.
О работе с фидбеком пользователей для улучшения продукта
— Мы с тобой постоянно говорим про Performance. Специфика ReSharper’а такова, что в приложении много разной функциональности, и каждый пользователь использует свое собственное ее подмножество. А большинство людей, которые пишут на .NETe, они пишут программы с вполне обозримой кодовой базой, где есть фиксированный workload, где по циклу выполняются одни и те же операции, где действительно можно снять какой-то профиль и посмотреть горячие методы. У вас это как-то совершенно не так. Как вы с этим живете? Как вы все это держите в голове?
— Есть несколько вещей. У нас есть такая кнопка – Profile Visual Studio. Ты, как пользователь, можешь записать кусок времени, когда ReSharper тормозил, отослать это нам и мы, скорее всего, что-то с этим сделаем. Это механизм, который работает. С его помощью мы, версия за версией, исправляем баги. А дальше… дальше сложно.
Как программист походит к оптимизации, желательно обозримой? Find Usage, анализ файла, навигация, может, в каких-то сложных местах. И смотрит, сколько времени потратилось на эту операцию. Find Usage сейчас у нас занимает 10 секунд, а должен занимать семь. Но в процессе изменений мы делам кэши, меняем структуруыданных, которые тоже нужны. И можно легко потерять производительность в каком-нибудь другом сценарии, например, в код Code Completion, а еще хуже в какой-нибудь синхронной части его части, который работает у тебя в Foreground и напрямую влияет на время отклика при печати.
Соответственно, сделав какую-то оптимизацию или запустив какую-то активность в бэкграунде, которая плодит много объектов, или заняв статическую память, ты, как программист ReSharper, можешь задеть самую чувствительную часть, к которой пользователи наиболее трепетно относятся – typing, переключение между редакторами, движение каретки — то, что должно работать вообще без каких-либо задержек.
— Как это вообще можно тестировать?
— Это практически не поддается регрессионному тестированию. Одним из важнейших критериев корректности любого теста на производительность является повторяемость результата. Это работает, если у тебя стабильная виртуальная машина на сервере, на котором нет другой нагрузки. А когда у тебя typing тормозит на каждый 10-й символ, а девять проходят — это довольно тяжело уловить.
— Непонятно, как сформулировать метрику, в которой это можно увидеть.
— И не всегда просто фиксится, когда влияние одного кода на другой происходит. И если ты занимаешься Code Completion’ом, а он тормозит из-за того, что окошко юнит-тестинга, например, сейчас работает юнитест, который в бэкграунде отображает свой output. Вполне реальный сценарий.
— Правда ли, что это лечится иными подходами к самой разработке, как примерно Дима Иванов рассказывал? И второе — правда ли, что в этом месте единственное, что работает – это пользовательский фидбек?
— Да, это работает. Это работает так: каждый наш разработчик, когда у него что-то тормозит, берет профилировщик, находит проблему, осознает ее и коммуницирует. Это догфудинг во всех его проявлениях и тщательная отработка скриншотов, которые приходят к нам от пользователей. Другие языки, с которыми они работают, другие виды солюшенов.
— Много таких скриншотов?
— Несколько в день. Часто бывает, что тормозит не ReSharper, а какой-нибудь экстеншн к ReSharper’у, экстеншен к Visual Studio или сама Visual Studio. Ну или что-нибудь, что вообще не поддается никакому анализу.
— Вы в этом случае идет в Microsoft или к тому, кто делал этот экстеншн для ReSharper?
— В Microsoft очень тяжело достучаться, и мы не тратим время на это. Если ты хочешь чтобы Microsoft что-то пофиксил, тебе нужно быть очень активным. Грубо говоря, взять свой компьютер и отослать в Microsoft, чтобы они его проанализировали. А когда к нам приходит фидбэк, со сценарием, который мы даже толком не можем воспроизвести, никто из Microsoft смотреть его не будет. Потому что у них своего фидбека хватает.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Канун Нового Года — время чудес. В преддверии нового года мы все вспоминаем год уходящий и строим планы на следующий. И надеемся, что все проблемы останутся в прошлом, а в новом году случится чудо, и мы заживём по-новому.
Какой же Java разработчик не мечтает о чуде, которое осенит его и позволит стать Самым Крутым На Свете Java Программистом.
Хорошие новости: я хочу рассказать как раз о таком чуде.
Имя ему — автоматические тесты!
Фу, тесты?
Да. Настоящим мастером своего дела вас сделают не чудо-фреймворки, не микро/пико/нано сервисы, а дисциплина. Дисциплина, которая говорит, что программист может считать дело законченным не тогда, когда код готов, а тогда, когда к нему написаны и запущены автоматические тесты. И если с юнит-тестами всё более-менее ясно, то UI-тесты пока остаются для разработчиков тёмным лесом.
Да ну, это же нудно?
О нет, поверьте мне! Написание грамотных автотестов — это хороший вызов, тут есть над чем пораскинуть мозгами. И это может быть очень весело и интересно. Только надо использовать правильные инструменты.
Правильный инструмент для написания UI-тестов — это:
Selenide
Selenide — это библиотека для написания лаконичных и стабильных UI тестов с открытым исходным кодом.
Selenide — идеальный выбор для разработчиков, потому что у неё очень низкая кривая обучения. Вам не придётся заморачиваться со всеми этими техническими подробностям, на которые обычно тестировщики-автоматизаторы тратят так много времени: нюансы работы с браузерами, типичные проблемы с таймингом и аяксом.
Посмотрим, как выглядит простенький тест на Selenide:
public class GoogleTest {
@Test
public void user_can_search_everything_in_google() {
open("http://google.com/ncr");
$(By.name("q")).val("selenide").pressEnter();
$$("#ires .g").shouldHave(size(10));
$("#ires .g").shouldBe(visible).shouldHave(
text("Selenide: concise UI tests in Java"),
text("selenide.org"));
}
}
(естественно, вместо Google здесь будет ваше веб-приложение)
Что здесь происходит?
Вы открываете браузер всего-навсего одной командой open(url)
Вы ищете элемент на странице командой $.
Вы можете найти элемент по имени, ID, CSS селектору, атрибуту, xpath и даже по тексту.
Вы совершаете некие действия с элементом: в данном случае вводите текст командой val() и нажимаете ввод с помощью команды pressEnter().
Вы проверяете результат: ищете все результаты поиска с помощью $$ (она возвращает коллекцию элементов). Вы проверяете размер и содержимое коллекции.
Этот тест легко читается, не правда ли?
Этот тест легко пишется, не правда ли?
А главное, этот тест легко запускается. Убедитесь сами:
Погружаемся глубже
Конечно, в жизни не всё так просто. Написание автотестов подразумевает кучу проблем, ведь не зря разработчики так их боятся — больше, чем любого наисложнейшего фреймворка или технологии.
Но и здесь Selenide облегчает нашу жизнь, решая большинство этих проблем из коробки.
Давайте рассмотрим типичные проблемы UI-тестов подробнее.
Проблемы с аяксом и таймаутами
В наше время веб-приложения все сплошь динамические. Каждый кусочек приложения может быть нарисован/изменён динамически в любой момент времени. Это создаёт проблемы для автоматических тестов. Тест, который ещё вчера был зелёным, может внезапно стать красным безо всяких изменений в коде. Просто потому, что браузер сегодня встал не с той ноги и запустил вон тот javascript чуточку медленнее, и тест успел кликнуть кнопочку раньше, чем она до конца отрисовалась.
Это прям вечная проблема у всех. Поэтому автоматизаторы пихают везде «слипы».
Тем более удивительно, насколько простым и надёжным способом Selenide решает эту проблему.
Если коротко, в Selenide каждый метод умеет немножко подождать, если надо. Люди называют это «умными ожиданиями».
Когда вы пишете
$("#menu").shouldHave(text("Hello"));
Selenide проверит, существует ли элемент с ID=«menu». И если нет, Selenide чуть-чуть подождёт, проверит ещё. Потом ещё подождёт. И только когда элемент появится, Selenide проверит, что у него нужный текст.
Конечно, нельзя ждать вечно. Поэтому Selenide ждёт не больше 4 секунд. Естественно, этот таймаут можно настраивать.
Не сделает ли это мои тесты медленными?
Нет, не сделает. Selenide ждёт, только если надо. Если элемент изначально присутствует на странице — Selenide не ждёт. Если элемент появился через 300 мс — Selenide ждёт только 300 мс. Это именно то, что вам нужно.
Множество встроенных проверок
А что ещё вы можете проверять на странице, помимо текста? Довольно много всего.
Например, вы можете проверить, что элемент видимый (visible). Если пока нет, Selenide подождёт до 4 секунд.
$(".loading_progress").shouldBe(visible);
Вы можете даже проверить, что элемент не существует. Если элемент всё же найден, Selenide предположит, что он вот-вот пропадёт и подождёт до 4 секунд.
$(By.name("gender")).should(disappear);
Вы можете делать несколько проверок в одной строке (т.н. «fluent API» и «method chain»), что сделает ваши тесты ещё более лаконичными:
$("#cv").uploadFile(
new File("cv1.doc"),
new File("cv2.doc"),
new File("cv3.doc")
);
И скачивание файлов тоже крайне просто:
File pdf = $(".btn#cv").download();
Тестирование «динамичных» веб-приложений
Некоторые веб-фреймворки (такие как GWT) генерируют совершенно нечитаемый HTML, не поддающийся анализу. Там нет постоянных ID, имён или классов.
Это прям вечная проблема у всех. Поэтому автоматизаторы пихают везде длиннющие «xpath» и вынуждены их поддерживать до конца жизни.
Чтобы решить эту проблему, Selenide предлагает искать элементы по тексту.
import static com.codeborne.selenide.Selectors.*;
$(byText("Привет, хабр!")) // находит элемент по тексту целиком
.shouldBe(visible);
$(withText("хаб")) // находит элемент по подстроке
.shouldHave(text("Привет, хабр!"));
Вопреки распространённому мнению, поиск элементов по тексту — не такая уж плохая идея. Между прочим, именно так ищет элементы реальный пользователь. Он не ищет элементы по ID или классу, и уж тем более не по XPATH. Он ищет по тексту. (ну, ещё по цвету, но это труднее поддаётся автоматизации).
Ещё в Selenide есть несколько полезных методов для поиска дочерних или родительских элементов. Это позволяет вам навигировать между элементами без опознавательных знаков.
Когда один и тот же элемент или страница используется во многих тестах, имеет смысл вынести логику страницы в отдельный класс. Такой класс называется Page Object, и их тоже очень удобно делать с Selenide.
Приведённый выше пример гугла можно переделать на page object таким образом:
public class GooglePage {
public SearchResultsPage searchFor(String text) {
$(By.name("q")).val(text).pressEnter();
return page(SearchResultsPage.class);
}
}
И для страницы результатов поиска:
public class SearchResultsPage {
public ElementsCollection getResults() {
return $$("#ires .g");
}
public SelenideElement getResult(int index) {
return $("#ires .g", index);
}
}
Но не злоупотребляйте пэдж объектами.
Хочу обратить ваше внимание, что UI-тестов должно быть мало. По той простой причине, что это всё-таки браузер,
аякс, javascript, а всё это сравнительно медленно и нестабильно. Напишите один-два UI-теста, которые проверят, что
приложение в целом работает: страничка открывается, текст отрисовывается, кнопки нажимаются, JavaScript не грохается.
А всевозможные комбинации и редкие случаи обязательно проверяйте с помощью модульных тестов.
Типичная ошибка — проверять всё через UI. Этим особенно страдают тестировщики в тех компаниях, где разработчики не пишут
модульных тестов. Бедным тестировщикам просто ничего не остаётся, кроме как городить огромную неповоротливую кучу медленных
и нестабильных UI-тестов и впрягаться в их пожизненную поддержку.
Хорошая новость в том, что вам не нужно всё это запоминать. Просто наберите $, точку и начните писать примерно, что вы хотите. Например «val» или «enter». И посмотрите, какие варианты предложит ваша IDE.
Используйте мощь IDE! Не засоряйте голову деталями и сконцентрируйтесь на бизнес-логике.
Сделаем мир лучше
У верю, что мир станет лучше, когда все разработчики будут писать автоматические тесты для своего кода. Когда разработчики будут спокойно вставать в 17:00 и идти к своим детям, не боясь, что они что-то сломали своими изменениями.
Поверьте мне, я чувствую себя уверенно оттого, что пока я ходил за кофе, мои тесты уже проверили мой код. И я точно знаю, что то, что я сдаю в тестирование — работает.
Давайте сделаем мир лучше с помощью автоматических тестов! Будьте уверены в своём софте, и вам не придётся скрещивать пальцы на удачу перед каждым релизом.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Обычная такая рептилоидная раса, возникающая из пучин глубокого космоса. Бац-бац из лазерного оружия со всех бортов! Потом сближение и абордаж, в завершение нападения кровавая резня на борту захваченного судна. Рептилоиды – люди слова: сказали «всех порежем», значит всех порежут, кто б сомневался. И растворяются в морозной черноте, только их видели.
Впрочем, разведка донесла. Если открыть игровую Энциклопедию, выяснится:
Точные координаты базирования цивилизации Учча-Та неизвестны. Принято считать, что это планета Дрро-Адда (так называемая Планета-Мать) планетарной системы в районе W-Девы (звездное скопление TDD67, тип «распластанная медуза», спектральный класс неизвестен).
Итак, местопребывание установлено: после пиратских нападении на мирные корабли рептилоиды скрываются на родной Планетоматери.
И что это дает мне как арт-директору в смысле намеков на дизайн персонажа? А ничего.
Но на первый взгляд плевое дело. Подумаешь, очередные гуманоидированные рептилии, коими интернет полнится! Тонны референсов, если поискать.
Отлично. Выдали задание художнику, он в оговоренные сроки слепил в ZBrush то, что попросили. Вот такого товарища, если конкретно:
Визуально пахнуло играми из 90-х: хорошее было времечко. Но – не проходит, однако. Неформат.
Следующую попытку я предпринял лично. Лепил также в Zbrush, очень увлекся, каждую чешуйку вылепил. Проперло, что называется. После Zbrush разверточка, диффузная карта в фотошопе, глаза притащил из 3d max, ну и финальная сборка в Keyshot:
Ага, все равно забраковали, по соображениям игровой вселенной. Сказали: слабо похож на гуманоида.
Ладно, пришлось сесть за проработку базы. Что там у нас в Энциклопедии написано?
«Вследствие условий своего пиратского существования Учча-Та редко доживают до старости, поэтому можно сказать: рептилоиды – раса молодых и сильных. Слабых умерщвляют при рождении: более сильные братья и сестры поедают их в гнезде. Самки, ввиду исключительной плодовитости, также умирают молодыми. До старости доживают лишь смотрители маяков станций дальнего обнаружения или служащие заброшенных колоний, до последнего дыхания поддерживая функциональность вверенной им техники».
Нет, не поможет.
Ладно, дадим задание концептеру, чтобы он отжался по полной и придумал наконец вариант, который бы всех устроил и мягко вписался в игру.
Сказано – сделано. Концептер отжался и придумал. При этом использовал любопытный способ эскизирования: лепил в Zbrush простую болванку задуманной формы, потом оперативно набрасывал в Photoshop основную идею.
В итоге за основу взяли пятый вариант.
Когда с внешним видом определились, я уселся за разработку эскиза. С ходу внес кое-какие правки, например, заменил оригинальный хвост на более привычный. Инновации не всегда хороши, иногда следует топать разъезженной колеей.
Моделька лепилась в Zbrush, доспехи делались в 3dmax (текстуры и развертки – исключительно для головы и открытых частей туши). Еще у рептилоида бионическая подставочка, но это так, аксессуар для размежевания с другими игровыми расами. Все в итоге собиралось в Keyshot, материалы брони взял из его библиотеки. В завершение небольшая проработка в фотошопе. Забыл сказать, всё делаем Hi Poly, нет смысла возится с ретопологией итп, конечный результат все равно 2d.
На данный момент космические пираты Уча-Та выглядят так:
Вариант окончательный, но ещё предстоит сделать расцветки костюмов, формы, ну и головы.
Теперь о логотипе. В нашей игре каждая космическая раса имеет логотип, даже пираты.
Рисовала художница. Сказала, что заложила в логотип пиратский характер рептилоидов. Красный и острые углы символизируют силу и агрессию, холодный зеленый цвет намекает на принадлежность к рептилиям.
Едем дальше.
Пираты на космических кораблях летают, а корабли откуда берут? Ну да, захватывают, а самый первый откуда взяли? Без производства не обойтись. Выходит, космические пираты – еще и искусные мастера?!
Обращаемся к Энциклопедии и выясняем: «С особенным интересом Учча-Та относятся к гум-ресурсам, предпочитая брать в плен не низкоквалифицированный вспомогательный персонал и даже не высококвалифицированных бойцов или пилотов со штурманами (которых ввиду специфического устройства своих кораблей все равно не могут использовать), а специалистов мирного профиля: инженеров, ученых, техников. При пленении таких гуманоидов им выходит послабление: высока вероятность того, что они будут съедены в последнюю очередь, а если пленным повезло быть отправленными на Планету-Мать – что они будут использоваться там по своей первоначальной специальности. Сами Учча-Та не склонны заниматься производством, особенно если это не производство вооружений или космической техники: для подобных целей они используют квалифицированных рабов».
Понятно, пираты организовали шарашки, в которых используют высококвалифицированный дешевый труд. По крайней мере, корабли у них оригинальной системы.
Решено было делать корабли в форме летающих тарелок. Да, банально. Но космических рас много, кто-то должен и на летающих тарелках перемещаться?! Поздно спорить, какой из рас больше подошла бы форма летающих тарелок: решение принято, ни шагу назад.
Придумывать стали от самого большого и самого мелкого, потом пошли к центру. Поставили перед концепт-художником задачи:
1) форма тарелки должна иметь агрессивный вид,
2) обшивка должна быть уникальных цветов, чтобы не повторяться с другими расами.
Модификации рисовали поверх, посредством добавления деталей на основную форму, это сильно экономило время. Времени, как известно, всегда не хватает.
Вот чистовые концепты фрегатов Уча-та:
О технических характеристиках читаем в Энциклопедии: «Учча-Та бороздят космические просторы на кораблях с двигателями на антиматерии (Стигма Магнитно-Эфирная Сингулярность), с высоко технологичной системой захвата небольших челноков и универсальными узлами стыковки с вражескими судами – и тяжелым вооружением, разумеется. Все корабли Учча-Та обладают превосходными полетными характеристиками, высокой маневренностью и колоссальной живучестью».
Таким образом, пиратские летающие тарелки используют в качестве движка Стигма Магнитно-Эфирную Сингулярность. Это на случай, если кто спросит. Теперь вы знаете ответ.
Чистовые 3d-модели делались по-разному.
3d-моделлеров у нас несколько, у каждого свой подход. Один сначала делает корабль в Maya, другой – сразу в 3Dmax, кто-то – в XSI. В любом случае работа принимается в 3dMax: освещение, маты и чистовой рендер делаются именно в нем.
В будущем финальный этап хочется перенести в KeyShot, так будет быстрее.
Разумеется, у каждого 3d-шника свой подход к текстурированию. Кто-то целиком развертку делает, кто-то – частями. Кто-то рисует в фотошопе детали, некоторые ударяются в хайполи, один запекает AO, другой нет, но в итоге укрупненный вид корабля все равно добивается в фотошопе.
У вас наверняка возник вопрос, а зачем так прорабатывать 3d-модель, если результат все равно в 2д? Ответ прост. Любую модель корабля можно крутить и смотреть по кругу с разных сторон, в приемлемом размере и детализации, для этого мы сделали 60 рендеров по кругу и слепили в спрайт, вот зачем.
Еще подборка кораблей Учча-та:
Космические станции пиратов не стали делать тарелками, не хотелось переборщить. Поэтому добавили разнообразия, но выдержали в стиле.
Концептер – тот же, что делал персонажей, – придумал болванку в 3dMax, потом обрисовал детали концепта в Photoshop. Применимость методы подтвердила работа с космическими станциями. Готовая в виде утвержденного эскиза болванка сразу уходила 3d-моделлеру на доработку. Очень удобно, ускоряет процесс.
Как-то так.
Пост заканчивается, а работа над образом космических рептилоидов продолжается.
Вот думаю, неплохо бы добавить пиратам чуток интеллигентности. Если судить по Энциклопедии, они ей не чужды.
«Начальные знания Учча-Та получают в бесплатных школах. Пираты Знака Крови продолжают обучение на дорогостоящих факультетах Военно-Инженерной, Военно-Космической и Военно-Медицинской академий, а пираты Знака Земли на бесплатных Технологическом, Медицинском и Расоведческом факультетах Академии Коллегии. Знания, приобретенные в Академии Коллегии, позволяют выпускникам быть специалистами в технологиях всех рас, досконально знать анатомию всех рас, свободно разговаривать на всех языках ГООР и понимать нюансы внутренней жизни каждой из рас, населяющих Галактику. Это позволяет не только обслуживать технику на Материнской Планете и всех колониях, но и разбираться в технических новинках, выпускаемых другими цивилизациями.
С такой великолепной научной подготовкой Учча-Та без труда копируют любой агрегат или аппаратный узел для применения его в своих транспортных системах, хотя бы впервые с ним столкнулись. Часто удается достичь большего эффекта за счет исправления чужих ошибок, что позволяет экономить немалые средства на долгих исследованиях и экспериментах. Тем самым любая оказавшаяся у Пиратов технология автоматически становится собственностью расы и успешно применяется в войне».
Думаю, не приделать ли к их фейсам пенсне, могут же ящеры быть от природы подслеповатыми? Впрочем, тщета.
Столько часов, души в эту игрушку вбухано. Хочется поделиться переживаниями.
Да, чуть не забыл. Если кто-то захочет узнать о рептилоидах Учча-Та больше, вот, Энциклопедия рекомендует книги:
• Чо-Пачонг. Пиратские цивилизации: исходящая от них опасность и способы предохранения. Почупонг, 4129-й хронопарсер.
• Рептилоидная цивилизация Учча-Та. Общегалактический справочник «Все обо всем». Мурландия, 891,71Е + 28.
Правда, не уверен, что они уже опубликованы. Никак не могу овладеть принятой в игрушке хронологией.
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Джон Хортон Конвей утверждает, что не работал ни дня в своей жизни. Этот отрывок из биографии «Гений за игрой» показывает, какие серьёзные математические теории, вроде сюрреальных чисел, могут появиться из развлечений и игр.
Грызя указательный палец левой руки своими старыми обломанными британскими зубами, с набухшими старческими венами, с задумчиво нахмуренной под давно нестриженными волосами бровью, математик Джон Хортон Конвей без сожаления тратит своё время на раздумья и теоретические изыскания. Хотя он будет утверждать, что ничем не занимается, ленится, и играет в игрушки.
Он работает в Принстоне, хотя славу он обрёл в Кембридже (будучи сначала студентом, а затем профессором с 1957 по 1987 года). Конвей, 77-и лет, утверждает, что не работал ни дня в своей жизни. Он имеет в виду, что тратит почти всё свое время на игры. И в то же время, он профессор Принстона по прикладной и вычислительной математике (сейчас уже почётный). Член Королевского сообщества. И признанный гений. «Титул „гений“ часто неправильно используют»,- говорит Перси Дьяконис, математик из Стэнфорда. – Джон Конвей – гений. При этом он может работать в любой области. И у него чутьё на всякие необычные вещи. Его нельзя поставить в какие-то математические рамки".
Надменная атмосфера Принстона как бы не совсем подходит в качестве базы для такого игривого человека. Здания построены в готическом стиле и затянуты плющом. В этой среде хорошо ухоженная эстетика не выглядит старомодной. И по контрасту, Конвей -неряшливый, вечно с загадочной миной на лице, нечто среднее между Бильбо Бэггинсом и Гэндальфом. Обычно его можно найти, слоняющимся без дела в департаменте математики на третьем этаже в общей комнате. Департамент находится в 13-этажном здании Файн Холла, самом высоком здании Принстона, на крыше которого расположены вышки операторов Sprint и AT&T. А внутри количество профессоров примерно равно количеству студентов. Обычно в компании студента, Конвей устраивается либо на одной из кушеток в общей комнате, или в алькове у окна в коридоре в одном из двух кресел, смотрящих на доску. Оттуда Конвей обращается к знакомому ему гостю, цитируя Шекспира со свойственной ему ливерпульской живостью:
Welcome! It’s a poor place but mine own!
(перефраз из комедии «Как вам это понравится»: «Вот бедная девственница, герцог, невзрачная вещица, герцог, но собственно мне принадлежащая»).
Вклад Конвея в математику включает бессчётное количество игр. Более всего он известен как изобретатель игры «Жизнь» в конце 1960-х. Мартин Гарднер, ведший колонку в журнале Scientific American, назвал её «самым известным детищем разума Конвея». Это игра про клеточный автомат – машину с группами клеток, которая эволюционирует по шагам в дискретном времени. Клетки трансформируются, меняют форму и эволюционируют во что-то другое. «Жизнь» играется на решётке, где клетки напоминают микроорганизмы, рассматриваемые под микроскопом.
Правила игры
Строго говоря, это не совсем игра. Конвей называет её «бесконечной игрой без игрока». Музыкант и композитор Брайан Ино вспоминает, как увидев однажды демонстрацию этой игры на мониторе музея Exploratorium в Сан-Франциско, испытал «интуитивный шок». «Вся система настолько прозрачна, что не должна приносить сюрпризов,- говорит Ино. – Но сюрпризов там хватает – сложность и органичность эволюции точечных форм полностью превосходит предсказания». И, как сказано диктором в одном из эпизодов телешоу Стивена Хокинга Grand Design: «Вполне возможно представить себе, что нечто вроде игры „Жизнь“ с несколькими простыми законами, может воспроизвести достаточно сложные вещи, а может даже и интеллект. Это может потребовать решётки в миллионы квадратиков, но в этом не будет ничего удивительного. В наших мозгах – сотни миллиардов клеток».
«Жизнь» стала первым клеточным автоматом, и остаётся самым известным. Игра привела к тому, что клеточные автоматы и подобные симуляции стали использовать в сложных науках, где они моделируют поведение чего угодно, от муравьёв до автомобильных пробок, от облаков до галактик. И она стала классикой для тех, кто любит бесцельно проводить время. Зрелище групп клеток игры, видоизменяющихся на экране компьютера, оказалось, вызывает опасное привыкание у студентов, изучающих математику, физику и компьютерные науки, как и у всех людей, у которых был доступ к компьютерам. В одном из военных отчётов армии США утверждалось, что потраченные за наблюдением за игрой «Жизнь» часы стоили правительству миллионы долларов. Ну, по крайней мере, так гласит легенда. Ещё утверждают, что когда в середине 70-х игра стала быстро набирать популярность, она работала на четверти всех компьютеров мира.
Обзор форм жизни, которые можно найти в игре / из письма Мартину Гарднеру [кликабельно]
Когда на Конвея накатывает тщеславие (а это бывает часто), он открывает какую-нибудь новую книгу по математике, находит алфавитный указатель, и раздражается, что его имя чаще всего цитируют только в связи с игрой «Жизнь». А кроме неё огромное количество его идей, расширивших математику, весьма разнообразно. Например, его первая любовь – геометрия, и как следствие, симметрия. Он выделился, открыв нечто под названием «созвездие Конвея» – три спорадические группы в семействе таких групп в океане математической симметрии. Крупнейшая группа основана на решётке Лича, представляющей собой наиболее плотную упаковку сфер в 24-мерном пространстве, где каждая сфера соприкасается с 196560 другими сферами. Он также пролил свет на крупнейшую спорадическую группу, «монстра Фишера — Гриса», в гипотезе «Monstrous Moonshine». А его крупнейшее достижение, по крайней мере, по его собственному мнению – открытие нового типа чисел, названных «сюрреальными числами». Это континуум из чисел, включающий все вещественные числа (целые, дробные, иррациональные), а кроме них все бесконечности, бесконечно малые величины, и т.д. Сюрреальные числа, по его определению – «бесконечные классы странных чисел, доселе невиданных человеком». Возможно, они смогут описать всё, от бесконечного космоса до бесконечно малых квантовых величин.
Но удивительнее всего то, как Конвей наткнулся на них: играя и анализируя игры. Как в мозаике Эшера, где птицы превращаются в рыб. Сконцентрируйтесь на белом, и вы увидите птиц. Сконцентрируйтесь на красном, и вы увидите рыб. Конвей наблюдал за игрой типа го, и видел в ней нечто другое – числа. А когда он увидел эти числа, он находился под впечатлением несколько недель.
В свои лучшие дни в Кембридже в 1970-х годах, Конвей, вечно в сандалиях, в любое время года, входя в общую комнату департамента математики, обычно объявлял о своём прибытии громким хлопком рукой по одной из балок в центре комнаты. И это действие отдавалось звоном. Звон означал начало нового дня игр. Особенно интересной была одна из игр, фатбол (Phutball, AKA философский футбол).
Правила фатбола
Игра начинается с одной фишки («мяча»), которую располагают на центральном перекрестии квадратной решётки – например, для игры в го. Два игрока садятся с противоположных сторон доски и ходят по очереди. На каждом ходу игрок может либо положить одну белую фишку («человека») на любое свободное пересечение, или выполнить последовательность прыжков.
Для прыжка мяч должен находиться рядом с одним или несколькими людьми. Он двигается по прямой (вертикали, горизонтали или диагонали) на первое свободное пересечение за человеком. Человек, которого перепрыгнули, удаляется с поля. Если проводится прыжок, тот же игрок может прыгать и дальше, всё время, пока мяч оказывается рядом хотя бы с одним человеком – или же может прекратить ход в любой момент. Прыжки не являются обязательными – можно вместо этого разместить человека на поле.
Игра кончается, когда последовательность прыжков заканчивается на краю или за краем доски, ближайшем к оппоненту («гол»), и в этом случае выигрывает тот, кто делал прыжки. Серия прыжков может проходить ровно по голевой линии оппонента, не заходя за неё. Одним из интересных свойств фатбола является то, что каждый ход может быть сыгран любым игроком.
Эту игру изобрёл Конвей, но при этом он сам в неё играет не очень хорошо.
По факту, правила фатбола позволяют игроку, сделавшему очень плохой ход, спросить «можно, я поплачу?», и если ему разрешают, он берёт ход назад и переигрывает. Но даже и в этом случае Конвею не удаётся хорошо играть в эту игру, и вообще он не особенно удачно играет в любые игры – по крайней мере, не очень часто выигрывает. Тем не менее, он участвовал в бесконечном количестве игр в общей комнате, поднимая их до уровня, достойного для серьёзных научных изысканий. Но при этом он иногда позволял себе внезапно вскакивать, хватался за трубу под потолком и раскачивался на ней взад и вперёд.
Эти представления не сделали его главным акробатом департамента. Тут его обошёл Фрэнк Адамс, тополог, увлекающийся альпинизмом, который любил залезать под стол, не касаясь пола. Конвей находил его пугающе, невозможно серьёзным математиком. Профессор астрономии и геометрии, Адамс имел репутацию человека, которому трудно угодить, лекции которого трудно слушать – и человека, строго относившегося к себе. Коллеги считали, что его честолюбие зиждется на его периодических нервных срывах. Адамс работал, как одержимый, что и доставляло беспокойство Конвею. Он был уверен, что Адамс не одобряет его пассивную расслабленную манеру. И это заставляло Конвея чувствовать себя виноватым, и думать, что его должны уволить – и он думал о жене и постоянно увеличивающейся группе своих дочерей, которых необходимо было содержать.
Он женился на Эйлин Хоуи, преподавательнице французского и итальянского языков, в 1961 году. «Он был необычным молодым человеком, что и привлекло меня,- говорит она. – Мы с Джоном вскоре после знакомства пошли в ресторан, и я стояла, ждала, пока он откроет мне дверь. А он мне сказал – ну проходи, что стоишь! Большинство молодых людей открывали двери, пододвигали стулья, и всё такое. Но ему это не приходило в голову. Он думал по-другому. Вот дверь, ты стоишь перед ней, почему бы её не открыть? Наверно, в этом есть логика».
После замужества у них родилось четверо дочерей, с периодами в один, два и три года. Конвей запоминал их годы рождения как 1960-й плюс числа Фибоначчи: 1960 + 2, 3, 5, 8 = 1962, 1963, 1965, 1968.
И Конвей не зря беспокоился о возможности потерять работу. К 1968 году он мало чего достиг. Всё, что он делал – это играл в игры в общей комнате, изобретал и переизобретал правила игр, которые он находил скучными.
Конвей играет в «Жизнь» в 1974 году
Конвею нравились игры, в которых происходят физические ходы. Он постоянно играл в нарды на небольшие ставки (деньги, мел, просто на интерес). При этом он так и не достиг высот в этой игре. Он часто рисковал, принимал дубли, когда этого не следовало делать, и поднимал ставки до 64 раз от первоначальной, просто чтобы посмотреть, что случится. И постоянно говорил о математике. Например, «задача Конвея про пианино», в которой спрашивается: какой наибольший объект можно передвинуть за прямоугольный угол в коридоре фиксированной ширины?
Ему было не так интересно выиграть в нарды, как интересно исследовать имеющиеся в игре возможности. Ему нравилось специально проигрывать, оставаясь в хвосте с наихудшими игроками. Его соперники часто теряли бдительность и начинали проигрывать. А затем он делал свой ход. Обычно эта стратегия не срабатывала. Но иногда ему везло (случайность – элемент игры в нардах, и поэтому она не поддаётся строгому научному анализу), и тогда он делал головокружительную победу.
В то время, как Конвей подсел на нарды, другие его коллеги опасались играть в них подолгу, а иные и вовсе отказывались, опасаясь, что втянутся в игру и их исследования будут заброшены. Другие утверждали, что Конвей является плохим примером для студентов. Но это и был его план.
Одним из студентов был Саймон Нортон, вундеркинд, посещавший Итонский колледж и получивший степень в Лондонском университете, пока он учился в последнем классе средней школы. Прибыв в Кембридж, и будучи уже опытным игроком в нарды, Нортон легко вписался в компанию. Он умел очень быстро проводить в уме вычисления, и стал протеже Конвея, решая для него задачи, которые тот решить не мог. Он следил за всеми задачами, решавшимся всеми и каждым, подглядывал, подслушивал, прерывал любого криками «неправда!», когда замечал у него ошибку. У него также был внушительный словарный запас, что нравилось Конвею. Он был известен способностью решать анаграммы. Например, однажды кто-то выкрикнул анаграмму «phoneboxes». Ещё до того, как кто-либо успел поднять голову и понять, что происходит, Нортон провозгласил: «Xenophobes!».
В основном Конвей играл в глупые детские игры — Dots and Boxes, Fox and Geese, а иногда он играл в них с детьми, в основном со своими четырьмя дочерьми. И, конечно же, со своими приспешниками – часто в игры, которые те изобрели, чтобы понравится своему лидеру. Колин Воут придумал игру COL, а Саймон Нортон – SNORT, и обе игры заключались в раскрашивании областей. Также Нортон придумал игру Tribulations, а Майк Гай парировал, выдав Fibulations – обе игры, похожие на ним, одна основанная на треугольных числах, а другая – на числах Фибоначчи. Конвей придумал Sylver Coinage, в которой два игрока по очереди называли разные положительные целые числа, но им нельзя было называть число, являвшееся суммой любых из названных ранее чисел. Первый игрок, называвший единицу, проигрывал.
Многие игры вошли в книгу «Выигрышные стратегии в математических играх» (Winning Ways for Your Mathematical Plays), написанную Конвеем и двумя соавторами, Элвином Берлекампом, математиком из Калифорнийского университета, и Ричардом Гаем из Университета Калгари.
Троица пионеров теории игр сошлась на конференции «Компьютеры в теории чисел» в 1969 году. Конвей – в третьем сверху ряду, второй справа (с бородой). Элвин Берлекамп – четвёртый ряд сверху, шестой справа (также с бородой). Ричард Гай – четвёртый ряд сверху, девятый слева (с полосатым галстуком). [кликабельно]
На написание книги ушло 15 лет, частично оттого, что Конвей и Гай любили позаниматься ерундой, и тратили время Берлекампа. Он звал их «парочкой болванов». И, тем не менее, книга стала бестселлером, несмотря на то, что необходимость печати в цвете и в необычных шрифтах отняла столько денег, что на рекламу их почти не осталось. Книга была учебником по тому, как выигрывать в играх. Авторы высыпали в неё теорий, как из рога изобилия, и добавили множество новых игр, подходящих для своих теоретических изысканий.
Конвей писал:
Мы изобретали новую игру утром для того, чтобы она служила приложением нашей теории. А после получаса исследования она оказывалась ерундой. Поэтому мы изобретали другую. В рабочем дне десять раз по полчаса, грубо говоря, и поэтому мы изобретали 10 игр в день. Мы их исследовали, просеивали, и примерно одна из десяти оказывалась достаточно хорошей для того, чтобы быть включённой в книгу.
Так они набрали игр без названий, и названия без игр.
У нас была «проблема женитьбы». Мы изобретали игру, и если она была хорошей, то возникала проблема как-то её назвать. Если имя не придумывалось, мы помещали её в папку «игры без названия». А затем щепетильный и любящий точность Ричад завёл ещё одну папку, «названия без игр». Все попытки изобрести имя для игры заканчивались изобретением кучи разных имён, которые плохо подходили к нужной игре, но сами по себе были неплохими. Поэтому они отправлялись в папку «названия без игр». Каждая из папок росла, и нам редко удавалось «поженить» между собой записи из двух папок.
Помню лучшее название без игры. Оно звучит как «не звоните нам, мы позвоним вам» (Don’t Ring Us, We’ll Ring You; ring – «звонить», а также – «кольцо», или «обводить кольцом»). У нас не дошли руки до изобретения игры, но суть её совершенно ясна: игроки рисовали бы на бумаге нечто, и цель бы заключалась в том, чтобы обвести кольцом своего противника. Для такой игры это было бы прекрасное название. Но саму игру мы так и не придумали.
Иногда Конвей ходил в гости к Мартину Гарднеру, и они обменивались материалами по математическим развлечениям. Это не обязательно были игры – это могли быть паззлы, и другие развлечения для нёрдов. Возьмём, к примеру, Алгоритм судного дня, который позволял определять день недели для любой даты. И хотя он демонстрировал этот трюк с подросткового возраста, алгоритм придумался во время визита к Гарднеру. Конвей прилетел в Нью-Йорк и ждал, пока его друг заберёт его из аэропорта. Он ждал, и ждал… А Гарднер всё не появлялся.
Сначала я подумал – ладно, он появится через пять минут. Но я ждал там очень долго – не знаю, может целый час. И я начал думать: «А что, если он не появится?». У меня даже не было его телефона. А даже если бы и был, я не знал, как звонить по телефону в Америке. Поэтому мне оставалось только сидеть там и надеяться.
Гарднер опоздал больше, чем на два часа, вбежал в зал аэропорта, бешено размахивая руками, с извинениями и обещаниями: «Ты простишь меня, как только узнаешь, что я нашёл!». Он был в общественной библиотеке Нью-Йорка, где нашёл заметку, опубликованную в 1887 году в журнале Nature: «Как узнать день недели для любой даты». Статью написал Льюис Кэрролл. Он писал: «Наткнувшись на следующий метод подсчёта в уме дня недели для любой выбранной даты, я отправляю его тебе, надеясь, что он заинтересует кого-либо из твоих читателей. Сам я не очень быстро считаю, и обычно у меня уходит на этот подсчёт секунд по 20. Но думаю, что у быстро считающего человека это может занять менее 15 секунд».
Гарднер не мог отказать себе в изготовлении фотокопии заметки, но к копировальному автомату была длинная очередь. Он встал в неё, но она очень медленно двигалась. К тому времени, когда стало ясно, что он опаздывает забрать Конвея, он уже простоял 30 минут, и решил, что ещё 15 минут ему хватит. Он считал, что оно того стоит, и знал, что Конвей согласится с ним.
продолжение следует
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
