Как сделать свою IDE уровня IDEA

Некоторое время назад я опубликовал пост, в котором поднял тему низкого уровня качества моего любимого инструмента — PyCharm, и спросил: что делать? Данная проблема видится мне совершенно обескураживающей: 21-й век на дворе, а единственная доступная мне профессиональная IDE развивается по принципу «лучше — больше, но хуже». Имеется около десятка багов, исправление которых я лично жду годами, не говоря уже о тех проблемах, которые мне стало лень зарепортить. Количество багов растёт каждый год с постоянной скоростью, а в качестве оправдания я слышу рассказ о зависимости количества багов от количества пользователей. Альтернатив нет, а пилить свою IDE — почти нереально. Так что же делать?

Среди потока эмоциональных комментариев меня особо заинтересовал один — никем не замеченный, в котором пользователь VISTALL скромно сообщил, как он решил эту проблему для себя. Он сделал свой форк IDEA для .NET и C# — Consulo IDE. Для меня лично такое заявление стало полной неожиданностью. Извините, если кто-то не разделяет моего удивления, но для меня это совершенно непостижимо так же, как вездесущие вечные баги в PyCharm. Ведь IDE разрабатывают большие команды разработчков, а он решил сделать свой форк, пусть даже и форк, но свой, который нужно поддерживать и развивать самому… Как??? Этот вопрос я решил задать лично автору форка — Валерию Семенчуку, а заодно и много других вопросов. Слово за слово, получилось небольшое интервью, надеюсь, интересное не только мне...

— Валерий, давно ты знаком с IDEA?

— Честно говоря, уже забыл, когда познакомился с IDEA (вроде бы с IDEA 7, но не факт). Плагины я начал писать с IDEA 8. После появления IDEA Community Edition началась новая ветка в истории. Медленно я начал изучать платформу, что позднее вылилось в пулл-реквесты и в диалоги на трекере (и не только там). Но были и неприятные истории. Например плагин к Play 1: после какой то очередной правки со стороны платформы плагин стал вести себя нестабильно (toolwindow не закрывался, а превращался в светло-зеленый прямоугольник). Фикса не было, плагин сам был закрыт (его код). И вот вместо того, чтобы ждать фикс, я попросту написал плагин с нуля, т.к накипело. И с того времени я быстрее напишу свой плагин (или фикс), чем буду ждать исправлений.

— Сколько плагинов ты написал на текущий момент? Можешь перечислить самые интересные?

— К IDEA были написаны плагины Play, Lombok, и несколько безымянных плагинов. Также я пытался восстановить C++ плагин к IDEA, но был огорчен тем, что анализ был написан на С++ (и не был открыт авторами). Позднее почти все мои плагины переросли в плагины к моему форку IDEA. Также я написал более 10 новых плагинов. Самые интересные — это, конечно, поддержка .NET и C#.

— Как так получилось, что ты решил форкнуть IDEA?

— Первый мой публичный форк IDEA был для поддержки фреймворка Lombok. Первая проблема состояла в том что IDEA имеет свой анализ java файлов, и не было возможности расширить анализ без изменения самой Java реализации. Вторая проблема — это то, что Java прибита гвоздями в IDEA: нельзя просто заменить Java реализацию на пропатченую версию. Было много спорных вопросов в моем решении проблемы — в итоге дальше форка оно не ушло.

— А были еще и непубличные?

— Да. Я игрался с компилятором Java (javac) и поддержкой мною созданных фич в IDEA. С тех пор я практически всегда сидел на своих билдах IDEA.

— Я так понимаю, ты на этом не остановился?

— Да. Как автор плагинов я видел проблемы, и старался их исправить через патчи либо через пулл-реквесты. Часть была принята, а часть до сих пор находится в подвешенном состоянии.

— Видимо, это были архитектурные исправления? Я могу себе представить, насколько сложно добиться принятия таких патчей. Ведь у проекта есть свои архитекторы со своим мнением, у проекта есть свои планы, и твои патчи могут быть для них как минимум сомнительными, а то и вовсе несовместимыми с их точкой зрения.

— Большинство моих патчей были маленькие и не задевали глобальных вещей. Насчет больших изменений я поднимал несколько задач в трекере и на форуме. Из самых глобальных — я хотел выровнять Java реализацию с другими плагинами. Суть в том — что IntelliJ IDEA позиционируется в основном как среда для разработки на Java, в итоге часть интерфейса прибита гвоздями к Java-фичам.

Это можно увидеть, например, когда открываешь Project Structure в Node.js проекте, или в том же Node.js проекте видны пункты меню для Java.

— Чем тебе это мешало?

— Банальный вопрос — зачем пользователю скачивать весь Java стек разработки для того, чтобы работать с C#, например.

— А Rider для C# они на тот момент не предлагали?

— Нет. На данный момент Rider — это гибрид Resharper и IntelliJ. Назвать её полноценной IDE на базе IntelliJ я не могу, ибо весь анализ (и не только) лежит на плечах Resharper, который запускается параллельно с Rider. Он отвечает за все фичи, которые касаются .NET платформы.

— Что он из себя представляет твой форк?

— Главная задумка — это сделать универсальную IDE подобную IDEA, но Java будет плагином, а не частью платформы.

Также хотелось исправлять (по возможности) баги, которые находил. Закрытость почти всех плагинов создавала ощущение “раба” ситуации. Зарепортил баг — и ждешь. Даже если бага исправлена, нужно ждать либо EAP, либо релиз. В итоге было решено сделать полностью открытый проект.

— Над IntelliJ IDEA работает целая компания, а ты — один. Неужели реально одному пилить свою IDE, пусть даже и на готовой платформе?

— На деле я не сам. По технической части мне помогает знакомый, как и с тестами. А вот с разработкой плагинов тяжело. Приходится выбирать самое главное из того, что нужно сделать, и не распыляться. А желания сделать что-то новое — есть, например язык F#.
Также периодически переношу изменения из IDEA в Консулу, но не все. Очень много спорных фич, или мешает Kotlin, который сейчас они стараются принести в платформу.

— Чем тебе мешает Kotlin? Его зашивают так же жёстко, как и Java?

— Проблема в другом. Они начинаю писать часть кода на Котлине. С их точки зрения — это нормально. А как со стороны стороннего форка, иметь “новый” язык в платформе — это “тяжелый груз”. При этом нужно учесть, что Kotlin-а ещё нет в Консуле.

— Когда-нибудь они полностью переведут свои IDE на Kotlin — что тогда? Как ты считаешь вообще, всё идёт к этому?

— На деле — код конвертируем. Конечно, большие кучки чего либо на Котлине я не переделываю. Да — рано или поздно так и будет. Если учесть, что Rider написан на Котлине, и не только он. Когда это наступит — это будет новая эра Консулы. Эра возрождения или вымирания — покажет время :)

— В прошлом своём посте я поднимал тему забагованности IDEA. Вот и ты говоришь, что отчасти баги и скорость их исправления натолкнули на создание форка. С чем пришлось столкнуться по мере исправления багов? Много ли их там? Как тебе вообще код IDEA в целом?

— Я унаследовал почти все баги IDEA, также я имею немного своих. Код IDEA, славящийся своей “документацией” (сарказм), вполне понятен. Но встречаются внутренние вещи, которые не понять, если ты не работаешь в JetBrains.

— Я вот замечал, что в некоторых меню первый знак подчёркивания не отображается. А вместо этого местами подчёркнутым отображается символ, идущий за потерянным знаком подчёркивания. Такое есть в разных местах: “File -> Open Recent”, “Run -> Prifle”, “Run -> Concurrency Diagram”. Только в последней версии это починили в “Open Recent”, но проблема остаётся в “Run”.

— Судя по проблеме — это лишняя обработка Mnemonic в тексте меню. Просто нужно запретить обработку mnemonic. Видимо, кто-то забыл, когда в очередной раз правил этот код. Не понимаю почему такие баги должны висеть долго. Беглым поиском проблемы находится вот такой коммит.

— Честно говоря, такие ошибки смотрятся ужасно непрофессионально. Интересно, насколько стары эти баги. Ты их успел зацепить в Consulo?

— Беглым тестом — немного. В Recent Projects я не вижу проблемы. А вот в Run Configurations я вижу эту багу. Фикс на эту багу займет где то 10 минут.

— Когда я открываю эти меню, я долго всматриваюсь, чтобы найти нужный элемент. Я мучался с “Open Recent” очень долго — не знаю сколько. Найденный мною тикет висел полтора года. А ты показываешь коммит, в котором добавлен всего один параметр. И неизвестно, сколько еще провисит ошибка в “Run”. Какие тикеты, по твоим наблюдениям, в JetBrains закрывают быстрее? Добавление поддержки имодзи? :)

— Имодзи — часто запрашиваемая фича. И для ее реализации нужно править JRE. Я за то, что бы добавить, но не в ущерб другим.

— Поскольку ты переносишь изменения из IDEA, то, наверное, следишь за тем, какие фичи там добавляются. Есть ли такие фичи, которые ты не стал переносить из-за их принципиальной ненадобности в IDE?

— Editor Background Image. Я вовсе не понимаю смысл этой фичи. Из архитектурных соображений я не перенес реализацию External Compiler (jps внутри IDEA). Ибо спорная реализация, которая порождает дубликаты. Возможно, я верну эту подсистему, если решу архитектурные проблемы. К этому списку присоединяется прозрачный скролл. В редакторе это смотрится слишком ужасно. Со времен IDEA 8 я видел смены UI для скроллов в редакторе, пока что они ищут золотую середину. Но тестить на пользователях без возможности вернуться на старый UI — это плохо (у меня есть задача 2010 года где я жаловался на юзабилити скролла).

— А ты в своей Consulo как-то улучшаешь UI, помимо поддержки HiDPI?

— Да. Как известно, в IDEA нету возможности нормальной смены UI Theme (Laf), ибо много компонентов имеют “захардкоденную” отрисовку, а также цвета.

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

— Когда-то “захаркоденная” отрисовка была одной из основных проблем на пути к появлению темной темы в IDEA. Но сделать хорошее решения у них не получилось, в итоге в IDEA есть два режима Light / Dark. И для каждого режима есть свой набор цветов которые никак не изменить (адекватно конечно). Хочется сделать нормальное решения чтобы дать юзерам возможность кастомизации интерфейса под себя. Есть несколько IDEA плагинов которые это делают. Но все же они встречают непреодолимые преграды для этого — очередной хардкод.

— Много там ещё такого неприятного хардкода встречается? В смысле, не в темах, а в чём-то ещё, что приходится переделывать.

— Да, приходится встречать призрак прошлого с тех времен, когда IDEA имела только Java реализацию. В платформе есть проверки на java language / java file например.

— На что ты делаешь упор при выборе новых фич? Каким фичам отдаешь предпочтение? Развитие какого функционала ты считаешь самым важным в Consulo, а какой приходится откладывать за недостатком ресурсов?

— В свое время я отложил все проблемы касаемые веб сервисов. И больше был занят поддержкой C# / Mono / Unity. Четыре месяца(сентябрь 2016) назад я решил переделать всю веб часть. Перешёл на Jenkins, написал сервис для пользователей и новый репозиторий для плагинов и платформы (в свою очередь это добавило возможность автоапдейта).

После закрытия беты второй Консулы я хочу сделать поддержку .NET Core.

— В чём ты видишь отличие своего подхода к разработке IDE от того, который используют в JetBrains? Кроме того, что ты ориентируешься на универсальную платформу.

— Первая разница — в том, что всё, что доступно для юзера, можно увидеть на гитхабе в виде исходников. Также можно влиять на саму разработку.

Второе — это более быстрые релизы. В текущий момент в канал “release” поступают билды каждый месяц (beta — каждую неделю, alpha — каждый день).

Я хочу добится более агрессивной смены API. Также активно поддерживать разработчиков сторонних плагинов. Сам помогаю разработчику Perl плагина к IDEA (и не только) — играю роль ходячей энциклопедии по платформе.

Это — из самых основных отличий.

— Ты говоришь “можно влиять на разработку”. И никто не скажет юзеру “это наш бизнес”, да? Один человек жаловался, что ему так и ответили, когда он предлагал что-то поменять в IDEA.

— Мне никто не платит, такое я не скажу. Да, могут быть спорные реквесты, но всё решаемо. Я не планирую продавать ни один из компонентов Консулы.

— Ты пробовал посчитать хотя бы примерно, сколько времени уже потратил на работу над Consulo? Есть ли в этом смысл? Может быть эффективнее было бы потратить это время на работу, за которую платят?

— Работаю над Консулой я с 2013 года. Смысл очень простой: Консула — моя основная среда для разработки. Если я встречаю баг — я исправляю его в течении дня, а не жду по несколько месяцев (очередной релиз IDEA например).

— Сколько сейчас человек пользуются Консулой на постоянной основе? Это возможно как-то достоверно подсчитать?

— Достоверно — нет. Увы сервис статистики у меня написан на коленке, и не даёт точной информации. А так — до 2 тысяч на первой версии, и более 400 человек на второй (которая с недавних пор доступна для скачивания, но имеет статус беты). С февраля 2017 года, первая версия больше не доступна для загрузки.

— Как часто пользователи присылают пулл-реквесты?

— Очень редко. Так как большинство пользователей у меня — это Unity (.NET платформа + C#), есть некие сложности в правке Java исходников. Также у меня хромает документация по всему проекту (более 100 репозиториев, и что в них — знаю только я), я очень медленно её дополняю. Но встречаются люди, которые делаю пулл-реквесты в несколько репозиториев одновременно (как общий фикс одной проблемы)

— А багрепорты и фича-реквесты? Как часто присылают, и как быстро ты на них реагируешь?

— Фичи — редко, баги — чаще. Сейчас я добился хорошей стабильности основного функционала, поэтому багов немного.

Реагирую я практически всегда в тот же день. Исправляю баги по мере приоритетности плагина, но если фикс простой — то исправляю в тот же день

— Как считаешь, по какой причине люди отдают предпочтения Consulo (те, кто отдают). Ты уже перечислил основные достоинства, но у меня ощущение, что это твоя точка зрения, то есть достоинства для тебя лично. А что нравится пользователям?

— Это просто. Консула была единственной нормальной средой C# для macOS. Хотя количество пользователей Windows + Linux догоняет macOS. Раньше была доступная только одна среда — это MonoDevelop (но это тихий ужас). Сейчас появились Visual Studio Code и Rider.

— Если пользователи продолжают прибывать, то, наверное, они находят в Consulo что-то такое, чего нет в других IDE? Что именно?

— Большая часть моей аудитории — это Unity разработчики, до сих пор нет хорошего аналога Консуле. Есть Rider который в статусе EAP, а в будущем будет платным.

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

— Не было, нет, и не будет. Это мое принципиальное решения по поводу закрытого функционала. Это одна из причин, почему я отошёл от IDEA. И возвращаться к этому я не собираюсь. Я хочу сделать открытый проект, а закрытый функционал будет мешать.

— А как на счёт пожертвований?

— Куда без них. У меня пока есть причины, которые мешают этому. В этом году постараюсь исправиться, и тогда наконец-то появится долгожданная кнопочка Donate.

— Каким бы ты хотел видеть будущее Консулы, и насколько, по-твоему, этого реально достичь?

— Вырасти в полноценную организацию/проект по разработке IDE (не только на Desktop). Реально ли? Да — но силами одного человека очень долго.

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

Больше IDE — хороших и разных!

Let's block ads! (Why?)

Свои потоки ввода-вывода в C++ с помощью std::streambuf

Создание однопользовательской игры: от идеи до прототипа

Слушатели нашей программы «Менеджмент игровых проектов» temoon и Mazoo сейчас участвуют в GamesJamKanobu 2017 с необычной физической экшн-головоломкой, где можно изменять направление гравитации. Называется игра Graviman.

Под катом вы найдете подробный рассказ Артема и Тани про работу над этим проектом от зарождения идеи и до создания прототипа. Ну а скачать прототип и поиграть в игру можно на странице проекта на джеме. Если игра вам понравится, обязательно за нее проголосуйте.

Идея

Люблю игры и в последнее время точно для себя осознал, что хочу их делать.
Именно за этим я пришел в ВШБИ – научиться, собрать команду единомышленников и начать делать игру. Хотелось сделать нечто крайне простое и в то же время законченный продукт, работая над которым можно будет пройти полный цикл разработки и который также станет проектом для выпускной защиты.

В то время я делал первые шаги буквально во всем: начал постигать 3D-моделирование, изучать Unity; в ВШБИ постоянно открывалось что-то новое: диздоки, аналитика, игровая экономика, психология игрока. И вот в один из вечеров, сидя в электричке, я смотрел очередной урок по созданию «змейки» в Unity, и меня осенило!

Буквально за пару дней до этого я смотрел видео об инди-разработчиках и там был кусок про FEZ. Меня очень зацепила USP вращения двухмерного мира. Я захотел сделать «змейку» с механикой из FEZ. В голове все выглядело блестяще. Змейка должна была есть яблоки в текущей двумерной проекции, при этом сам ее мир был трехмерным, и его нужно вращать не только вправо-влево, но и вверх-вниз.

За несколько часов я накидал первый прототип с вращающимся кубом и змейкой из примитивов. На следующий день еще подправил и дал поиграть друзьям. Я объяснил управление, и просто стоял и смотрел, как они играют. Сразу понял: не было мотивации его вращать. Можно просто есть появляющиеся яблоки, как в стандартной «змейке». Тогда я решил добавить препятствий на поле, причем таким образом, что в разных проекциях они бы перекрывали доступ к какой-то его части и для того, чтобы туда попасть, если там вдруг появилось яблоко, нужно было поле повернуть, т.е. сменить проекцию.

Это была самая хардкорная «змейка» в истории: никто не мог предсказать, куда она поползет после очередного поворота — люди постоянно врезались в препятствия или в хвост. Идея, а вместе с ней и прототип, были выкинуты в корзину без сожалений.

Спустя некоторое время, я вдохновился другой известной инди-игрой: VVVVVV. И уже на её USP (вместо прыжка – смена гравитации вверх-вниз) мой мозг наслоил 3D.

Первый, второй и третий опыт

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

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

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

Нужно сказать, что именно тогда были придуманы все основные механики, которые перекочевали в ту версию, которая есть сейчас, даже несмотря на то, что во втором прототипе гравитация менялась не глобально у всех предметов в мире, а только у игрока, превращая его в этакую «муху», умеющую ходить по стенам.

Уровни я создавал самостоятельно, моделируя в Blender. Из-за неопытности на это уходили дни, в один из которых родился прародитель той демо-версии, что есть сейчас. Именно тогда я начал задумываться над геймплеем, пытаясь улучшить восприятие игроками довольно сложной механики. Хотелось сделать управление простым и естественным, а нарастание сложности – максимально плавным. Отдельное спасибо преподавателям ВШБИ, которые играя в мою игру давали обратную связь и советы.

Первый шоукейс

В феврале этого года в ВШБИ проходил лекционный день, где все желающие могли присутствовать на открытых лекциях. Также там был организован шоукейс игровых проектов выпускников и тех, кто учился на программе по геймдеву на тот момент. Я решил участвовать. Фактически, именно тогда проект перешел из стадии идеи в стадию разработки.
В ночь перед показом я вообще не спал – собирал прототип, «полировал» уровень. Для показа у меня был стол, стул и старый ноутбук с Linux. Я показывал как новый уровень, так и один из предыдущих прототипов, где немного отличались механики. Пытался оценить что больше «зайдёт». В тот день у моего стенда остановилось порядка 15 человек: у каждого я собрал бесценный отзыв, пообщался.

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

Создание команды

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

Со слов Mazoo

Привет всем!
Я тоже учусь в ВШБИ, и с самого начала моей основной целью было сделать хоть маленький, но работающий прототип. Идей и черновиков разных игр у меня уже накопилось к тому времени много, но они так и оставались на бумаге. Специально для обучения в ВШБИ я начала прорабатывать мобильную игру про кота, такую пошаговую стелс головоломку-адвенчуру (разумеется, с прокачкой :)). На такой игре лучше всего отработать все те техники, которые нам дают. Погрузилась в Unity, чтобы самой сделать прототип. Но нужна команда.
Поэтому смотрела по сторонам – кто что из сокурсников делает. Наши преподаватели призывали: «Объединяйтесь в команды!» и сейчас я понимаю, насколько это правильно.
Что я могу дать команде? Во-первых, я математик, поэтому вся математическая часть может быть на мне. Во-вторых, и это для меня важнее – это истории в игре. Последние пару лет я активно учусь всему, до чего могу дотянуться (от Курсеры до Сreative Writing School) о том, как рассказывать истории с помощью игр. Но конечно в первую очередь нужны были программисты :)
Первая игра temoon, 3D змейка, была прикольная, но не цепляла. А вот когда он показал первый прототип Graviman, сразу стало ясно, что в игре есть фан. Так и представился такой инди-Portal. Поэтому, когда temoon предложил объединиться, я согласилась. В этой игре есть вызов – как с помощью механик и головоломок, идя от геймплея, показать историю, и я этот вызов приняла.
Но дело было не только в игре. За время учебы присматриваешься к людям и становится очевидно, с кем ты сможешь сработаться, а с кем нет. У temoon есть несколько качеств, которые были для меня важны. Во-первых, он четко знает, чего хочет и уверенно идет вперед. Во-вторых, он мыслит механиками, совершенно перпендикулярно моему мышлению, поэтому мы не перетягиваем «одеяло» придумывания геймплея друг у друга, а дополняем. Ну и третье важное качество — он умеет слушать и соглашаться. И четвертое — не соглашаться тоже умеет :) Поразмыслив надо всем этим, я решила пока отложить кота и сосредоточиться на Graviman’е.
Изначально было несколько идей, как оправдать то, что герой может менять гравитацию – космос, лаборатория, или подсознание. От идеи космоса отказались – в этом сеттинге нужно быть специалистом, чтобы не сделать шляпу. Лаборатория уже есть в Portal. А вот подсознание – богатая тема, тут можно придумывать что угодно, хотя обилие вариантов — это и минус тоже.
Мне хотелось сделать не просто бродилку по подсознанию, а историю, в которой главный герой преображается, и где ему чрезвычайно важно по своему подсознанию пройти. Так родилась концепция того, что вся игра – это один миг, в который герой находится между жизнью и смертью, в клинической смерти. И он должен пройти от конца к самому началу, чтобы найти ресурс, чтобы жить. Или решить, что пора освободиться.
Но на бумаге написать идею, конечно, проще, чем в игре. По задумке со второго уровня в игре появляются персонажи, и большой вопрос – как их вставить в наш минималистичный мир, чтобы они смотрелись гармонично.
Должны ли они падать при изменении гравитации? Как их нарисовать? Может, это должны быть тени? Как с минимумом текста (или вообще без него) передать то, что происходит между персонажами? Может быть, от персонажей, вообще, нужно отказаться? Как сделать так, чтобы сюжет шел от геймплея, и игра не превратилась в симулятор ходьбы?
Вопросов много, решать их приходится от возможностей. Сейчас к нам присоединились четверо художников и у меня большие надежды на то, что совместно мы выработаем единый стиль, и соответственно, это поможет в построении сюжета.

Джем

На первых парах, не являясь до этого командным игроком, я продолжал принимать некоторые решения самостоятельно, за что «огребал» от партнёра, но со временем перестал совершать такие ошибки, научились договариваться и процесс работы над игрой пошел полным ходом.
Кстати, одним из таких несогласованных решений было участие в GamesJamKanobu 2017. В один миг проект перешел в очень активную стадию. Мы нашли аж четверых художников, готовых работать «за идею»!

Состояние перманентного кранча очень сплотило. Одно из важных решений, которое мы приняли в самом начале — это ежедневный stand-up (правда, он у нас почти в полночь), где каждый член команды в течение пары минут рассказывает, что он сделал за сегодня, в чем у него возникли сложности и что планирует делать завтра. Таким образом, все остаются в курсе дел на проекте и мотивируют друг друга. К тому же — это отличный способ сразу увидеть проблемы и внести корректировки в работу.

И вот мы тут

На текущий момент в демо-версию сыграло более 400 человек, а сам проект находится в десятке лучших по выбору пользователей. В нашей команде 6 человек: продюсер/программист, гейм-дизайнер/сценарист, лид-артист, художник и два 3D-моделлера.

Вот ссылка на текущую реализацию нашего проекта на GamesJamKanobu 2017, где можно про нее подробно почитать, посмотреть, поиграть и даже проголосовать.

Будем рады ответить на ваши вопросы в комментариях.

Let's block ads! (Why?)

[Перевод] 7 важнейших изменений в гейм-дизайне с эры Nintendo 64

Старое снова становится модным. Достаточно посмотреть, например, на игру Yooka-Laylee компании Playtonic Games: ностальгический 3D-платформер в стиле Banjo-Kazooie и Donkey Kong 64. Playtonic была готова к этому проекту — многие сотрудники команды раньше работали в Rare, создававшую классику 1990-х.

С помощью Yooka-Laylee команда Platonic пытается показать, как 3D-платформер в классическом стиле может выглядеть на современном игровом рынке. После успешной кампании на Kickstarter Yooka-Laylee будет выпущена в апреле этого года.

Не нужно говорить, что со времён Nintendo 64 в играх изменилось многое. Мы попросили сотрудников Playtonic рассказать нам о том, как технологические усовершенствования повлияли на различные области разработки игр, и что они значили для дизайнеров, художников, композиторов и директоров, участвующих в процессе разработки.

1) Готовые движки упрощают работу

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

«Большая разница заключается в том, что в эру N64 бóльшую часть игровых инструментов нам приходилось писать вручную для каждого проекта. Сегодня существуют не только движки типа Unity, но они ещё и сами по себе являются платформами, позволяющими сообществу разрабатывать собственные инструменты поверх движка», — говорит Крис Сазерленд (Chris Sutherland), руководитель проекта Yooka-Laylee (он был ведущим программистом Banjo-Kazooie).

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

«На N64 большинство ошибок приходилось исправлять инженерам-разработчикам. Сегодня благодаря таким разнообразным, стабильным и простым в работе наборам инструментов не обязательно разбираться в коде, чтобы исправлять ошибки», — рассказывает Сазерленд. «Это относится и к финальным этапам подготовки продукта, в которых нужно не только программирование. Благодаря этому можно более эффективно использовать сотрудников команды разработки».

2) Художники должны сдерживать себя

Иногда неограниченное воображение само по себе может стать проблемой. Технический арт-директор Yooka-Laylee Марк Стивенсон (Mark Stevenson) (раньше он был арт-директором Donkey Kong 64), поделился своими мыслями о том, как технологический прогресс вынуждает художников ограничивать себя, а не полагаться на технические ограничения оборудования.

«Разница в основном заключается в гораздо более мощном оборудовании и значительно усовершенствованных инструментах и технологиях», — говорит Стивенсон. Хотя всё это хорошо для расширения возможностей и оптимизации производительности и рабочих процессов, у таких преимуществ есть и обратная сторона. Нужно постоянно сдерживать себя и принимать разумные решения, чтобы достичь необходимых результатов и высокого уровня качества, не потеряв при этом контроля над ситуацией.

«Во времена N64 мы всегда стремились использовать оборудование по максимуму и раздвигать границы возможного для очень слабых технологий», — рассказывает Стивенсон. «Сегодня легко ощутить себя ребёнком в кондитерском магазине и пуститься во все тяжкие, поэтому имея команду таких размеров, как у Playtonic, нужно всегда чётко осознавать границы. Но разница заключается в том, что эти границы надо устанавливать самому, а не полагаться на ограничения технологий».

3) Персонажи стали живыми

Давайте посмотрим на дизайн персонажей в Banjo-Kazooie. В особенности на Банджо. Помните большого медведя с синим рюкзаком и подвижными пальцами?

Ваши воспоминания обманывают вас. Ничего подобного на Nintendo 64 не было. Детали и анимации персонажей — это ещё одна область, в которой игры сделали большой шаг с тех пор, как Банджо начал своё путешествие.

«Сегодня мы способны в анимации на гораздо большее», — делится Стив Мэйлс (Steve Mayles), арт-директор по персонажам Yooka-Laylee (он был художником по персонажам Banjo-Kazooie). «На N64 нам приходилось работать с минимальным количеством соединений — каждое дополнительное соединение снижало производительность. Поэтому у бедного старого Банджо даже не поворачивались глаза, не двигался рот и даже пальцы!»

«Сейчас мы можем создавать любое количество соединений. Из-за временных ограничений иногда некоторые соединения даже не анимируются, но при необходимости можно их использовать», — рассказывает Мэйлс. «Способ привязки геометрии к скелету позволяет теперь создавать гораздо более реалистичную анимацию по сравнению с твердотельными вершинами, с которыми мы работали на N64».

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

«Для персонажей мы можем сегодня создавать слои анимации (например, при беге они могут наклоняться), но всё равно нам всегда нужно оценивать, стоит ли добавлять определённые детали. Заметят ли их люди, или мы делаем это для собственного удовольствия? Иногда нужно просто прочертить линию и переходить к следующей задаче».

4) Размер имеет значение

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

«Создание окружений стало гораздо более сложным», — замечает арт-директор по окружениям Yooka-Laylee Стивен Хёрст (Steven Hurst) (бывший художник по окружениям Banjo-Kazooie). «Хотя инструменты творчества стали намного функциональнее, и модели создавать проще, детализированность и размеры миров значительно увеличились. Поэтому время производства стало намного больше, чем раньше, и для него требуется больше людей».

Разработка для нескольких платформ тоже имеет свои проблемы. В отличие от игр про Банджо, которые предназначались только для N64, Yooka-Laylee будет выпущена на разных консолях.

«При создании многоплатформенной игры ресурсы должны быть более масштабируемыми. Нужно больше внимания обращать на такие аспекты, как разные уровни детализации (Level of Detail), чтобы обеспечить плавную работу игры на различном оборудовании. Разработка для одной платформы проще, ведь мы знали её ограничения и возможности», — говорит Хёрст.

5) Больше полигонов — больше головной боли

Каким бы ни было развитие игровых технологий, возможности человека ограничены. Он не может изменить количество часов в дне или увеличить объём работы, выполняемый за неделю. И некоторые процессы, например, разработка персонажей, требует сегодня больше времени, чем нужно было десятилетия назад.

«Разработка концепта, модели и анимаций для персонажа на N64 занимали неделю (если вы работали столь же усердно, как я)», — говорит Стив Мэйлс. «Мы работали примерно с 500 полигонами, а сейчас используем десять тысяч. Конечно же, инструменты стали лучше, но даже в программах 1997 года работа над 500 полигонами была быстрее, чем сегодня — над десятью тысячами. Сейчас можно заложить на тот же процесс около месяца, и вы не сильно ошибётесь в оценках».

Из-за гораздо больших сроков остаётся меньше времени на ошибки, возврат назад или смену направления.

«Становится всё важнее обеспечить правильное развитие персонажа с самого начала разработки», — признаёт Мэйлс. «У нас относительно небольшая команда, и последнее, что нам нужно — переделывать свою работу. Чтобы „встать на правильный путь“, нужно, если потребуется, использовать множество людей и задать себе следующие вопрос: „Соответствует ли он стилю игры?“ „Выполняет ли он все требования дизайна?“ и так далее. Иногда внешний вид персонажа приводит к новым идеям в дизайне, так что эта работа проходит в обоих направлениях».

6) Детали против дизайна

Чем больше 3D-миры, тем больше в них можно посетить мест и проложить маршрутов. Но это также значит, что становится больше областей, в которых игрок может заблудиться.

«При планировании и дизайне миров в 3D гораздо проще достичь ощущения пространства, обеспечивать поиск пути и создавать важные для сюжета точки», — уверен ведущий креативный специалист Гэвин Прайс (Gavin Price) (ранее дизайнер Grabbed by the Ghoulies). «Однако создание языка дизайна для ненавязчивого ориентирования игрока на уровне и фокусировки его внимания стало гораздо сложнее».

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

«Мощь современных систем можно использовать для заполнения и украшения мира подробными деталями. Всё вокруг внезапно начинает выглядеть интересным и важным. Игрок может вслепую перемещаться по окружениям, никак не продвигаясь по сюжету игры. В результате у него возникает чувство неудовлетворённости», — говорит Прайс. «Во многих смыслах ограничения старых систем упрощали жизнь дизайнера уровней, потому что только важные части мира имели интересные детали».

7) Секрет в звуке

Хотя процесс сочинения музыки не сильно изменился, Грант Киркхоуп, композитор Yooka-Laylee (бывший композитор Banjo-Kazooie), рассказывает, как увеличение объёмов памяти позволило ему добавить в Yooka-Laylee более качественную музыку.

«Мой рабочий процесс написания музыки почти не поменялся», — говорит Киркхоуп. «Я по-прежнему сижу за клавиатурой и пытаюсь записать ту музыку, которая мне понравится. Однако значительно изменился уровень качества этой музыки».

Раньше большой проблемой был объём используемой памяти. Композиторам приходилось урезать музыку, чтобы она уместилась внутри картриджа N64.

«В те дни эпохи N64 мне нужно было использовать сэмплы инструментов, уменьшать их качество, но чтобы музыка при этом оставалась приемлемой, затем сжимать их, и только потом добавлять в мой крошечный набор MIDI, находившийся в картридже N64», — вспоминает Киркхоуп. «Мне выделили ограниченное количество памяти на всё, включая звуковые эффекты. Кажется, для Banjo-Kazooie это были 2 мегабита!»

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

«Сегодня я могу использовать библиотеки сверхкачественных сэмплов, которые звучат так достоверно, что их иногда трудно отличить от настоящих звуков», — говорит Киркхоуп. «Память ограничивает нас гораздо меньше, чем раньше. Пределы по-прежнему есть, но они не идут ни в какое сравнение с прошлым. Очевидно, что звук должен умещаться на диск, он сжимается и полного CD-качества не добиться, но разница со звуками для Banjo-Kazooie или GoldenEye колоссальна!»

Let's block ads! (Why?)

Переход с bash на zsh

Основы TCP/IP для будущих дилетантов

[Перевод] Как говорить с искусственным интеллектом?

Перевод поста Стивена Вольфрама (Stephen Wolfram) "How Should We Talk to AIs?".
Выражаю огромную благодарность Полине Сологуб за помощь в переводе и подготовке публикации

---

Содержание

— Вычисления — это сила
— Язык вычислительного мышления
— Понимание ИИ
— Что будет делать ИИ?
— Постановка целей для ИИ
— Разговор одного ИИ с другим
— Сбор информации: обзор миллиарда лет
— А что, если бы каждый мог писать код?
— Действительно ли это будет работать?
— Скажу больше

---

Еще совсем недавно идея иметь компьютер, который может отвечать на вопросы на английском языке, казалась научной фантастикой. Но когда мы в 2009 году выпустили Wolfram|Alpha, одним из самых больших сюрпризов (по крайней мере, для меня!) стало то, что мы сумели сделать наш продукт реально работающим. И теперь люди ежедневно задают личным помощникам несметное количество вопросов — на обычном разговорном языке.

Все это достаточно неплохо работает (хотя мы всегда стараемся сделать лучше!). Но как насчет более сложных вещей? Как общаться с искусственным интеллектом?

Я долго думал об этом, пытаясь совместить философию, лингвистику, неврологию, информатику и другие области знания. И я понял, что ответ всегда был перед моим носом, и лежал он в той сфере, которой я занимался последние 30 лет: Wolfram Language.

Может быть, это как раз тот случай, когда у вас есть молоток, и вы видите вокруг одни гвозди. Хотя я уверен, что дело не только в этом. По крайней мере, продумывание этого вопроса — хороший способ понять больше об искусственном интеллекте и его взаимоотношениях с людьми.

Вычисления — это сила

Первый ключевой момент (в четкому пониманию которого я пришел только после серии открытий, которые я совершил в фундаментальной науке) заключается в том, что вычисления — это очень мощная вещь, которая позволяет даже крошечным программам (например, клеточным автоматам или нейронным сетям) вести себя невероятно сложным образом. И этим может пользоваться ИИ.

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

Язык вычислительного мышления

Я видел свою роль в том, чтобы определить «куски» вычислений, которые люди будут использовать, — вроде FindShortestTour, ImageIdentify или Predict. Традиционные компьютерные языки были сосредоточены на низкоуровневых конструкциях. Но в Wolfram Language я начал с того, что мы, люди, понимаем, а затем попытался захватить как можно больше этого «понимаемого» в языке.

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

Можно задаться вопросом: зачем придумывать язык для всего этого? Почему бы просто не пользоваться, скажем, английским языком? Ну, для конкретных понятий вроде "ярко-розовый", "Нью-Йорк" или "луны Плутона" английский язык действительно неплохо подходит (и в таких случаях Wolfram Language позволяет людям пользоваться только английским языком). Но если попытаться описать более сложные вещи, разговорный английский довольно быстро становится слишком громоздким.

Представьте себе, например, описание даже довольно простой алгоритмической программы. Диалог в стиле теста Тьюринга быстро вас разочарует.

Но Wolfram Language построен именно для решения таких проблем. Он создан быть легко понятным для людей и учитывает особенности человеческого мышления. Также он обладает структурой, которая позволяет собирать воедино сложные элементы. И, конечно же, его легко могут понять не только люди, но и машины.

В течение многих лет я думал и общался на смеси английского и Wolfram языков. К примеру, если я скажу что-то на английском языке, то затем я смогу просто начать печатать продолжение моей мысли с помощью кода Wolfram Language.

Понимание ИИ

Но давайте вернемся к ИИ. На протяжении большей части истории вычислений мы создавали программы, для которых каждую строку кода писали программисты, понимая (за исключением ошибок), за что отвечает каждая строка. Однако достижение уровня ИИ требует более мощных вычислений. Пойти по этому пути означает выйти за пределы программ, которые люди могут писать, и расширить круг возможных программ.

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

На каком-то уровне это тревожит. Мы не знаем, как программы работают изнутри, или на что они способны. Но мы знаем, что они производят сложные вычисления, которые в некотором смысле слишком сложны для анализа.

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

На протяжении веков мы определяли те аспекты мира природы, которые мы можем понять, а затем использовали их для создания полезных технологий. И наш традиционный инженерный подход к программированию работает более или менее одинаково.

Но в случае с ИИ мы должны уйти с проторенной дорожки, лежащей в пределах Вычислительной Вселенной, и нам придется (как и в мире природы) иметь дело с явлениями, которые мы не можем понять.

Что будет делать ИИ?

Давайте представим, что у нас есть такой совершенный ИИ, который в состоянии сделать все, что связано с интеллектом. Может быть, он будет получать входные сигналы от множества IoT датчиков. Внутри него будут осуществляться все виды вычислений. Но что он в конечном счете будет пытаться сделать? Какова будет его цель?

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

Можно подумать, что, так как ИИ становится более сложным, в конечном итоге он будет преследовать какую-то абстрактную цель. Но это не имеет смысла. Потому что на самом деле нет такого понятия, как абстрактная абсолютная цель, выводимая чисто формально — математически или посредством вычислений. Цель определяется только по отношению к людям и соотносится с их конкретной историей и культурой.

"Абстрактные ИИ", не связанные с человеческими целям, будут просто продолжать делать вычисления. И, как это происходит с большинством клеточных автоматов и большинством природных систем, мы не сможем определить какую-либо конкретную цель этого вычисления.

Постановка целей для ИИ

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

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

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

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

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

Разговор одного ИИ с другим

Думать о том, как люди общаются с ИИ, это одно. Но как ИИ будут общаться друг с другом? Можно предположить, что они могли бы делать буквальный перевод имеющихся у них знаний. Но это не будет работать, поскольку два ИИ имеют разный «опыт», и используемые ими представления неизбежно будут различаться.

Так что в итоге ИИ (как и людям) придется прийти к использованию некоторой формы символического языка, который представляет понятия абстрактно (без конкретной ссылки на лежащие в их основе представления).

Можно подумать, что ИИ должны были просто общаться на английском языке; по крайней мере, таким образом мы смогли бы их понять! Но это не сработает. Поскольку ИИ неизбежно должны постепенно расширять свой язык, так что, если бы даже они начали с английского, то все равно вскоре вышли бы за его пределы.

В естественных языках новые слова добавляются тогда, когда появляются новые понятия, которые достаточно широко распространены. Иногда новое понятие связано с чем-то новым в мире ( «блог», «смайлик», «смартфон» и т.д.); Иногда это связано с возникновением новых различий между существующими понятиями («дорога» и «шоссе»).

Часто именно наука открывает нам новые различия между вещами путем выявления различных кластеров поведения или структуры. Но дело в том, что ИИ может делать это гораздо более масштабно, чем люди. Например, наш проект по идентификации изображений настроен на распознавание 10000 видов объектов, имеющих привычные наименования. Он тренировался на реальных изображениях и открыл многие различия, для которых у нас нет названия, но благодаря которым можно успешно разделять вещи.

Я назвал это "постлингвистическими понятиями" (или PLECs). И я думаю, что иерархия этих понятий будет постоянно расширяться, заставляя язык ИИ также постепенно расти.

Но как это поддерживается в рамках английского языка? Я полагаю, что каждая новая концепция может обозначаться словом, образованным из некоторого хэш-кода (вроде набора букв). Но структурированный символический язык (вроде Wolfram Language) обеспечивает более подходящую основу. Поскольку для него нет необходимости в том, чтобы единицами языка были простые «слова», такими единицами могут стать произвольные блоки символьной информации, — такие, как наборы примеров.

Так должны ли ИИ разговаривать друг с другом на Wolfram Language? Мне кажется, в этом есть смысл. При этом не имеет значения, как именно кодируется синтаксис (форма ввода, XML, JSON, двоичный, — что угодно). Важнее структура и содержание, которые встроены в язык.

Сбор информации: обзор миллиарда лет

В течение миллиардов лет, на протяжении которых жизнь существовала на Земле, существовало несколько различных способов передачи информации. Основной — тот, которым занимается геномика: передача информации на «аппаратном» уровне. Для этого у нас есть нервная система и, в частности, мозг, который получает информацию (например, из нашего проекта по идентификации изображений), накапливая ее из пережитого. Этот механизм используется в нашем организме для того, чтобы увидеть и сделать много других штук наподобие тех, что свойственны ИИ.

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

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

И именно здесь становится явной значимость языка, основанного на вычисляемых знаниях (вроде Wolfram Language), потому что он обеспечивает возможность обмена понятиями и фактами о мире, не требуя отдельного толкования.

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

Одним из возможных вариантов является описание цивилизации с ИИ — независимо от того, какой она может оказаться. И, возможно, это будет далеко от того, что мы, люди (по крайней мере, в нашем нынешнем состоянии) можем понять. Хорошая новость заключается в том, что, по крайней мере в случае Wolfram Language, точный язык, основанный на вычисляемых знаниях, не является непостижимым для человека; он может быть мостом между людьми и машинами.

А что, если бы каждый мог писать код?

Итак, давайте представим себе мир, в котором (в дополнение к естественному языку) повсеместно используется язык вроде Wolfram Language. Конечно же, такой язык гораздо чаще будет использоваться для коммуникации между машинами. Однако, возможно, что он станет доминирующей формой общения между человеком и машиной.

В современном мире лишь небольшая часть людей может написать компьютерный код — так же, как 500 лет назад лишь небольшая часть людей могла писать на естественном языке. Но что, если уровень компьютерной грамотности резко повысится, и в результате большинство людей смогут писать код, основанный на знаниях?

Именно естественный язык способствовал формированию многих черт современного общества. Какие возможности открывает код, основанный на знаниях? Самые разные. Сегодня вы можете получить меню в ресторане для выбора блюда. Но если бы люди могли читать код, можно было бы создать код для каждого варианта, чтобы вы могли легко внести изменения на свой вкус (на самом деле, что-то вроде этого скоро будет возможно (Emerald Cloud Lab) с помощью кода Wolfram Language для лабораторных экспериментов по биологии и химии). Еще одно следствие для людей, которые в состоянии прочитать код: вместо того, чтобы написать обычный текст, можно написать код, которым смогут воспользоваться как люди, так и машины.

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

Действительно ли это будет работать?

Хорошо: допустим, мы хотим использовать Wolfram Language для общения с ИИ. Получится ли это? Этот вариант уже воплощается в жизнь, потому что внутри Wolfram|Alpha и основанных на ней системах вопросы, формулируемые на естественном языке, преобразуются в код Wolfram Language.

Но как насчет более сложных применений искусственного интеллекта? Во многих случаях, когда используется Wolfram Language, мы имеем дело с примерами ИИ, — являются ли они вычислениями, производимыми с изображениями, или данными, или символьными структурами. Иногда вычисления включают в себя алгоритмы, цели которых мы можем точно определить (FindShortestTour); иногда цели менее точны (ImageIdentify). Иногда вычисления представляются в виде "того, что надо сделать", иногда — как "то, что надо найти", или "то, к чему стремиться".

Мы проделали долгий путь представления мира в Wolfram Language. Однако нужно сделать еще больше. Еще в XVII веке предпринимались попытки создать "философский язык", который каким-то образом символьно отражал бы суть всего, что только можно представить. Теперь нам нужно действительно создать такой язык. При этом необходимо будет охватить все виды действий и процессов, которые могут произойти, а также такие явления, как верования народов и различные психические состояния. Поскольку наши ИИ становятся все более изощренными и более интегрированными в нашу жизнь, представление таких вещей — важный шаг.

Для некоторых задач и мероприятий, мы, безусловно, не будем использовать чисто машинное обучение, и нам не придется строить какую-либо промежуточную структуру или язык. Но, поскольку естественный язык имел решающее значение в становлении нашего вида, постольку и владение абстрактным языком будет иметь важное значение для прогресса ИИ.

Я не знаю, как это будет выглядеть, однако можно представить себе использование какого-то чисто эмерджентного языка, создаваемого ИИ. Но в таком случае у нас, людей, не будет шансов понять то, что делает ИИ. Но в случае с Wolfram Language у нас есть мост: язык, который подходит как для людей, так и для ИИ.

Скажу больше

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

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

Другие статьи Стивена Вольфрама на Хабре, расширяющие понимание вопроса

• Стивен Вольфрам: “Внедряя вычисления повсюду”
• Стивен Вольфрам: Рубежи вычислительного мышления (отчёт с фестиваля SXSW)
• Искусственный интеллект в Wolfram Language: проект по идентификации изображений
• Вычисляемые знания и будущее чистой математики
• Книга Стивена Вольфрама «Элементарное введение в язык Wolfram Language»
• «Моя жизнь сквозь призму технологий...» — Стивен Вольфрам
• Краткая история появления Mathematica

Let's block ads! (Why?)

[Из песочницы] Генератор проектов

Похоже, я не предприниматель

N причин, чтобы использовать Create React App

Статья о статическом анализе кода для менеджеров, которую не стоит читать программистам

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

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

Наша компания занимается разработкой анализатора PVS-Studio, предназначенного для поиска ошибок в коде программ на языке C, C++ и C#. Идея проста: запускаем регулярно анализатор и изучаем участки кода, которые показались ему подозрительными. В общем, некий аналог автоматического code-review.

Любому менеджеру, да и самим программистам понятно, что качественный код лучше, чем некачественный. Понятно и то, что чем реже в программе проявляются глюки, тем лучше.

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

• «это инструмент для Макдональдса, а в нашей команде работают эксперты, и если у нас и бывают ошибки, то они связаны только с синхронизацией потоков»
• «мы не используем статический анализ кода, так как набираем только профессионалов выше среднего»

Думаю, если бы в момент таких дискуссий рядом присутствовал менеджер проекта, то немало программистов получило от него щелбан за гордыню. Каждый руководитель может вспомнить, как несколько дней искали ошибку, которая потом оказалась какой-то глупой опечаткой. Или менеджера может начать одолевать скепсис: если все так всё хорошо, почему приложение продолжает падать время от времени? Менеджеры не так радужно, как программисты, относятся к процессу разработки проекта и возникающим проблемам.

Рисунок 1. Программисты часто слишком оптимистичны, будучи уверенными, что всё прекрасно.

Поэтому я хочу раскрыть менеджерам тайну, которая на самом деле, конечно, никакой тайной не является. У программистов есть проблема с переоценкой своего уровня. Про это хорошо написано в статье "Программисты 'выше среднего'" (en). Процитирую отрывок:

Как вы оцениваете свой уровень как программиста (ниже среднего, средний, выше среднего)?

Согласно психологическим опросам среди разных групп, около 90% программистов отвечают «Выше среднего».

Очевидно, это не может быть правдой. В группе из 100 человек 50 всегда будут выше и 50 — ниже среднего. Этот эффект известен как иллюзия превосходства. Он описан во многих областях, но даже если вы об этом слышали, вы всё равно, вероятно, ответите «выше среднего».

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

Анализатор PVS-Studio находит ошибки в коде таких проектов как Qt, MSBuild, LLVM, GCC, GDB, Chromium. Разработчиков этих проектов никак нельзя оценить ниже среднего. Однако, это не мешает все новым и новым программистам отвечать, что их код качественен и для них анализ кода не актуален. Я в таких случаях люблю спрашивать: раз все кругом так хорошо и все такие профессионалы, то кто сделал вот эти 11000 ошибок? Вопрос, конечно, риторический, и я не жду ответа.

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

Кстати, на эту тему расскажу кое-что интересное. Недавно коллега проверял проект CryEngine V. Баг на баге. Коллега даже не досмотрел предупреждения уровня High, уж очень их много. А потом мы вдруг узнаем, что в последнее время у компании Crytek проблемы и некоторые программисты уже 3 месяца не получают зарплату. Нездоровая ситуация в компании отразилась на качестве кода. Интересно было увидеть такую явную взаимосвязь.

В общем, надо не стесняться заставлять программистов использовать статический анализ кода. Пусть даже не PVS-Studio, пусть это будет хотя бы Cppcheck (выполняет простые проверки, но зато бесплатен). Это уже будет большим хорошим делом. Программист, конечно, может капризничать, поэтому стоит проявить твердость.

Часто программисты ссылаются на то, что работа с анализатором отнимает время, заставляя просматривать ложные предупреждения.

Здесь я не сдержусь от сарказма: Да, да… Потратить один день на настройку анализатора, чтобы сократить количество ложных срабатываний, это много. А сидеть и неделю искать ошибку, это в самый раз, это нормально.

Proof: ошибка, на обнаружение которой было безуспешно потрачено около 50 часов, при помощи однократного запуска анализатора была обнаружена и исправлена менее чем за час.

Кстати, если нет нужды начать с поиска ошибок в старом коде, то интегрировать в процесс разработки статический анализатор очень просто. PVS-Studio может показывать ошибки, относящиеся только к новому или измененному коду (см. массовое подавление сообщений анализатора).

Следует скептически относиться к возражениям программистов на тему того, почему им не нужен статический анализатор. Им-то, может, он действительно не нужен. Он нужен проекту. Эта одна из методологий, такая же как, например, юнит-тесты, которая позволяет повысить надежность программы и, тем самым, сократить траты на её сопровождение. Чем быстрее какие-то ошибки будут найдены, тем лучше. Статические анализаторы позволяют выявлять ошибки на самом раннем этапе, т.е. сразу, как только они появятся в коде.

Рисунок 2. Учтите, некоторые программисты используют статический анализ неправильно.

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

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

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

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov. A post about static analysis for project managers, not recommended for the programmers

Let's block ads! (Why?)

Шаг за шагом: собираем и тестируем Интернет вещей на базе платформы SAP Cloud Platform

Два сапога Java: как прошли JBreak и JPoint

Новосибирская конференция JBreak и московская JPoint — два сапога пара: обе проходят весной, обе проводятся JUG.ru, обе — главные Java-конференции своего региона. А в этом году мы и вовсе устроили их на одной неделе (и даже выжили после такого). Поэтому рассказы «как всё прошло» для JBreak и JPoint решили объединить в один, скажем так, «breakpoint». Под катом — подробности и о Новосибирске, и о Москве.

С обеими конференциями в этом году произошло одно и то же событие: смена площадки. В Новосибирске ещё год назад стало ясно, что придётся искать место вместительнее, и им стал масштабный «Экспоцентр». А JPoint, продолжающий расти, в этот раз прошёл в конгресс-центре ЦМТ.

В программах обеих конференций появились обозначения, помогающие понять, для какой аудитории предназначен доклад: «Введение в технологию», «Для практикующих инженеров», «Хардкор» и «Готовьтесь, будет подгорать». Разумеется, эти обозначения немедленно породили прорву обсуждений и споров. Правильно ли выбрано обозначение у каждого доклада? Правильна ли классификация в целом? А какая была бы правильнее?

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

Также в обоих случаях мы решили улучшить онлайн-сопровождение: оперативно постить в Twitter и ВКонтакте качественные снимки, создать по Telegram-чату для JPoint и для JBreak. А Москве досталась ещё и «проапгрейженная» онлайн-трансляция: в перерывах между докладами, когда обычно зрителям трансляции нечего делать, в этот раз демонстрировались интервью со спикерами и репортажная съёмка. По итогам всех этих онлайн-активностей один из зрителей трансляции написал в том же Telegram-чате «Как будто на конференции находишься» — значит, получилось.

На JPoint из-за обилия стендов компаний (Сбербанк-Технологии, GridGain, Одноклассники, Альфа-Лаборатория, Deutsche Bank и не только) всю конференцию происходил какой-то экшен, связанный с ними: вот Deutsche Bank проводит собственные мини-выступления, а вот спикеры Барух Садогурский и Евгений Борисов «дерутся» у стенда Zalando, где можно снять гифку.

Горячие дискуссии на #jpointhttp://pic.twitter.com/4RNIxGfQ3Q

— Baruch Sadogursky (@jbaruch) April 8, 2017

А что с главным, ради чего все собрались — докладами? Программы двух конференций частично пересекались, но у обоих городов были и «эксклюзивы» (особенно у JPoint, где докладов попросту гораздо больше из-за двухдневности). Обо всех выступлениях не рассказать, пройдёмся по отдельным запомнившимся моментам:

Даже как-то скучно писать, но новый доклад Алексея Шипилёва (Red Hat) про сборщик мусора Shenandoah прошёл на ура в обоих городах. Никакой интриги! Но почаще бы в нашей жизни слова «никакой интриги» означали «все опять в восторге». После того, как Шипилёв сослался на «The Garbage Collection Handbook» как на главную книгу о GC, часть слушателей решила за неё взяться — в том числе спикер Тагир lany Валеев и наш собственный директор Алексей 23derevo Фёдоров.

Помимо технических деталей GC-алгоритмов, доклад запомнился многим фразой «чтобы найти мусор, надо думать как мусор». А Алексей на время своего слота настолько выжег собой инфополе, что даже в другом зале вспоминали о нём же (пусть и с комментарием «мы люди простые, среднеквадратичные отклонения не высчитываем»).

Саше Гольдштейну (Sela Group), автору книги «Pro .NET Performance», не привыкать к аплодисментам на .NET-конференциях. Но теперь он неожиданно для многих выступил на JPoint — и от джавистов тоже получил очень высокие оценки. Как вообще возможно с первой попытки покорить «чужую территорию»? Вероятно, помогло то, что объектом его внимания был Linux-инструмент BPF, помогающий в мониторинге Java-приложений: как рассказал нам Саша в интервью, изначально Linux-инструменты интересовали его сами по себе, а Java просто стала удобной точкой применения, потому что с .NET в Linux пока что негусто.

Любопытно, что сразу после своего доклада Гольдштейн оказался ещё глубже втянут в Java. Заинтересовавшись выступлением Андрея apangin Паньгина и Вадима Цесько (Одноклассники) о тонкостях работы Java-профайлеров, он тут же принялся контрибьютить в профайлер Паньгина на GitHub, не дожидаясь даже окончания конференции:

Yesterday @AndreiPangin and @incubos introduced their new JVM profiler; today I propose a PR w/ docs and a loader: https://t.co/gviFha4Hd9http://pic.twitter.com/p4fbloIm1s

— Sasha Goldshtein (@goldshtn) April 8, 2017

В отзывах на доклад Чарльза Наттера (Red Hat) про String новосибирцы жаловались, что вступительная теоретическая часть о кодировках слишком длинная. Действительно, Наттеру, живущему в стране с латинским алфавитом, может быть неочевидно, что российские программисты из-за кириллицы и так знают о кодировках не понаслышке. Зато это длинное вступление пришлось как нельзя более кстати в Москве, где на докладе Наттера возникли проблемы с проектором. Теоретическую часть Наттер как раз смог рассказать и без слайдов, а затем техника заработала ровно к тому моменту, когда он переходил к библиотекам joni и jcodings, и нужно было показывать на экране примеры кода. В итоге вовремя заработавший проектор сорвал столько аплодисментов, словно он и был докладчиком.

Тагир Валеев (JetBrains), рассказывавший в обоих городах о работе над инспекциями в IDEA, начал с чистосердечного признания «Польза моего доклада сомнительна» — но это не помешало многим с большим интересом слушать, что стоит за возможностью улучшить свой код одним нажатием в IDE. Если не задумываться, это может показаться простой механической работой по замене одних конструкций на другие, однако доклад показывал, насколько это не так.

Вариаций одной и той же конструкции, которые надо суметь распознать, может быть множество («даже Джон Скит не распарсил бы это reg exp’ом»). В нюансы документации необходимо вчитываться даже тогда, когда это кажется излишним («оказывается, вот в этом случае map.getOrDefault и map.putIfAbsent действуют по-разному, хотя оба появились в Java 8»). При этом документация может быть неполной («ну, на Stack Overflow я нашёл-таки ответ об этом, но речь об интерфейсе, завтра появится новая реализация, мы своей IDEA начнём ломать людям код, и что я в оправдание покажу, ссылку на Stack Overflow?»). А также есть множество неочевидных моментов вроде необходимости сохранить и разместить в «правильном месте» комментарии, когда код изменяется («Где пыль со стола? Там были записаны важные телефоны!»)

А кроме того, практическую пользу в этом случае можно было извлечь благодаря дискуссионным зонам, где спикеры после своих докладов подробно отвечали желающим на вопросы. Наверняка у множества разработчиков есть вопросы, связанные с IDEA — и здесь была удобная возможность задать многие из них. В результате дошло до того, что Тагир после конференции стал работать над исправлением бага, который ему прямо на JPoint и показали. На всякий случай уточним: это не означает, что конференция является официальным каналом приёма багов, для этого всё-таки есть YouTrack!

Никита Липский (Excelsior) присутствовал на обеих конференциях, но с совсем разными темами: в Москве он рассказывал про верификацию байткода, а в родном для него Новосибирске собрал полный зал зрителей докладом «Модули Java 9: Почему не OSGi?».

Казалось бы, доклад с таким названием должен быть очень коротким — достаточно повторить слова Марка Рейнхольда о том, что с помощью OSGi можно делить на модули проект, но только с помощью Jigsaw можно «распилить» саму JDK. Что можно к этому добавить? Оказалось, много чего. «Система активации бандлов в OSGi — это бомба замедленного действия: если JVM начнёт разрешать ссылки менее лениво, OSGi-приложения попросту перестанут работать», объяснял Никита землякам, и чем больше он рассказывал про OSGi, тем привлекательнее начинал выглядеть Jigsaw. А отдельную ачивку Липскому можно дать за общую живость выступления: доклад, где в начале цитируют Хармса, в середине исполняют со зрителями мантры, а в конце заявляют «Роды неизбежны», не может быть скучным.

Другим спикером с разными темами стал Егор yegor256 Бугаенко: в Новосибирске он говорил об Utility-классах, а в Москве об аннотациях. Зная Егора, несложно догадаться, что оба явления он нещадно критиковал, и, разумеется, у обоих его докладов стояли значки «Готовьтесь, будет подгорать». В презентацию на JPoint он даже успел включить отзывы, полученные от слушателей доклада на JBreak: «Автор — маньяк», «Егор в своём репертуаре: все гондурасы, а я Д’Артаньян».

Ещё в прошлом году, обсуждая с Егором «ООП будущего», Барух jbaruch Садогурский заметил, что провокационным выступлениям Бугаенко подходит формат «пять слайдов, а теперь давайте рубиться»: поскольку слушатели в любом случае начинают громко возражать Егору на пятой минуте доклада, стоит выступление и делать сразу дискуссионным. В этом случае так и было сделано — и активнее всех на JPoint рубился с Егором сам Барух, отстаивая пользу аннотаций. Алексей Шипилёв тем временем то выходил из зала, то заходил обратно, регулярно меняясь в лице. Мы не берёмся точно расшифровать его эмоции по поводу происходившего, но ощущаем, что они были сильными.

В Новосибирске Кирилл Толкачёв (Альфа-Лаборатория) говорил о граблях Spring Boot Test в одиночку, а в Москве к нему присоединился Евгений Борисов (Naya Technologies). Также Евгений выступил и с отдельным докладом о нюансах Spring — и самый крупный зал конференции оказался переполнен людьми. Самый яркий зрительский отзыв, пожалуй, такой: «После таких докладов у меня появляется ощущение, что логику Spring можно понять».

От Сбербанк-Технологий, ставших генеральным спонсором обеих конференций, на них было сразу несколько спикеров с совсем разными темами — от архитектурных решений в работе над платформой до создания DSL-языка для тарификации. Какой из докладов полезнее — судить зрителям, но наибольшее оживление в зале явно вызывало выступление о DevOps Олега olegchir Чирухина. Его формулировки вроде «Поскольку мы на Java-конференции, тут все разбираются в том, как выбесить админа» наглядно показывали, что работа в гигантской компании не означает автоматически скуку и «застёгнутость на все пуговицы».

Любопытно получилось с Kotlin: за считанные дни до JPoint внезапно вышло техническое превью Kotlin/Native, и в результате слова Андрея abreslav Бреслава о движении языка к мультиплатформенности подкреплялись свежим конкретным шагом в этом направлении. Оглядывая зал, Бреслав замечал, что вокруг наверняка находится множество «embedded на C» — и это означает потенциальный рынок для native-решений. А из зала спрашивали о возможной поддержке WebAssembly, и Андрей в ответ сравнивал текущее состояние wasm с бункером, откуда не достучаться ни до чего: мол, когда в проекте появится нормальный доступ к DOM, тогда можно будет говорить о его поддержке.

В общем, привычного по предыдущим конференциям «мяса» на JPoint и JBreak хватало. А было ли в программе любой из них что-то уникальное, что может никогда не пригодиться, зато навсегда запомнится? Пожалуй, для зрителей JPoint таким стал кейноут популяризатора математики Алексея Савватеева.

На конференциях JUG.ru кейноуты нередко отходят далеко от основной тематики, давая возможность «переключить мозг» (например, на прошлом JPoint выступала Евгения Тимонова, известная видеоблогом о животных). Но в этом случае получился интересный «промежуточный» вариант: хотя тематика лекций Савватеева и не относится к Java, многим джавистам она близка — вплоть до такого:

Вот так ты смотришь вечерами лекции Савватеева по теории групп, а потом видишь, что вы с ним на пару читаете пленарные доклады на #jpoint.

— Aleksey Shipilëv (@shipilev) March 3, 2017

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

На этом у нас всё — но помимо нас, участники тоже оказались активны и понаписали много сами:

• JPoint 2017. День 1
• JPoint 2017. День 2
• jpoint по горячим следам. Часть 0 из N: начало.
• jpoint по горячим следам. Часть 1 из N: банкет и его продолжение.
• Performance это праздник (хабрапост vladimir_dolzhenko)

А напоследок — фотография «Барух Садогурский гладит пушистый микрофон»:

Let's block ads! (Why?)

Flow + tcomb = типизированный JavaScript

Страховка от кибер-рисков

Как показало недавнее исследование «Лаборатории Касперского», потеря данных становится для бизнеса одной из наиболее серьезных угроз. По результатам опроса, 42% российских компаний хотя бы один раз за последний год теряли важную информацию из-за взломов или утечек данных. Треть компаний сообщила, что это случалось неоднократно. Средний ущерб в результате инцидента зависит от размера предприятия. Если для малого и среднего бизнеса он составляет 1,6 миллиона рублей, то для крупных компаний потери достигают 11 миллионов.

По оценкам экспертов, в мире ущерб от хакерских атак, совершенных за последние годы, составляет от $300 млрд до $1 трлн. И эти показатели имеют тенденцию к росту.

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

Какие кибер-риски являются основной причиной финансовых потерь? Топ3 – ущерб репутации компании, нарушение бизнес-процессов, выплаты клиентам за потерю данных.

Как защитить информационные системы персональных данных от кибератак и взлома сетей? Можно ли застраховаться от кибер-рисков — рисков операторов данных, возникающих в результате ежедневной работы с информацией и информационными системами? Готовы ли российские компании страховать подобные риски? И есть ли вообще такая возможность? Для этого страховые компании стали предлагать специально разработанные продукты.

Где застраховаться?

До недавнего времени в России этого рынка практически не было, вернее, он был очень узким, нишевым. Компании не вполне понимали, стоит ли им тратиться на страхование от кибер-рисков. Об этом задумывались, скорее, российские подразделения глобальных компаний, которые такие риски обычно учитывают. Трудно было найти страховые компании, предлагающие такие услуги как отдельный продукт. Тем временем в США к 2020 году этот рынок, по прогнозам PwC, достигнет $7,5 млрд. По оценкам PwC, одна треть американских компаний уже приобрела такие страховки.

Теперь и России ситуация меняется. Вслед за немногочисленными первопроходцами — компаниями Allianz и AIG, Willis и некоторыми другими, уже давно работающими в данном сегменте, на рынок выходят новые игроки. Так недавно компания «Страховой брокер Сбербанка» (на 100% принадлежит Сбербанку) объявила о начале продаж продукта страхования от киберугроз для компаний.  

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

Allianz представила свой продукт по страхованию кибер-рисков Allianz Cyber Protect в ноябре 2016 года. У AIG есть отдельный продукт по страхованию кибер-рисков CyberEdge.

CyberEdge: не только страхование информационных рисков

Компания AIG разработала программу страхования CyberEdge для защиты персональных данных на предприятии от последствий их утечки или незаконного использования. Подобное страхование необходимо любой компании, имеющей дело с данными, в особенности – с данными персональными.

CyberEdge Plus поможет обеспечить первичную финансовую поддержку и помощь в организации необходимых мер, если кибератака приведет к повреждению имущества компании, перерыву в производстве, травмам клиентов или других третьих лиц и повреждению имущества третьих лиц. Дополнительное покрытие по телесным повреждениям, повреждению имущества и финансовым убыткам также доступно в рамках продукта CyberEdge PC.

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

Для защиты персональных данных от хищения, действий хакеров, ошибок персонала и многого другого решение AIG также предоставляет клиентам доступ к услугам компаний, специализирующихся на кибербезопасности и расследованиях киберпреступлений, юридической консультации и антикризисному PR. Это инструмент для предотвращения убытков и преодоления последствий утечки данных. Он предоставляет профессиональную, круглосуточную, финансовую помощь для сотрудников, клиентов и членов их семей, которые пострадали от хищения персональных данных.

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

От каких именно рисков защищает программа страхования CyberEdge? Она включает в себя обязательные (A-C) и дополнительные (D-F) покрытия.

Вид покрытия	Что в него входит
А: Убытки в связи с нарушениями данных.	— Убытки в результате нарушения данных. — Убытки в результате нарушения корпоративной информации (коммерческие тайны, профессиональная информация, бюджеты, перечни клиентов и др.). — Убытки в результате нарушения безопасности компьютерной системы (заражение вирусами, уничтожение, модификация или удаление информации, физическая кража или утеря аппаратного обеспечения и др.).
В: Административное расследование в отношении данных.	— Убытки страхователя в связи с расследованием в результате нарушения законодательства или иных нормативно-правовых актов в связи с обработкой данных или корпоративной информации, за которые страхователь несет гражданскую ответственность, в размере, не превышающем расходы на защиту.
С: Расходы на реагирование при нарушении данных.	— Расходы на реагирование и упреждающую программно-техническую экспертизу. — Расходы на восстановление репутации страхователя и физических лиц, на уведомление субъектов данных. — Расходы на мониторинг. — Расходы на восстановление электронных данных и программ.
D: Ответственность за содержание информации.	— Убытки страхователя в результате публичного раскрытия, вызванного ошибкой, ложным заявлением, вводящим в заблуждение заявлением или упущением в связи с осуществлением ими деятельности в области мультимедиа, которые приводят к нарушению авторского права, права собственности, слогана, товарного знака, торгового наименования, нарушению доменного имени, плагиату, нарушению издательского права или незаконному присвоению или краже идей; любому неверному освещению, публичному раскрытию фактов частной жизни, совершенным без умысла, вследствие записанного, произнесенного или транслируемого высказывания, включая, без ограничения, эмоциональное потрясение или психическую боль в связи с такими действиями; или вторжению, посягательству на частную жизнь, противозаконному вторжению или лишению собственности, совершению правонарушения или несанкционированному извлечению информации.
E: Виртуальное вымогательство.	— Убытки от виртуального вымогательства: денежные средства, выплаченные страхователем с письменного согласия страховщика для ограничения или прекращения угрозы безопасности, которая иначе может вызвать убыток страхователю; и стоимость проведения расследования для определения причины угрозы безопасности. Убытки от виртуального вымогательства не включают любые выплаты лицам, ответственным за угрозу безопасности.
F: Перерыв в работе сети	— Убытки от сбоев в работе сети в размере неполученной прибыли (доходы, которые должны были быть получены, уменьшенные на величину расходов, которые должны были быть произведены).

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

B – это покрытие расходов при административном расследовании в отношении данных со стороны регулирующих органов. Покрытие С включает расходы на программно-техническую экспертизу, позволяющую установить причину утечки; на восстановление репутации компании и /или ее должностных лиц; на уведомление субъектов данных и мониторинг; а также расходы на восстановление электронных данных.

Полис CyberEdge – это комплексное решение, которое не только компенсирует возможные потери от утечки данных, но и позволит успешно преодолеть кризис, возникший по причине утечки.

От каких рисков страхует программа CyberEdge.

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

Какие преимущества дает CyberEdge?

Данная программа страхования позволяет свести к минимуму последствия кризиса, вызванного утечкой данных. Для этого привлекаются специалисты в области юридической поддержки, ИТ-расследований и антикризисного PR, расходы на которых компенсирует AIG. Оказывается юридическая поддержка при расследовании государственных органов, проводимой в связи с нарушением персональных данных.

Компании-партнеры AIG предоставляют услуги своих аккредитованных специалистов.

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

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

Наличие полиса CyberEdge говорит о том, что компания заботится о своих рисках и рисках своих клиентов, что она не будет тратить собственные средства на ликвидацию последствий, а воспользуется помощью AIG. Доверяя свои данные такой компании, клиенты могут быть уверены в том, что в случае инцидента смогут получить возмещение ущерба. Особенно удобно, если подобный сервис предлагает провайдер услуг хостинга. Например, компания RUVDS бесплатно страхует всех клиентов от кибер-рисков A, B, C и F.

Спрос на страхование кибер-рисков в России может существенно вырасти в том случае, если крупные игроки или государство сформулируют четкие требования по наличию такой страховки.  

Let's block ads! (Why?)