Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Сообщество

Роман Шувалов Мне пришла в голову идея сделать трехмерный рендер карты OpenStreetMap

21.07.2020 00:08:15 | Автор: admin

Роман Шувалов разработчик инди-игр из Тольятти, который в начале этого года выпустил игру Generation Streets, основанную на данных OpenStreetMap. Не так давно он открыл часть кода своего проекта. Зачем он это сделал, как появилась игра и почему выбор пал на OSM обо всем этом Роман рассказал в интервью.

Как и когда вы узнали о проекте OpenStreetMap?

Это случилось около 5 лет назад в 2014-2015 годах, когда я искал решения, которые бы позволяли пользователям создавать карты для собственных нужд. На тот момент у меня уже был небольшой веб-проект карта дорог и тропинок тольяттинского леса. Он был выполнен на сервисе Яндекс.Карты, поверх стандартной подложки которого накладывался векторный слой с нужными мне объектами. Кстати, этот слой был сделан на основе GPS-треков, записанных мною и участниками нашего велоклуба. Это было нечто похожее на тепловую карту Strava. В какой-то момент я понял, что мне хочется чего-то большего и стал думать, как модернизировать свою карту.



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

Постепенно, по имеющимся у меня GPS-трекам, отрисовал в OSM тольяттинский лес и связанную с ним инфраструктуру. После сделал свой собственный рендер, его можно увидеть на Велосипедной карте Самарской области. Его особенность состоит в том, что даже на маленьких масштабах (начиная с 10) отображаются тропинки и иные объекты, которые могут быть полезны велосипедисту. В то время как на стандартных рендерах на 10-м и даже 12-м масштабе карта имеет довольно низкую детализацию, что особенно заметно при попытке построить веломаршрут по полям и лесам.


Велосипедная карта Самарской области. Мелкие тропы и населенные пункты видны даже крупных масштабах.

Почему в итоге остались в проекте? Ведь могли отрисовать только нужные вам дорожки и всё.

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

Чем вам интересна картография? Всё-таки достаточно необычное хобби.

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

Давайте поговорим о вашей 3D-игре Generation Streets, в основе которой данные OSM. Как она появилась на свет?

Отмечу сразу, что разработкой игр я занимаюсь с 2010 года. Что же касается конкретно этой игры, несколько лет назад совершенно случайно мне пришла в голову идея сделать трехмерный рендер карты OSM. Причем всей планеты сразу. Я посмотрел уже имеющиеся аналогичные проекты (F4map, OSM Buildings), но, к сожалению, ни один из них меня не удовлетворил они слишком схематичные. Мне же хотелось более реалистичный рендер: с текстурами, визуальным мусором в виде деревьев, фонарей и пр. Одним словом с той ерундой, которую мы обычно не замечаем, но без которой мир не выглядит живым.



И с чего вы начали разработку?

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

В итоге я остановился на двух маленьких программках: Osmconvert и Osmfilter. Для их работы не требуется поднятие БД. Они берут данные OSM в формате PBF и позволяют через параметры командной строки вырезать нужные кусочки. Таким образом я получил возможность без лишних проблем нарезать всю планету на тайлы.

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

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



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

Да, вы правы: готовые форматы уже есть, в том числе и векторные, например, у Mapbox, но всё дело в том, что они ориентированы на плоское двухмерное изображение. И у них есть одна неприятная особенность: если здание попадает на стык тайлов, то оно разрезается. Для меня это было абсолютно неприемлемо, так как для того, чтобы я потом смог сделать 3D-модель здания, оно должно было быть целым. Готового решения этой проблемы не было. Думаю, что просто ранее никто с этим не сталкивался. Потому я решил сделать что-то свое.



Поделитесь статистикой по игре? Какие отзывы?

С момента публикации игры на Steam (ранний доступ октябрь 2018 года, полноценный релиз февраль 2020 года) ее скачало около 3 тысяч человек. Для такого типа игры инди это достаточно неплохо. Важно еще учесть следующий момент: у игры слабый геймплей. И я сразу понимал, что в рамках этого проекта у меня никак не получится сделать его увлекательнее. Поэтому он такой, какой он есть.

Главный интерес в этой игре состоит в том, что у пользователя есть возможность скачать интересную для него территорию на планете Земля и полетать там. У большинства игр такой возможности нет. Например, те, кто живет в Нью-Йорке, регулярно радуются тому, что вышла очередная игра, в которой этот город воссоздан достаточно детально. А те, кто живет в Тольятти, вряд ли когда-нибудь дождутся игры созданной в локациях их города. Вот именно на это я и делал ставку.

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



Ваша игра использует данные OSM. Можно ли через неё править его?

Изначально я хотел встроить редактор OSM, но после небольшого эксперимента решил этого не делать. Какое-то время у пользователей была возможность вносить правки. Эти правки не шли напрямую в OSM, они оседали в локальной БД. Оказалось, что игроки далеки от мира OSM, а потому к карте они отнеслись весьма безответственно. Сейчас думаю о том, чтобы отключить даже и этот экспериментальный редактор, а всех желающих направлять в JOSM.

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

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



Что вам нравится в OSM?

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

Что не нравится?

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

Что бы сделали лучше?

Хотел бы увидеть хороший веб-редактор. Да, уже есть iD, но он ориентирован на новичков. Хочется что-то поудобнее. Также, мне кажется, что было бы намного лучше, если бы объекты внутри OSM были как-то связаны между собой. Сейчас если вносятся какие-то изменения в форму здания или меняется положение дороги, которая проходит рядом, то это изменение никак не влияет на соседние объекты. Даже если после изменения, например, дорога стала проходить поверх дома. Пока не знаю каким именно образом подобное взаимодействие можно реализовать, но вот хотелось бы, чтобы информация о зависимостях была. Тогда, например, не ломались бы маршруты общественного транспорта в случае редактирования дороги. Предполагаю, что это сделает данные OSM еще более удобными для редактирования и их дальнейшего использования.

Используете OSM в личной жизни? По работе? Кроме игры.

В повседневной жизни использую мобильные навигаторы OruxMaps и Maps.Me. Оба оффлайновые, то есть позволяют работать с картой без интернета, в основе их карт OSM. Чем мне нравится OruxMaps, так это тем, что он еще позволяет использовать собственные карты в векторном формате mapsforge.

Что посоветуете новичкам? Или тем, кто только думает: связываться с проектом или нет.

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

Что скажете в завершении беседы?

Как бы это громко не звучало, но на данный момент OSM это единственный открытый и свободный картографический проект в мире. Это независимая альтернатива коммерческим картосервисам. Именно поэтому в нем нужно принимать участие и всячески его развивать. Ведь если OpenStreetMap перестанет существовать, мы все будем вынуждены пользоваться коммерческими картами на тех условиях, которые нам будут кем-то навязаны. А о свободном использовании геоданных можно вообще будет забыть.

Общение российских участников OpenStreetMap идёт в чатике Telegram и на форуме.
Также есть группы в социальных сетях ВКонтакте, Facebook, но в них, в основном, публикуются новости.

Присоединяйтесь к OSM!


Предыдущие интервью:
Иван Чашкин, Сергей Астахов, Виктор Щерб, Николай Парухин, Евгений Катышев, Дорофей Пролесковский, Дмитрий Лебедев, Мария Попова, Николай Петров, Александр Зейналов, Алексей Клянин, Максим Дубинин, Александр Павлюк, Сергей Зайченко, Георгий Потапов, Владимир Маршинин, Евгений Усвицкий, wowik, SviMik, Кирилл Бондаренко, Артем Светлов, Сергей Синицын, Наталья Козловская, Виктор Вяличкин, Иван aka BANO.notIT, Антон Беличков, Елена Балашова, Илья Зверев, Тимофей Субботин, Сергей Голубев.
Подробнее..
Категории: Интервью , Openstreetmap , Геоинформационные сервисы , Сообщество , Работа с 3d-графикой , Open source , Разработка , Разработка игр , 3d , Игра , Рендер , Видеоигра , Инди-игра

Перевод Угон домена Perl.com

05.03.2021 10:06:07 | Автор: admin

Прим. перев.: в конце января стало известно о том, что один из основных доменов языка программирования Perl Perl.com был угнан. Это вызвало смешанную реакцию в сообществе как любителей языка, так и его противников. Теперь, когда всё уже позади и справедливость восстановлена, один из самых известных сторонников Perl brian d foy рассказал о том, что же произошло и как сообщество добилось положительного исхода событий. Представляем вниманию перевод его заметки.

На неделю мы потеряли контроль над доменом Perl.com. Теперь, когда проблема устранена, можно подробно рассказать о том, что произошло и как мы с этим справились. Инцидент затронул только домен Perl.com, никакие другие ресурсы сообщества не пострадали. Сам сайт никуда не делся, но DNS выдавал другие IP-адреса.

Во-первых, следует отметить, что проблема не связана с продлением домена. Для нас подобная забывчивость была бы даже лучше, поскольку есть так называемый grace period (в течение месяца после expiration его владелец все еще может продлить прим. перев.).

Во-вторых, хочу подчеркнуть, что я всего лишь редактор сайта, который использует домен Perl.com. То есть юридически меня нельзя назвать пострадавшей стороной. Владельцем домена является Tom Christiansen, и если делу будет дан ход, мне или кому-либо другому вовсе не обязательно знать все подробности. Однако я общался со многими людьми, вовлеченными в процесс.

Реакция на инцидент

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

Ранним утром 27 января Perl NOC (Network Operations Center) в рамках повседневного мониторинга заметил, что с доменом происходит нечто странное. Параллельно пользователи начали жаловаться, что сайт недоступен. По мере обновления записей DNS по всему миру все большее число пользователей сообщали о проблемах. Мы понятия не имели, что происходит и почему.

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

Я завел Google-документ и пригласил нужных людей. Мы начали заполнять детали, классифицируя их с помощью цвета: зеленого, янтарного, красного. Зеленым помечалась информация, которую мы считали достоверной например, прямое взаимодействие с регистратором; янтарный обозначал непроверенную информацию, которая могла быть правдивой, а красным маркировались недостоверные сведения. Вся информация сопровождалась временем и источником. Первое правило борьбы со слухами запоминать, от кого и когда вы их услышали. Когда это все сведено в документ, любой имеет возможность сравнить имеющуюся у него информацию с общедоступной и понять, является ли она более ценной и актуальной. Иногда информация, которая считалась правдивой, оказывалась недостоверной. Тогда мы вносили изменения в документ.

Также был составлен список дел, и все, кто мог, занялись ими. Например, мы начали проверять другие ресурсы сообщества. Elaine Ashton проверила регистрацию cpan.org (там была странность в контактной информации, но после телефонного разговора с регистратором все оказалось в порядке). Robert Spier, участник Perl NOC, проверил различные сетевые аспекты, хронологию и т.п. Rik Signes вызвался завести закрытый список рассылки на TopicBox (в конце концов, он же CTO). Тонкость здесь в том, чтобы не делать работу, которую может сделать кто-то другой (и часто лучше). Аналогичным образом, если кто-то уже что-то делает, не стоит тратить свое время впустую, переделывая за ним или заново "изобретая велосипед". Децентрализация это классно, но ей необходим координатор. В этом случае координатором стал я, поскольку очень многое вложил в сайт Perl.com. Кроме того, я отлично сработался с Томом, ведь до этого мы целый год трудились над книгой Programming Perl.

Мой твит и комментарии в Reddit привлекли внимание обеих сторон в "регистрационном уравнении", так что на самом старте процесса я смог переговорить как с Network Solutions, так и с Key Systems. Нам очень повезло, что Perl штука довольно известная, а мы с Tom Christiansen, в свою очередь, занимаем не последнее место в сообществе Perl. Первое правило успеха уже быть успешным. Сотрудники различных вовлеченных в процесс организаций предлагали нам свою помощь и давали советы. Увы, другим жертвам повезло меньше, и помощи они не дождались. Все эти организации, вероятно, на определенных этапах своего существования использовали Perl, и с теплотой вспоминали старые добрые времена.

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

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

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

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

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

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

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

Это не первое мое "родео", и я взял на себя роль пресс-секретаря. Несмотря на кропотливую работу по проверке всего и вся, многие люди со стороны просто выдумывали всякую ерунду. Что ж, бывает и такое (что вполне предсказуемо). Издательский принцип "Если мать говорит, что любит тебя, найди второй источник" не применим в эпоху Twitter. Часто не нужен даже первый источник.

Важно, чтобы сообщество представлял один человек. Авторы доброй половины "новостных" публикаций не потрудились провести базовые исследования, а у некоторых из них отсутствовала контактная информация (серьезно? Журналист, с которым нельзя связаться?). Некоторые авторы исправили свои материалы, поговорив со мной.

The Register с самого начала выдавал точную информацию, как и Paul Ducklin на сайте Sophos.

Примерно через неделю после изменений на серверах имен, я пришел к заключению, что возврат домена после взлома может растянуться на несколько недель. Поскольку в него были вовлечены разные страны со своими законами и правилами, процесс продвигался гораздо медленнее, чем нам хотелось. В эпоху Интернета "завтра" равносильно "вечности". David Farrell выдвинул идею о переименовании сайта, и мы стали использовать perldotcom.perl.org в качестве временного домена. Robert смог все быстро настроить, и мы классно провели время, анализируя pull request'ы от сообщества. В них пользователи указывали на некоторые моменты, которые мы за'hardcode'или, хотя не должны были (любой человек может предложить PR по любому поводу, имеющему отношение к сайту!). Основой для всей этой работы выступал процесс на базе GitHub, который разработал David (нам приятно получать даже самые незначительные PR от сообщества!).

Затем, в начале февраля, обходными путями я получил надежную (зеленую) информацию о том, что домен вернется к нам через пару дней. Я сперва не поверил, но это действительно произошло! Опять же, нам очень повезло: люди, в сердцах которых Perl занимает особое место, сильно нам помогли. Все стороны понимали, что Perl.com принадлежит Тому, и воплотить это понимание в жизнь было несложно. Владельцам менее известного доменного имени было бы гораздо труднее доказать свои права на него.

Впрочем, с возвращением домена история не закончилась. Пока домен был скомпрометирован, различные продукты в сфере безопасности внесли Perl.com в черный список, а некоторые DNS-серверы занесли его в sinkhole. Мы решили, что постепенно все придет в норму, и отложили празднование возвращения Perl.com до более подходящих времен. Хотелось, чтобы он стал доступен для всех. И, наконец, этот знаменательный момент наступил! Если у кого-то проблемы с Perl.com, пожалуйста, заведите issue, чтобы мы знали, что для некоторой части интернета домен не работает.

Что, по нашему мнению, произошло

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

John Berryhill опубликовал в Twitter результаты своего расследования, которое показало, что взлом на самом деле произошел в сентябре. В декабре домен был передан регистратору BizCN, но серверы имен остались прежними. В январе домен вновь был передан другому регистратору Key Systems, GmbH. Подобная задержка помешала выявлению проблемы на ранних этапах, а передача домена от одного регистратора другому значительно осложнила его восстановление.

Обратите внимание на длительную задержку до момента первой передачи. Домен взломан в сентябре, а передача произошла в декабре. Для этого имеется веская причина: 60-дневное правило ICANN. Домен нельзя передать в течение 60 дней после обновления контактной информации. Мы думаем, что регистрация была изменена злоумышленниками одновременно с продлением домена на несколько лет (первоначально домен истекал в 2029 году).

После передачи домена Key Systems в конце января, новый владелец-мошенник выставил его (и другие домены) на продажу на Afternic (рынок доменов). Perl.com можно было купить за 190 тыс. долларов. После запросов The Register домен был снят с продажи.

Некоторые уроки

Очевидно, ситуация неприятная, но ее нельзя назвать уникальной. Домен был зарегистрирован в начале 1990-х, вскоре после этого Tom Christiansen получил над ним контроль, и с тех пор продолжал платить сборы за продление. Как обычно бывает, ничего не менялось "пока гром не грянул". Механизмы вроде двухфакторной авторизации, пожалуй, избавили бы нас от большей части проблем (хотя атаки социальной инженерии умудряются обходить защитные меры).

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

Очень важно вести переговоры с одним и тем же человеком, иначе вы рискуете посеять путаницу из-за многообразия сообщений, даже если в них говорится одно и то же. Также необходимо демонстрировать уверенность и компетентность, чтобы озвучиваемая вами информация воспринималась как достоверная; если разные каналы озвучивают разные послания, риск ошибок возрастает. Perl Foundation настоял на публикации собственного заявления вместо подготовленного нами. Хотя оно было крайне лаконичным, ссылка на блог Perl NOC не работала несколько дней. Не рискуйте понапрасну.

Кроме того, всегда хорошо иметь друзей и поддерживать добрые отношения с людьми, способными помочь. Сотрудники Network Solutions и Key Systems очень помогли нам с восстановлением, как и другие специалисты, поддерживающие работу интернета. Я хотел бы назвать их имена, но уверен, что они предпочтут не афишировать себя и просто делать свою работу.

Текущее состояние дел

Домен Perl.com был благополучно возвращен Tom Christiansen. Ведутся работы над различными мерами, способными предотвратить повторение подобной ситуации. Сайт вернулся к нормальной жизни и стал чуть ярче благодаря всей той помощи, которую мы получили.

В рамках реагирования на инцидент The Perl Foundation Infrastructure Working Group изучила другие важные домены сообщества. Будет проведена соответствующая работа по их защите. Желающие помочь могут связаться с ними.

P.S. от переводчика

Читайте также в нашем блоге:

Подробнее..
Категории: Информационная безопасность , Сообщество , Open source , Dns , Блог компании флант , Perl

Перевод Новости из мира OpenStreetMap 515 (26.05.2020-01.06.2020)

13.06.2020 18:19:58 | Автор: admin

lead picture


Тренды в OpenStreetMap: среди стран, городов и тем 1 | Pascal Neis | map data OpenStreetMap contributors



Картографирование


  • Русс Гарретт, разработчик сайта OpenInfraMap, опубликовал в своем Твиттере картинку, на которой можно увидеть источники возобновляемой энергии в Европе, отмеченные в OSM.
  • [1] На сайте статистики osmstats.neis-one.org, который ведет Паскаль Нейс, появилась новая функция, аналогичная Twitter Trends. Она отображает тренды в OSM: среди стран, городов и тем.
  • Zkir поделился своими выводами, которые он сделал по итогам участия в картоакции "Как проехать в деревню?" (о ней мы писали ранее). Кстати, он также провел стрим.

Сообщество


  • Местное отделение Фонда OSM в США опубликовало протокол заседания своего совета от 29 апреля 2020 года.
  • В российском сообществе OSM продолжается картоакция "Как проехать в деревню?". Напомним, что в рамках инициативы предлагается нарисовать дорогу к тем деревням, которые на данные момент никак не соединены в OSM со всем остальным миром. Сейчас идет работа над Южным федеральным округом. Ранее был отработан Приволжский.
  • SomeoneElse написал скрипт, который умеет делать рейтинг тем для данного того или иного списка рассылки OSM. С его помощью он составил рейтинги тем списка рассылки Тегирование в мае 2020 года, Разговоры в мае 2012 года (когда было много горячих дискуссий во время сменя лицензии) и мае 2007 года.
  • Валерий Трубин продолжает серию интервью с осмерами. На этот раз он поговорил с Евгением Катышевым о том, как принимаются новые теги в OSM, и Николаем Парухиным о переводах инструментов на русский язык.
  • Иван Кирюшкин рассказал, как он с помощью OSM и QGIS построил изохроны территориальной доступности горнолыжных курортов Розы Хутор и Альпики-Сервис.
  • Мы уже сообщали ранее (#498), что пользователь Vascom начал еженедельно собирать новые карты для Maps.Me. Не так давно он добавил еще 6 новых стран: Сербию, Словакию, Словению, Венгрию, Румынию, Боснию и Герцеговину. Помимо этого, он начал делать ежедневные сборки. Правда, всего две локации: Москва и запад Московской области.

Импорты


  • Российская компания NextGIS сообщила, что выполнила импорт в OSM всех гипермаркетов Лента. Как отмечается на форуме, для импорта был использован инструмент OSM Conflator, процесс был документирован на WikiOSM. Импорт предварительно был согласован с сообществом RU-OSM на форуме и в Telegram-чате.

Фонд OpenStreetMap


  • Эдоардо Нирхут рассказал в своем блоге об усилиях, которые он прилагает для создания официального местного отделения Фонда OSMF в Океании. Компании OSGeo Oceania Ltd уже подала заявление о признании ее юридическим лицом местного отделения.
  • Фонд OSM и GraphHopper выпустили совместный пресс-релиз, в котором сообщили о выходе версии 1.0 открытого движка маршрутизации GraphHopper. Его разработка ведется уже 7 лет.

Гуманитарный OSM


  • Некоммерческая организация Missing Maps способствует сбору открытых данных об учреждениях здравоохранения во всем мире. В своем блоге она рассказывает о платформе healthsites.io и их подходу к ее проектированию.
  • HOT объявил первую группу получателей программы микрогрантов Rapid Response Microgrants: COVID-19, целью которой является улучшение покрытия карты слабо отрисованных районов, у которых нет сильных сообществе, так как они могут быть забыты в связи с пандемией COVID-19.
  • В интервью Вилле Марселен рассказал о том, как он работал над новой версией инструмента (4.0) HOT Tasking Manager.
  • Забытый и неотрисованный под таким заголовком на сайте Пулитцеровского центра вышла статья о судьбе Макоко, районе трущоб в Нигерии, которого официально не существует. Помимо прочего в материале рассказывается о работе HOT по составлению карты этой территории.

Образование


  • Павел Гаврилов сделал два (1, 2) больших обучающих видео о работе с мультиполигонами в JOSM (посты в блоге: 1, 2).

Карты


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

Переходим на OSM


  • Японский автоперевозчик Hokkaido Takushoku Bus сделал карту своих маршрутов. В качестве подложки OSM.
  • Район Фрейзинг в федеральной земле Бавария (Германия) использует OSM на своем туристическом портале.
  • В Минске создали интерактивную карту мест сбора мусора. В качестве подложки OSM.
  • Оказалось, что крупная российская социальная сеть Вконтакте использует POI из OSM.

Открытые данные


  • Балтийская металлургическая компания поделилась с сообществом RU-OSM снимками своей промышленной площадки.
  • Представитель замка Постерштайн в Германии, в котором сейчас находится музей, спросил: сотрудничают ли между собой OSM и Викимедия в Германии. Это их заинтересовало, так как не так давно они узнали о проекте Карта замков Швейцарии совместном проекте швейцарских OSM и Викимедии. Штефан Келлер поделился с ними нужными контактами, но до сих пор не получил никакой обратной связи.
  • Гийом Ришар сообщил, что доступна новая карта Люксембурга, выполненную методом отмывки. В ее основе открытые данные, собранные с помощью технологии LiDAR.
  • Флориан Лоховв беспокоится за проект OpenStreetCam. В данный момент он делает новые снимки быстрее, чем их удается загрузить на этот сервис. В последнее время обработка снимков на нем происходит по несколько дней.
  • Немецкий город Херренберг сделал платформу stadtnavi, чтобы поддержать переход к более экологичным видам транспорта, таким как общественный транспорт, каршеринг, велосипед или просто ходьба. В основе проекта данные OSM и свободное программное обеспечение.

Программное обеспечение


  • Разработчики OsmAnd сообщили о выходе новой версии приложения, которая теперь умеет работать с плагинами пользователей. За счет этого его можно будет настроить еще более тонко. Отмечается, что вы можете указать в плагине собственные файлы рендеринга, шрифты, маршруты, карты и пр.
  • Возобновлена разработка плагина для браузера OSM Smart Menu.

Программирование


  • Куинси Морган, разработчик онлайн-редактора iD, размышляет о том, чтобы сделать мобильное приложение для данного редактора.

OSM в СМИ


  • Сара Скоулс написала в журнале Popular Science об OSM в целом, а также коснулась ряда деталей, например, импорта зданий в Денвере, археологии, спасателях, вырубке лесов и многом другом.

Другие гео события


  • Возможно, первая абстрактная карта, показывающая маршруты общественного транспорта была выполнена Францем Раффельшпергеров в 1826 году.
  • Бард Вульфгар, наиболее известный своими сатирическими карикатурами о Донаельде Неготовом, на самом деле работает археологом. В Твиттере он опубликовал интересную информацию о том, как аэрофотосъемка и LiDAR помогают ему в его работе каждый день.
  • Скорее всего, карта Германии 1989 года сейчас невероятно дешево стоит .
  • Meander это генератор исторических карт течения вымышленных рек.
  • С помощью сервиса 'Widen My Path CycleStreets' можно оставить маркер на карте Великобритании в том месте, где по мнению ее автора необходимо расширить велосипедную дорожку.
  • Российской госкорпорацией Роскосмос выпущен очередной номер научно-практического журнала Дистанционное зондирование Земли из космоса в России.
  • Власти Москвы опубликовали карту иммунитета к коронавирусу.
  • В Москве с 1 июня разрешили выходить на улицу для прогулок и занятий спортом. При этом власти предлагают выходить на улицу не тогда, когда хочется, а по расписанию. График прогулок составлен для каждого дома жилого дома в Москве! Узнать его можно на сайте мэрии города.


Общение российских участников OpenStreetMap идёт в чатике Telegram и на форуме. Также есть группы в социальных сетях ВКонтакте, Facebook, но в них в основном публикуются новости.

Присоединяйтесь к OSM!


Предыдущие выпуски: 514, 513,,512, 511, 510,
Подробнее..
Категории: Социальные сети и сообщества , Openstreetmap , Геоинформационные сервисы , Перевод , Новости , Геоинформационные технологии , Карты , Сообщество

Почему онлайн-митаапы никогда не заменят оффлайн, что с этим делать и почему онлайн всё равно нужен

26.06.2020 16:08:22 | Автор: admin
Мне это надоело.
В прошлом году я был на 50+ митапах, нескольких конференциях и на паре хакатонов.
За последние пару месяцев я сходил на 30 онлайн-мероприятий разных форматов, и хочу рассказать, почему зря потратил это время, в чём проблема с онлайн (и офлайн) митапами и что мы можем сделать чтобы оказаться в чуть лучшем мире. Давайте по порядку.

Зачем приходить на митапы

Знания (доклады, контент)

Мы выбираем мероприятия по направлениям и темам, просим работодателя оплатить участие, мотивируя это получением новых знаний. И звать на митапы можно исходя из позиции прокачки экспертизы и получения знаний. Давайте посмотрим, с кем такие мероприятия конкурируют в онлайне:
  • Pluralsight библиотека на 7.000+ онлайн-курсов по разработке, облакам, МЛ, девопсу, безопасности и данным.
  • Coursera сборник онлайн-курсов, сертификаций и программ лучших университетов и компаний мира, 4.000 курсов.
  • Записи докладов с конференций на Youtube на русском и английском
  • Хабр. Серьезно, доклад это же видеоверсия статьи.

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

Развлечение/награда/отдых

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

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

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

Нетворкинг


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

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

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

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

Всё. Это основные цели для конференций и митапов. И онлайн-митапы проигрывают по каждому из этих направлений. Ну, по крайней мере, в теории. А что на самом деле?

Пруфы

В подсчете статистики нам поможет сайт https://meetups-online.ru/, на котором собраны почти все онлайн-события в ИТ. За первую половину мая прошёл 31 митап и можно по ним посмотреть доступность нетворкинга на мероприятиях. Вторую половину мая я пропустил потому что участвовал в РИТ++ и Podlodka Teamlead Crew, о которых скажу отдельно.

Методика

Сложно сравнивать офлайн и онлайн из-за разных механик, поэтому я просто выбрал те механики, которые связаны с обратной связью (от спикера, от аудитории, к спикеру) и позволяют митапу отличаться от его расшифровки в текст:
  1. Хорошая доступность без сложных регистраций и установки нетипичных для прикладной работы программ.
  2. Чат участников трансляции, в котором идёт беседа во время митапа.
  3. Возможность задать вопрос текстом в чате или на отдельном сайте.
  4. Возможность выйти в эфир и задать вопрос спикеру или обратиться к аудитории голосом.
  5. Обратная связь от аудитории и подстройка сценария разговора под актуальные для собравшихся темы. Это может быть и в голосовом обсуждении, и с помощью чата, если есть отдельный редактор, который мониторит канву обсуждения и скидывает ведущему и участникам актуальную информацию.
  6. Общий созвон всех участников, который убирает границу между спикером и аудиторией, а поучаствовать в обсуждении можно максимально просто.
  7. Техники для развития нетворкинга: BoF-сессии, общие интерактивные голосования.
  8. Приватность и уютность общения: случайный кофе, несколько тематических комнат по интересам в дискорде, привычный мессенджер вроде телеграма, в котором можно быстро перейти в личку.
  9. Оригинальные инструменты/форматы/техники, которые помогают стереть границу между участниками и дают больше возможностей для обмена опытом: единая Miro-доска, VR, стенды партнеров в онлайне.

Итоги

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

Что делать

Отличные новости! Выход есть. То есть, я попытался его найти.


Поддерживайте оффлайн-организаторов

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

Не организуйте митап ради митапа

Если вы организатор, то посмотрите на инструменты, которые могут улучшить UX вашего митапа. Zoom позволяет хорошо модерировать трансляцию и не разделяет аудиторию. В Discord есть возможность делать много разных тематических комнат и максимально быстро переключаться между ними, даже устанавливать его не понадобиться, можно пользоваться браузером. Miro даст общее пространство для рисования и стикеров участникам. Посмотрите на Slido и Mentimeter.

Одним из самых ярких впечатлений от РИТ++ было афтерпати в Spatial, который эмулирует пространство вечеринки в 2d. Можно запускать сразу несколько трансляций youtube в разных углах и собираться вокруг них, можно объединяться в компании и подходить к другим компаниям. Есть несколько тематических комнат, в каждой из которых собиралось сразу несколько кружков по интересам, перейти между ними можно очень быстро, а помогает ощутить себя в тусовке.

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

Сморите на новые форматы

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

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

23 мая прошёл онлайн-паб без докладов, только общение за столиками по интересам с экспертами, афтерпати и барные викторины в перерывах.

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

Давайте много честной обратной связи

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

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

Ещё не поздно рассказать своё мнение в большом опросе Нужны ли онлайны этим летом? И какие, если да.

Оставайтесь дома

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

Из песочницы Геймдев и кризис

24.07.2020 12:09:40 | Автор: admin
Наверное многие уже успели заметить эту тревожную тенденцию падение прибыли, потеря платящих игроков, уменьшение покупок и среднего чека. А обратив внимание начали читать метрики на предмет Что же мы сделали не так? Почему игроки уходят? Может логика стала кривой или кнопка перехода не нажимается, может мы чем-то обидели игроков?. После разбора полётов картина не становится яснее, 10 лет небольшие колебания но стабильные цифры и тут вдруг бац и крутое пике!

Начать придется немного издалека иначе контекст катастрофы будет непонятен. Тут нужно прояснить для себя одно очень важное понятие Модель.

Что первое у нас всплывает в памяти при этом слове? Модельки машинок или крутящиеся шарики на подставке? Это оно! Это уменьшенная копия некоего оригинального объекта или процесса с разной долей достоверности. А зачем вообще нужны модели? спросите вы. Всё дело в нашем мозге и его ограничениях. Возьмём для примера автомобиль у него есть вес, ширина, высота, мощность двигателя, материал корпуса и еще бесчисленное количество параметров. Каждый раз, когда вы хотите обдумать мысль связанную с автомобилем вам приходится загружать в крошечный участок мозга всю информацию по объекту, а памяти мало, нейроны быстро устают(на самом деле не устают просто у них заканчиваются медиаторы, но смысл такой же). Если объект простой то памяти хватает, а если у объекта тысячи параметров как быть бедному мозгу? Эволюция нашла выход! Можно давать веса параметрам объекта и подгружать, в зависимости от доступных ресурсов, параметры с наибольшими из них. В результате у нас появляется упрощенное(неполное) описание объекта или процесса Модель. Модель может иметь разную степень достоверности соответствия описанных параметров и реальности. Модель имеет степень детализации это те самые признаки с назначенными им весами, чем их больше, тем точнее и детальнее модель. Теперь объект или процесс, представленный моделью, можно загрузить в мозг и понять его(и простить) и осознать, производить с ним разные операции, уменьшать, расширять, давать вводную информацию и получать исходящую. Да, конечно это будет не настоящий процесс, а его имитация и результаты будут всего лишь с неким процентом достоверности(больше детализация больше процент достоверности).

Теперь мы опишем текущую модель игрока и продажи ему чего-то за деньги.

Чего и сколько мы продаем по статистике:

  • Приложения 5-7%
  • Подписки 10-15%
  • Инапы 40-45%
  • Клики на рекламные ролики 20-25%
  • Просмотры рекламных роликов 15-20%
  • Продажа, не влияющих на баланс, косметических скинов. 5-10%
  • Продажа battle pass открытие веток квестов. 5-10%
  • Продажа данных пользователей (если вам говорят что это бесплатно значит товар это вы )
  • Перспективная продажа контекстной рекламы во внутриигровых виджетах. 0.1%

Наш игрок имеет свободное время для игры, минимум час в день. Имеет деньги (минимум 10 баксов в неделю).

Как делят игроков:

  • Богатые(vip, киты) покупают постоянно. 5%
  • Средние покупают изредка. 30 45 или подростки на деньги родителей. 35%
  • Бедные не покупают практически никогда. 60%

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

  • Продажа инапов 40-45% средним и богатым
  • Рекламы бедным

Продажа рекламы сама по себе имеет много нюансов, тут и игра должна удерживать игрока и реклама не должна быть навязчивой появляясь в разгар боя. Реклама, один из самых мощных демотиваторов для игрока. Стань игра менее интересной и всё игрок потерян, а 10 центов за 1000 кликов слишком мало на фоне потраченных на разработку ресурсов. Единственный надёжный источник это инапы. Игроделы конечно научились у наркоторговцев маркетингу. Грамотно выстроенный баланс и заветная конверсия в платящего произошла, сначала немного, потом чуть больше и вот у нас новый условный мак.

Почему старая модель больше не работает?

Тут мы подходим к самому скверному моменту экономический кризис. Начался он 10 лет назад, а вот уходит в крутое пике сегодня и по разным оценкам падение реального ВВП у штатов и Китая будет от 40 до 50%, у европы 35%, у нас около 5%(мы и так уже упали на дно). Чем это грозит? Вот те средние перейдут на ступеньку ниже в бедные, а значит инапы можно будет продать только 5% богатых (а их на всех не хватит). Что следует за сломом старой модели продаж? Смена механик монетизации! А на них завязаны сюжеты, логика, баланс. Ого, приплыли! Да это по сути нужно новую игру создавать и не просто как обычно фигак-фигак и в продакшен, а на плавающей целевой группе, что сулит игре нехорошим. Добавьте сюда 30% от вырученных слёз у вас заберут магазины приложений. Прибыли у них упадут, а жить скромно они разучились. Надежды на разумные 5% мало, вот тут мы и увидим взлёт стремительным домкратом всяких хуавей сторов. А ведь 30% это только краешек проблемы, магазины запрещают то, на чём можно хоть что-то заработать секс, насилие, азартные игры, шутки про негров.

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

Итак спрос будет даже лучше прежнего правда малоплатежеспособный.

Зная вот такие невесёлые расклады давайте опишем новую модель продаж и новую модель пользователя.

Модель потребителя:

  • Богатые 5%
  • Бедные 95%

Модель продаж:

  • Продажа кликов на рекламные ролики
  • Продажа просмотров рекламных роликов
  • Встроенная контекстная реклама

Новый пользователь не потерпит несправедливости в виде покупки инапов и преимущества в игре (а у богатых это главный стимул). Рекламу будет тяжело продавать, так как на рынок выйдет новая волна игр и у конкурентов её может заменять другая монетизация. Продажа данных пользователей маркетинговых компаниям? Да! Но для этого нужно иметь знаменитую игру с высокой посещаемостью, а это редко у кого есть. Встроенная контекстная реклама только в первых прототипах. Хороший вариант не забирать деньги пользователя, но создать сюжет или ситуацию при которой их можно будет свободно ввести, вывести, обменять и т.д., а за ввод и вывод брать крошечный процент. Прозрачность залог доверия если пользователь понимает правила и видит, что его не грабят значит будет мотивирован и другим расскажет, а для новых тёмных веков это немало.

Если раньше, чтобы повысить установки достаточно было занести несколько миллионов зелени в магазин чтоб подняли игру повыше, в фейсбук чтоб направлял своих рекламой, то теперь с зеленью будут проблемы. Размер заноса вообще не поддаётся прогнозированию. И что же делать? Идти на землю! Необходимо завести людей которые в сети будут отыскивать любые сообщества и аккуратно, ненавязчиво подталкивать их к созданию собственной игры (а по настоящему хорошие игры делает только студия N)! Хорошо тем, у кого есть вселенная!

Готовая фангруппа которая купит и простит многое, а если её нет? Её должно придумать сообщество. Бухгалтеры квесты по невыплатам. Бандиты и депутаты про ограбления и насилие в отношении простых граждан. Простые граждане про насилие над депутатами и бандитами. Вообщем у каждой группы есть интересы, этим они и отличаются друг от друга, найти их вот наша задача! Далее группа или сообщество методом голосования формирует предложения по концепции, жанру, логике, графике Да, да можно переложить работу ГДшников и сценариста на пользователей! Пользователи будут в самой гуще, они не будут оторваны от результата, сама игра будет консистенцией того, о чём они мечтали:
Хочешь грабить корованы? Вот бери!.
И тут мне должны возразить:
Да ты medex вообще в своём уме? Ты вообще знаешь сколько стоит разработка? Какие зарплаты нужно платить разрабам, гдшникам и qaшникам? Сколько стоит коммуналка на офис, сколько стоит Unity?.

К сожалению представляю. И тут я как бы из последних сил вытаскиваю из кармана карточку, а на ней написано 2 уровня на Godot. Три слова и одна цифра, а смысла на хорошую кандидатскую. Используя Godot мы получаем единную среду разработку для художников, аниматоров, гдшников, разработчиков и тестировщиков. Мы получаем IDE с исходниками под MITовской лицензией, с беком на плюсах и разработкой логики на питоноподобном GDScript с динамической типизацией и заменой сборщика мусора на смартпоинтеры, с анимацией и логикой на блюпринтах и как изюминка можно писать логику и на C#. Что даёт нам скрипт на питоне? Удешевление разработчиков с примерно тем же уровнем. Есть и минусы, слабая интеграция с модными сервисами метрик, но этого дела на гитхабе уже полно. Что у нас по итогу если в логике готовы менеджеры обвязки (квестов, сейлов, пушей, магазина, игрового сервера, метрик, соревнований и т.д.) то останется только логика мира и игровой сцены для 2 уровней это 2 месяца со стартовой графикой купленной в готовых ассетах или на pinterest. Даже более того ведь если жанр популярный, то жанровый движок тоже можно недорого купить готовый! А далее заинтересованные(интересом или игровой валютой) пользователи тестируют уровни экономим на QA.

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

Как то так я вижу ближайшее будущее, сбудется ли оно покажет время, ну а пока а ля гер ком а ля гер господа!
Подробнее..
Категории: Сообщество , Open source , Исследования и прогнозы в it , Бизнес-модели , Управление проектами и командой , Монетизация игр , Godot , Продажи

Как внедрить геймификацию в профессиональное сообщество

27.07.2020 12:16:39 | Автор: admin
В новом году, в сообществе IT-аналитиков Новосибирска, мы стали внедрять игровые механики через многоразовые бейджы. Сегодня расскажу что из этого вышло


image

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

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

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

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

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

В-третьих, я большой фанат геймификации. Давно ждал возможности применить знания на практике.

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

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

image
image

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

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

  1. Опыт других сообществ (к сожалению, конкретные статьи и видео у меня не сохранились)
  2. Кейсы Octalysis Prime и An Coppens
  3. Советы из Геймшторминга
  4. Механики игровых ачивок

Первый драфт логики вышел подробным, механика хоть и интересной, но излишне сложной.

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

Когда механика версии 1.0 устоялась, пришло время переходить к дизайну. Дизайнеры у нас есть, только были заняты другими задачами, поэтому я взял Canva.com, фотографии с мероприятий сообщества и принялся творить:

image
image

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

На оборотной стороне самое интересное поле достижений. Оно разбито на две секции:

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

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

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

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

Правила простые и понятные. То, что нужно для версии 1.0.

image

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

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

Каким именно образом?
Приведу краткий список того, что пошло не по плану:

  • Посыпалась роудмапа.
    У нас была четкая роудмапа с мероприятием на каждый месяц. Очным мероприятием, конечно. Быстро перепрофилировать все в онлайн не удалось. Годовой план посыпался.
  • Проблемы с мотивацией. События года неплохо подкосили мотивацию. Пафосно, но будущее стало казаться туманным и мрачным. О какой общественной деятельности может быть речь, если непонятно где ты можешь оказаться завтра?
  • Онлайн формат враг локальных комьюнити. Я, как создатель сообщества, не очень понимаю онлайн формат. На мой вкус он против идей локального комьюнити.
  • Активность участников упала.


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

image

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

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

Бросать проект, желания нет. Есть противоположное желание развивать геймификацию больше, и не только в сообществе IT-аналитиков Новосибирска.

Посмотрим, что из этого получится. Буду держать в курсе дальнейшего развития событий и делиться новыми кейсами. Так же буду благодарен за советы, куда еще посмотреть в плане теории геймификации.
Спасибо за время, увидимся ;)
Подробнее..
Категории: Сообщество , Анализ и проектирование систем , Ивенты , Управление сообществом , Геймификация , It-аналитики новосибирска , It-аналитики , Сообщества

Перевод Будущее Prometheus и экосистемы проекта (2020)

04.08.2020 10:19:03 | Автор: admin
Прим. перев.: это перевод статьи, подготовленной по мотивам недавнего выступления Richard Hartmann заметного представителя команды разработчиков Prometheus, директора по сообществам из Grafana Labs, основателя проекта OpenMetrics и председателя группы SIG Observability в CNCF. Автор подводит итоги последнего года в жизни Open Source-проекта (и сообщества) Prometheus, а также рассказывает об основных трудностях и ближайших перспективах.



Во время PromCon Online 2020 я выступил с докладом под названием Будущее Prometheus и его экосистемы. И хочу поделиться с вами его ключевыми моментами.

Резюме


Со времени прошлой конференции PromCon 2019 в Prometheus произошло множество изменений.


2.14


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

2.15


Версия 2.15 прошла под знаком API метаданных. Формат экспозиции Prometheus уже давно поддерживает специальные выражения HELP, TYPE и т.п., однако сам Prometheus раньше просто отбрасывал эти данные. Теперь, когда они остаются, можно открыть внешний доступ к ним через API. Например, Grafana уже пользуется этой возможностью и предоставляет пользователям дополнительную информацию о временных рядах, с которыми те работают:



2.16


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

2.17


К слову о затянувшихся запросах на фичи: версия 2.17, наконец, дала долгожданную I в ACID для БД: изолированность.

2.18


В 2.18 были улучшены трассировка и поддержка экземпляров в формате экспозиции. Экземпляры это первый заметный для пользователя эффект от внедрения OpenMetrics в Prometheus. Объединив их с Grafana, можно достичь удобной детализации, позволяющей переходить от:



к:



2.19


В 2.19 сократили потребление памяти на целых 50%! Даже несмотря на то, что Prometheus уже весьма эффективна, остается значительный потенциал для оптимизации это одновременно и воодушевляет, и пугает.

Такой график прекрасная тому иллюстрация:



2.20


Версия 2.20 может похвастаться самым длинным списком изменений с момента выхода v2.6(!). Главным, вероятно, является родная поддержка обнаружения сервисов для Docker Swarm и DigitalOcean.

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

node_exporter


Подводя итог, хочу заметить, что node_exporter достиг версии 1.0 и теперь включает в себя ЭКСПЕРИМЕНТАЛЬНУЮ поддержку TLS. Фонд Cloud Native Computing Foundation проспонсировал аудит node_exporter'а компанией Cure53 (он охватывал как экспортер в целом, так и нашу реализацию TLS в частности). И он того стоил вдвойне: мы не только проверили TLS перед тем, как копировать его в другие экспортеры, но и использовали node_exporter как подопытного кролика, с которого копируются и иные паттерны.

Будущее


Иногда у меня возникает ощущение, что мы как проект почиваем на лаврах. Некоторое время назад я запустил мозговой штурм внутри Grafana под девизом Prometheus'у не хватает функций и призвал Red Hat поступить так же. Попутно мы создали доступный для всей команды Prometheus документ сразу обо ВСЕМ. Он служит основой для рассмотрения конкретных тем, разбитых на пункты для обсуждения во время dev-саммитов (по мере готовности этих пунктов).

Саммиты разработчиков


В прошлом году у нас было два dev-саммита: один после KubeCon EU, второй после PromCon. Планировалось то же самое сделать в 2020 году, но помешал COVID. В этом году пока саммитов не было, но я полагаю, что мы нашли выход: более короткие, частые и виртуальные встречи. Мы проводим блоки по 4 часа вместо того, чтобы собираться сразу на 1-2 дня. Первый такой dev-саммит прошел 10 июля, а следующий, вероятно, состоится 7 августа. Мы продолжим проводить их, пока не разберем все накопившиеся вопросы (хотя их число постоянно растет по мере того, как добавляются все новые пункты из вышеупомянутого документа).

Сейчас я хочу сделать две вещи:

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

Метаданные


Метаданные начинают приносить реальную пользу в Prometheus (см. 2.15 выше). Нам нужно реализовать больше возможностей для работы с метаданными (например, распространять их через удаленное чтение/запись). Консенсус ниже не охватывает такие интересные вопросы, как Что делать, если метаданные изменились/пропали? или Что делать, если они станут вектором атаки?.

КОНСЕНСУС: Мы хотим лучше поддерживать метаданные. Работа будет вестись в специальном документе.

КОНСЕНСУС: PR 6815 пойдет в качестве ЭКСПЕРИМЕНТАЛЬНОГО временного решения. Скорее всего, оно будет другим в версиях 3.х.

Изменения в рабочем процессе и s/master/main/


Тема разгребания мусора, скопившегося в рабочих процессах, не требует особого пояснения, однако следует сказать несколько слов об устранении словоблудия (единстве терминологии). Мы серьезно настроены на очистку терминологии: это не самое важное, но то, чем мы можем заняться уже сейчас. Пока мы ждем соответствующего инструментария от GitHub. Как только он появится, попробуем привлечь к этой работе платного стажера через Community Bridge.

Я веду переговоры с Linux Foundation и CNCF о том, чтобы потенциально реализовать это во всех проектах. Отличная возможность для того, кто интересуется данной тематикой: возможность изучить множество проектов, поработать с различными инструментами, познакомиться со многими людьми. Свяжитесь со мной в Twitter (@TwitchiH) или по почте (richih на сервере grafana.com), если вам это интересно.

КОНСЕНСУС: Установить Требовать прохождения проверок статусов перед merge'ем во всех репозиториях prometheus/ Не допускать прямые push'и в main branch? Не допускать force push'и в main branch?

КОНСЕНСУС: Отключить force push'и во все main branches.

КОНСЕНСУС: Поведение по умолчанию разрешает push'и в main branch, однако его следует отключить для некоторых важных репозиториев, например, prometheus/prometheus (на усмотрение maintainer'а).

Заполнение данными (backfilling)


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

После продолжительных обсуждений и попыток прийти к консенсусу стало ясно, что сделать это так просто не получится. Поэтому я переформулировал предложение следующим образом: Мы хотим поддерживать backfilling по сети хотя бы потоками, которые не пересекаются с head block.

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

КОНСЕНСУС: Мы хотим поддерживать текстовый формат экспозиции Prometheus и OpenMetrics, и один четко определенный CSV-формат для импорта данных.

КОНСЕНСУС: Мы хотим поддерживать backfilling по сети хотя бы блоками, которые не пересекаются с головным.

НЕ КОНСЕНСУС: Мы хотим поддерживать backfilling по сети хотя бы потоками, которые не пересекаются с головным блоком.

КОНСЕНСУС: Мы хотели бы поддерживать backfilling по сети блоками, которые не пересекаются с головным блоком при условии надлежащей реализации.

Вендоринг


Еще одна из задач, связанных с наведением порядка. Здесь я хочу покритиковать Go: он был разработан в мире, в котором единый монореп это норма. Google хранит весь (или основную часть) своего общего кода в единственном репозитории. Этот подход имеет много преимуществ, но плохо переносится на реальные условия. Go медленно, но верно уходит от этого наследия.

Занимательный факт: я написал консенсус-предложение практически в самом начале обсуждения. Было понятно, что мы как минимум его попробуем. Было понятно, что Ben Kochie вызовется сделать это. И было понятно, что жертвой станет node_exporter. Как правило, мы стремимся совершенствовать рабочий процесс, и волонтером всегда выступает Ben, а node_exporter является тем тестовым стендом, с которого мы потом копируем результаты в другие экспортеры. И да, было важно, чтобы обсуждение продолжалось некоторое время и чтобы люди сами пришли к этому, вместо того, чтобы ставить их перед фактом.

КОНСЕНСУС: Удалить его в node_exporter и посмотреть, довольны ли мы будем результатом.

Списки рассылки и IRC


Google заблокирован в Китае, однако наши списки рассылки работают на нем. Мы решили попробовать сделать так, чтобы можно было подписываться по электронной почте. Я проверил: prometheus-users+subscribe@googlegroups.com работает. Также можно почитать архивы (https://www.mail-archive.com/prometheus-users@googlegroups.com/maillist.html), если есть такое желание.

Кроме того, мы позаботились о том, чтобы все желающие могли использовать IRC через Matrix, поскольку для некоторых xkcd 1782 весьма актуален.

КОНСЕНСУС:

Посмотреть, возможно ли подписываться на наши списки рассылок без учетки Google и подключить этот функционал; для публикации по-прежнему требуется подписка.

Добавить ссылку на общедоступный архив списков рассылок в разделе docs/community и рассказать, как можно подписаться на рассылки без учетной записи Google.

Отключить требования идентификации в каналах IRC, чтобы упростить использование Matrix; вернуть все назад, если будут атаки.

Документация


Позвольте повторить слова, сказанные на саммите: Самое первое, что мне не понравилось в Prometheus в 2015, году это документация; в 2020-м я ее просто ненавижу. Она сложна в использовании и почти бесполезна, подходит только тем, кто уже знает, что делает, или по крайней мере хорошо представляет себе концепции. Короче говоря, мы будем работать в этом направлении:

КОНСЕНСУС:

Мы разделим документацию на три части:

* Руководство пользователя (user manual) как простой для понимания вариант по умолчанию.
* Справка (reference) по аналогии с той, что у нас сейчас есть с примерами на PromQL для ввода/вывода.
* Гайды (guides), желательно на модульной основе.

Мы попросим Diana Payton разработать единый стиль оформления, общую концепцию и т.п. для всей документации.

Мы постараемся не ломать ссылки понапрасну.

Если вам это интересно, в настоящее время мы ищем технического писателя в Grafana Cloud, который будет работать над официальной upstream-документацией для Prometheus. В конце концов, мы серьезно относимся к своим обязательствам перед сообществом.

Как обычно, записи по итогам dev-саммита будут опубликованы. Также можно почитать итоги саммита 2020-1 и саммитов прошлых лет.

P.S. от переводчика


Читайте также в нашем блоге:

Подробнее..
Категории: Сообщество , Kubernetes , Open source , Cloud native , Prometheus , Блог компании флант

Анонс онлайн-митапа по .NET три доклада о кроссплатформенных десктопных приложениях

24.11.2020 08:05:01 | Автор: admin

Вы уже не ждали, а мы сделали. В этот четверг, спустя почти год после предыдущего митапа, мы проводим первую (надеюсь, среди многих ?) онлайн-встречу с тремя бомбическими докладами про кроссплатформенные десктопные приложения. Миша Романов рассмотрит всевозможные фреймворки для кроссплатформенных приложений и расскажет, как и зачем. Никита Цуканов потравит байки про разработку Avalonia интероп с COM и автогенерированный CQRS прилагаются. А Саша Якунин расскажет о разработке библиотеки для отслеживания изменений в данных, которая позволяет делать real-time UI (как и другие штуки) действительно быстрыми.

Когда:26 ноября в 17:00 (Мск)
Где:Ютуб-канал Контура

Обзор кроссплатформенного GUI для.NET Миша Романов, разработчик в Контуре

.Net Core поставил знак равенства между словами .NETи кросплатформенно, но только для консоли и веба. А как же десктоп? В своем докладе Миша сделает обзор нескольких кроссплатформенных GUI-фреймворков, доступных.NET-разработчикам: от широко известных (таких, как Avalonia и GTK#) до малознакомых, но интересных (например, Eto.Forms).

Как добавляются новые фичи в Avalonia UI Никита Цуканов, основатель Avalonia UI O

На какие жертвы приходится идти, чтобы сделать UI действительно кроссплатформенным?

Никита поделится своим опытом разработки Авалонии самого крупного из кроссплатформенныхфреймворков на .NET. Он расскажет, как в Авалонии разрабатывался предпросмотр XAML, каким образом добавлялся интероп с COM и почему разработка плавных анимаций закончилась автогенерацией CQRS в движке рендеринга.

Эффективное кэширование или как получить максимальный RPS и real-time UI Саша Якунин, CTO в ServiceTitan

Саша автор библиотеки Fusion. Он расскажет вам, как относительно простая абстракция поможет серьезно повысить производительность веб-сервисов и сделать весь UI вашего приложения обновляемым в реальном времени. Разберёмся, как все это связано с Blazor, two hard things in computer science, eventual consistency, новизной React, и другими, казалось бы, несвязанными, проблемами.

До встречи! Жмите колокольчик на Ютубе, готовьте горячительные напитки, регистрируйтесь и подключайтесь к онлайн-митапу Kontur Tech Talks по .NET.

Подробнее..
Категории: Сообщество , Конференции , Митап , C , Net , Блог компании контур , Контур , Konturtechtalks

Ростов-на-Дону IT-компании, сообщества и мероприятия в 2020 году

25.03.2021 16:19:55 | Автор: admin

Если бы ИТ-столицы России светились в темноте, то в Ростовской области были белые ночи.

В прошлой статье "Ростов-на-Дону: IT-компании, сообщества и мероприятия в 2019 году" я рассказывал о том, чем живёт и из чего состоит Ростовское сообщество как мы собираем 60-70 митапов в год, какие компании есть в городе и чем они занимаются.

Готова подборка интересного из 2020 и планы на 2021 год новые сообщества, бум митапов, ИТ-конференция с бассейном и результаты опроса о том, где хотят работать местные разработчики. А еще немного про уникальныи феномен Таганрога города с самои большои концентрациеи ИТ-специалистов на человека. И, конечно, приглашение в гости к Ростовскому ИТ-сообществу. Но давайте по порядку.

Так у нас выглядит ИТ-конференцияТак у нас выглядит ИТ-конференция

ИТ-компании

В этом году в опросе узнаваемости и привлекательности ИТ-компаний поучаствовали больше 1.000 человек из местного ИТ-сообщества. А ещё появился новый сайт с результатами, где можно сравнить данные за два года и заодно посмотреть кто такие эти наши Ростовские ИТ.

Всего на графиках можно узнать про 100+ компаний, а вот что мы узнали в этом году про Ростов (кроме того, что он ИТ-столица России) и про Таганрог (кроме того, что он ИТ-столица России):

  • QA в Ростове чаще всего хотят работать в местном офисе международного финтехаDevexperts, а в Таганроге QA выбирают e-commerceOggetto,DistilleryиArcadia. Привлекательность Аркадии за год выросла в пять раз, а всё благодаря QARATE, серии воркшопов и митапов про тестирование и качество ПО, которую начала делать компания;

  • .net-программисты любят Контур в Ростове и Аркадия в Таганроге. А, возможно, Ростовские дотнетчики просто не знают, что у Аркадии есть офис и там ;)

  • Джависты в Таганроге с двойным отрывом по популярности выбираютDistillery, а Ростовские ждут вакансий разработчика вTINKOFF;

  • Геймдева в Ростове и Тагане хватает, но среди опрошенных в почёте больше всего Лайт мэп;

  • Аналитики проголосовали заDistillery и Accenture;

  • DevOps-инженеры знают, что их ждут в @TELE2 и TINKOFF, их и выбирают;

  • Почти все студенты в Тагане знают по крайней мере 10 ИТ-компаний. В Ростове такой славы удостоились только банки и телеком;

  • Единственный Elm-разработчик, который ответил на вопрос с прошлого года переехал из Ростова в Таганрог и постарел на 12 лет;

  • На митапы стало ходить вдвое больше людей благо в 2020ом для этого даже идти никуда было не обязательно;

  • 5 самых мотивирующих вещей при выборе работе для тех, кто заполнил опрос это: уровень оплаты, возможности для профессионального роста, хорошие отношения в коллективе, белая зарплата / соблюдение ТК и гибкий график

  • В Ростове чаще всего хотят работать или в TINKOFF или в местном офисе международного финтеха Devexperts. Ещё любят @TELE2, Сбер, Контур, РнД Софт все они и узнаваемые и достаточно привлекательные);

  • Средняя узнаваемость всех Ростовских ИТ-компаний среди людей, которые посещают митапы 29.2%. Тоже самое среди тех, кто на митапы не ходит 21.4%. Можно сказать, что люди, которые ходят на митапы в полтора раза лучше ориентируются в местном ИТ-рынке.

Таганрог

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

Все лидеры (да и почти все компании в Таганроге) специализируются на заказной разработке для европейских и американских заказчиков. Это значит, что частым требованием в работе является хороший английский, а зарплата привязана к доллару.

Таганрог расположен на берегу Таганрогского залива. Это ещё не море, но почти в черте города есть пляжи, прокат кайтов и виндсёрфинг.

Набережная, порт и старый центр ТаганрогаНабережная, порт и старый центр Таганрога

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

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

Сообщество и мероприятия

Ожидание

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

И сколько же раз у нас получилось собраться вместе на оффлайн-мероприятиях в 2020? 2? 5? Мы чуть-чуть спросили об этом у местной аудитории и получили такой результат: 80% ответивших на вопрос в считают, что местное IT-сообщество собиралось на открытые мероприятия в 2020ом не больше 10 раз.

Реальность

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

52 митапа от местных организаторов и для местного сообщества, из них 28 в смешенном формате с оффлайном. Мы сами не ожидали таких цифр, поэтому собрали в одном месте все местные ИТ-мероприятия за год.

Главные ИТ-события 2020 в Ростове:

  • У нас появилось новое сообщество "Тимлид на диване" с регулярными тематическими встречами и очень интересным чатом в телеграме. Совсем недавно прошёл шестой митап про командообразование и построение метакоманд, а на youtube-канале уже есть свежая запись. Тимлидам вообще повезло для них в 2020ом было больше десятка мероприятий;

  • Для QA было целых 7 мероприятий, всё потому, что Аркадия активно поднимает культуру качества и тестирования с их QArate;

  • За год мы сделали 2 больших онлайна на весь день WTM провёл International Women's Day 2020 в июне, а в конце мая RndTech и GDG Rostov сделали онлайн-паб про облака, тренды мобильной разработки и карьеру для JS-разработчиков;

  • 12 сентября случилась RndTechConf оффлайн-конференция с 5 потоками выступлений про бэкенд, фронтенд, мобилки, менеджмент и девопс. На свежем воздухе. С бассейном. И мангалами. И йогой. И полянками для общения. И стендапом. И сап-сёрфами. В общем, лучше один раз увидеть.

Таблица с полным списком митапов и конференций 2020 по датам и целевой аудитории

Дата

Митап

Оффлайн?

Для кого

16.01

Product Mindset Meetup #4 by RndTech

+

Для продуктологов, продуктовых аналитиков, ИТ-менеджеров

17.01

.meetup #2

+

Для хардкорщиков, аппаратчиков и функциональщиков

18.01

Mobile meetup by GDG Taganrog

+

Для мобильных разработчиков и их тимлидов

23.01

IT61job Meetup: OKR

+

Для ИТ-менеджеров и функциональных руководителей

30.01

Code In The Dark! Битва верстальщиков

+

Для верстальщиков

8.02

Воркшоп "Решение рабочих конфликтов"

+

Для тимлидов и тех, кто работает в команде

15.02

Flutter StudyJam

+

Для мобильщиков и кроссплатформщиков

15.02

#QArate 2

+

Для QA и тестировщиков

20.02

Python meetup #2

+

Для питонистов

25.02

IT61job Meetup #2: Управление командой

+

Для ИТ-менеджеров и функциональных руководителей

28.02

Digital Pain: менеджмент

+

Для начинающих менеджеров в digital

29.02

RND PHP #2

+

Для PHP-программистов

29.02

JavaScript GameDev Workshop

+

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

29.02

QARATE #3 Wayback QA Workshop

+

Для QA и тестировщиков

05.03

RndTechTalks.Architecture #2

+

Для архитекторов, техлидов и сеньоров

4.03

ФП среда "Зависимые типы, которые могут навредить"

+

Для функциональщиков

13.03

.meetup #3

+

Для хардкорщиков, аппаратчиков и функциональщиков

14.03

Практикум по Elm и Elixir: полный стек на функциональных языках программирования

+

Для практикующих функциональщиков

18.03

dxTechTalk 10 - Frontend Day

-

Для фронтендеров

26.03

RndTechTalks.QA 3

-

Для QA

29.03

Rostov GDC #2 game dev meetup

+

Для всех-всех из геймдева

01.04

IT Standup Online (и это не шутка)

-

Для сообщества

07.04

QARATE 4: Как ломать ПО

-

Для тестировщиков и их программистов

15.04

DistilleryTech. DevOps for Developers

-

Для разработчиков

28.04

Cеминар о сшивании изображений Points & Descriptors от CVisionLab

-

Для тех, кому интересна обработка изображений

28.04

QARATE 5: Автоматизация в web

-

Для QA и тестировщиков

14.05

Тимлид на диване

-

Для тимлидов и будущих тимлидов

16.05

GDG Taganrog Web Meetup

-

Для разработчиков

22.05

Онлайн-хакатон Ростовской области про снижение последствий Covid-19

-

Для всех неравнодушных

23.05

Онлайн-паб RndTech и GDG Rostov: мобилки, JS, облака

-

Для всех, кто ходил на мероприятия не за докладами, а за атмосферой

26.05

QARATE 6

-

Для QA и тестировщиков

14.06

International Women's Day 2020

-

Для женщин в ИТ и от женщин в ИТ

19.06

QARATalk

-

Для QA и тестировщиков

23.06

Семинар CVisionLab "Camera calibration & Stereovision"

-

Для тех, кому интересна обработка изображений

25.06

DistilleryTech.Agile

-

Для тимлидов, разработчиков в agile-комнандах

30.06

dxTechTalk Becoming a Business Analyst

-

Для аналитиков и тех, кто хочет понять, чем они занимаются

2.07

Тимлид на диване 2

-

Для тимлидов и будущих тимлидов

9.07

CVisionLab про "CVPR 2020"

-

Для интересующихся компьютерным зрением, распознаванием образов и всем, что рядом

9.07

Митап Докер в банке

-

Для девопс-инженеров и их разработчиков

13.08

Тимлид на диване 3

-

Для тимлидов и будущих тимлидов

20.08

RndTechTalks.Management 3

+

Для тимлидов, будущих тимлидов, их менеджеров и функциональных руководителей

01.09

Тимлид на диване 4

-

Для тимлидов и будущих тимлидов

11.09

IT61job WORKSHOP Kanban

+

Для всех, кто хочет вкатиться в канбан

12.09

GDG South DevFest && RndTechConf

+

Для сообщества

13.09

Workshop Романа Сороки Эффективная команда и брейнсторм

+

Для тимлидов и будущих тимлидов

28.09

.meetup #4

+

Для хардкорщиков, аппаратчиков и функциональщиков

8.10

Вёрстка батл!

+

Для фронтендеров и верстальищков

30.10

Хакатон по ИБ

-

Для интересующихся ИБ

5.11

Совместный просмотр Ru |> Elixir |> Meetup

+

Для экликсирщиков

21.11

Встреча Papers We Love #1

+

Для интересущихся 3D-графикой

10.12

Митап на английском "IT Matters"

+

Для сообщества

15.12

Тимлид на диване 5

-

Для тимлидов и будущих тимлидов

2021

Читать про прошедшие конференции не так интересно. Поэтому, у меня есть небольшой call to action, если вы живете в Ростове или хотите приехать и посмотреть на наше сообщество.

Во-первых, у нас есть call for papers для митапов если собираетесь приехать, то мы умеем неплохо подстраивать митап под спикеров и заполнять программу :)

Во-вторых, мы уже запланировали RndTechConf 2021 на сайте можно подать доклад, взять early bird билет или посмотреть записи докладов с предыдущей конференции.

Если прямо сейчас планов нет есть специальный телеграм-канал и группа на meetup.com, куда мы бережно складываем все ИТ-ивенты региона. Можно следить за чем-нибудь интересным для вас или подключаться к трансляциям и онлайн-митапам.

И хорошего вам года.

Подробнее..
Категории: Сообщество , Конференции , Хакатоны , Митапы , Карьера в it-индустрии , Управление сообществом , Ит-компании , Релокация , Devrel , Ростов-на-дону , Таганрог , Митапы в ростове

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru