«Желательно, чтобы у вас был котик» — как стартапу выстрелить на Product Hunt

Публикация на агрегаторе стартапов Product Hunt — хороший способ привлечь к себе внимание международных СМИ и инвестиционных фондов. При этом самого факта публикации недостаточно. О том, как подготовиться к выходу на Product Hunt и чего нельзя делать во время гонки, на примере OneSoil Map рассказывает менеджер по маркетингу Вероника Линдоренко.

image


* Статья была опубликована 13.02.2019 на сайте Probusiness.io

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

— 23 октября 2018 года мы разместили презентацию своей интерактивной карты OneSoil Map на Product Hunt. Мы набрали 1563 голоса, что беспрецедентно для продукта из AgTech-сферы, и хотим поделиться опытом, чтобы коллеги могли, при желании, последовать нашим советам и избежать промахов, которые мы совершили.

Прежде чем размещать свой продукт на Product Hunt, подумайте, насколько вам может быть полезна эта площадка. Если у вас интересный и полезный продукт, который можно изучить за пару минут и сделать вывод, то Product Hunt может быть отличным стартом. Это важно, потому что в течение дня вы будете соревноваться с очень разными продуктами, например, с развлекательными приложениями типа TikTok, с hardware вроде Angee, расширениями для браузера, видеоредакторами и менеджерами паролей.

Если у вас — сложный софт, для использования которого нужно прочитать десятки тьюториалов и поговорить с технической поддержкой, то лучше выбрать другую площадку для продвижения. Например, рекламу в Facebook или Google Ads, посты на FAQ типа reddit.com, quora.com, SEO или ASO. Это также могут быть участие в митапах и конференциях, прямые продажи через LinkedIn. Хорошо работают статьи на тематических сайтах. Все очень индивидуально. Для того чтобы дать хороший совет по маркетингу ИТ-продукта, нужно разбирать каждый кейс отдельно.

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

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

Для чего вам нужен Product Hunt

Запускать продукт на Product Hunt нужно по трем причинам:

1. Это хороший способ заявить о себе. Product Hunt — это агрегатор стартапов, который известен во всем мире, а особенно в США и Западной Европе. С помощью него можно рассказать о новом продукте многочисленным участникам платформы: создателям приложений, новостным медиа, инвесторам, представителям бизнеса. Последние 3 категории пользователей Product Hunt отслеживают успешные стартапы и, если им интересен проект, могут предложить сотрудничество. Мы, например, активно искали как бизнес-контакты, так и знакомства с американскими журналистами.

Опыт OneSoil Map на Product Hunt в цифрах:

  • Вышли на Product Hunt 23 октября
  • Набрали 1563 голоса
  • Получили публикации в десятках СМИ и сотни постов в соцсетях
  • Приняли около 300 писем с предложениями о сотрудничестве, полезными комментариями, комплиментами

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

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

Эти комментарии помогут понять ценность продукта, в правильном ли вы движетесь направлении и где есть моменты, которые стоит еще раз проработать

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

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

Чтобы «выстрелить» на Product Hunt

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

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

image

2. Выбрать правильное время для публикации продукта. Время голосования ограничено, и чем больше времени продукт находится в поле зрения участников Product Hunt, тем больше голосов вы наберете и больше вероятность попасть в топ-10 стартапов за день и находиться в течение дня на главной странице Product Hunt. В своем блоге основатели Product Hunt советуют публиковать продукт в 24:01 PST (в 10:00 по минскому времени). Это даст 24 часа на сбор голосов. Время окончания гонки — 23:59 PST.

Мы также ознакомились с данными о недельной активности пользователей Product Hunt и публиковали OneSoil Map во вторник в 10:00.

image
Активность пользователей Product Hunt в течение недели

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

image

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

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

5. Подготовить заранее все контакты. В день выхода на Product Hunt нужно трубить о своем продукте во всех новостях, и для этого необходимо проработать контакты заранее. Мы договаривались с белорусскими, американскими, европейскими медиа и журналистами, PR-партнер Bulba Ventures (фонда, который инвестировал в нас) помогла нам в этом — т.е. задействовали все ресурсы. Однако в связи с тем, что карту мы завершили перед самым днем запуска на Product Hunt, не все СМИ смогли ее увидеть и отреагировать.

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

При этом очень важно напоминать о событии как за несколько дней до релиза, так и в сам день релиза. Вот список ресурсов, которые опубликовали материалы о нас, он может пригодиться и вам: dev.by, 42.tut.by, bel.biz, kyky.org, tech.eu, zdnet.com, bigthink.com, cnet.com.

image
Рост количества голосов в течение дня

6. Воспользуйтесь силой лидеров мнений. Соберите список людей, у которых много подписчиков и которым интересен ваш продукт, и попросите их написать о вашем продукте в своих аккаунтах. Это могут быть ваши инвесторы, маркетологи, сооснователи стартапов, разработчики. Ищите также Telegram- и Slack-чаты с представителями вашей тематики и просите поддержать вас в день X. Есть еще Facebook-группы, сообщества в ВК, сабреддиты, форумы и лидеры мнений в Twitter. Используйте все каналы по максимуму.

Мы, например, просили создателей таких каналов, как TechSparks, Городские данные, All-in-One Person | Технологии, софт и все такое, NeuroHive написать о нашей карте новость. Все они отозвались и поддержали нас.

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

Мы считаем своим самым правильным шагом письмо Артемию Лебедеву. В определенный момент Саша Яковлев, сооснователь OneSoil, начал писать письма Илону Маску, Ричарду Аллену Гэрриоту, Артемию Лебедеву с просьбой оценить OneSoil Map и поддержать нас на Product Hunt. Мы не ждали каких-то особенных результатов, но на следующий день Артемий опубликовал информацию про нашу карту во всех своих социальных аккаунтах: Telegram-канал, VK, Facebook, Twitter, Livejournal.

image
Статистика посещений OneSoil Map. Пик – после публикаций Артемия

Его посты стали виральными, и в этот же день многие российские, украинские и белорусские СМИ написали о нашей карте. Это дало огромнейший пиар-эффект и большой трафик на map.onesoil.ai.

Чего делать нельзя

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

1. Привлекать слишком много новых юзеров. Будет лучше, если за ваш продукт отдадут голоса «динозавры» платформы, мейкеры других продуктов, а не те, кто в день вашего релиза впервые попал на Product Hunt, да еще и отдал голос только вашему продукту. Это может сказаться на рейтинге приложения.

Основатель Product Hunt Райан Хувер в своем Twitter-аккаунте также говорил о том, что алгоритм распознает недобросовестные действия и «наказывает» мейкера. Прямой призыв к голосованию распознается алгоритмом как хакерство, и за это могут понизить в позициях.

Просите о поддержке, а не о голосе за вас

Создайте заранее список с 20−30 лидерами Product Hunt, которым была бы интересна ваша тема (Topic), и свяжитесь с ними заранее. Расскажите им о продукте, попросите фидбек.

2. Собирать много апвоутов без перехода на страницу проекта. Хорошо, если люди не просто голосуют, а переходят на страницу продукта, исследуют проект, а затем уже ставят голос. Еще лучше, если они оставят review или добавят комментарий, который приведет к активной дискуссии среди участников Product Hunt. Наш хантер Chris Messina писал мне об этом в день публикации, когда мы уже просели в позициях.

image

Советы для всех

  • Подготовьте to-do list, согласно которому будете совершать все действия в день запуска, времени на раздумья у вас не будет
  • Подготовьте все маркетинговые материалы и список мест для продвижения страницы вашего продукта на Product Hunt заранее
  • Опубликуйте свой продукт заранее в проекте Ship. Здесь можно еще до оформления проекта рассказать о нем, собрать лояльную аудиторию и получить фидбек
  • Почитайте, как проходит «охота» на продукт в блоге Product Hunt
  • Изучите эти рекомендации
  • Добавьте кнопку на странице вашего продукта, которая будет вести на Product Hunt c ненавязчивым предложением поддержать вас. Но только не просите «проголосовать»
  • Подготовьте разные сообщения для разных сообществ
  • Активно используйте Twitter как одну из наиболее популярных социальных сетей в США и Западной Европе. Можно делать Tweets с упоминанием пользователей и своего продукта, но не пишите прямых сообщений — за это штрафуют
  • Попросите друзей и знакомых комментировать ваши посты и сами быстро отвечайте на комментарии — это значительно влияет на ваше место в гонке на Product Hunt
  • Подготовьте пресс-релиз для журналистов и разместите его на сайте продукта
  • Сделайте рассылку пользователям своего продукта, если они уже есть
  • Подготовьте красивые картинки для социальных медиа (желательно, чтобы там был логотип Product Hunt и котик:)
  • Прокачайте заранее профили мейкеров своего продукта: подпишитесь на рассылку, голосуйте за продукты в течение минимум трех дней
  • Сделайте кнопки шаринга (FB, Twitter) со снипетом, включающим красивую картинку и текст о продукте
  • Добавьтесь в чат Maker на Product Hunt и там расскажите о своем продукте
  • Подготовьте список FAQ, чтобы оттуда брать готовые ответы на вопросы юзеров. Это ускорит процесс ответа на вопросы в комментариях к продукту
  • Почитайте этот thread, созданный Максимом Каменковым, CEO и сооснователем SplitMetrics и SearchAdsHQ, — здесь вы найдете большое количество интересных фактов.

И ещё кое-что

Никто, кроме создателей PH, не знает, как работает алгоритм, и многие советы основаны на ошибках, совершенных самими мейкерами. Главное — не делать то, что будет казаться обманом или хитростью для Product Hunt. Старайтесь сохранять баланс трафика, не клянчить голоса и дружить с Product Hunt-сообществом.

Апдейт от команды OneSoil

В день запуска наш проект стал пятым в рейтинге из-за ряда промахов. Несмотря на это, в декабре 2018 команда Product Hunt назвала OneSoil Map продуктом года в категории AI & Machine Learning. Так что всегда боритесь до конца! А чтобы закрепить информацию и точно понимать, что такое хорошо и что такое плохо для Product Hunt, посмотрите выступление Вероники в минском Парке Высоких Технологий (начинается с 35 минуты).

Удачного запуска!


ссылка на оригинал статьи https://habr.com/ru/post/454990/

CAN или не CAN? Или зачем мне сеть микроконтроллеров?

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

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

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

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

И вот, помнится, глянул за окно, а там 21-й век. Стало быть надо все делать заново и по-другому. Вместо лампочек — экономичные светодиоды. Вместо проводов — проводки. Вместо одного ящика — много-много маленьких ящичков, контроллеров, стало быть.

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

К тому времени я уже знал, что такое CAN и уровень моего уважения к фирме Bosch был много выше, нежели у повара приличного ресторана или аккуратной домохозяйки. А производители автомобилей BMW, я уверен, даже ходили к инженерам Bosch в гости.

Controller Area Network, как сказали бы иностранцы, на мой взгляд, как техническое решение, возникло из желания сделать что-то, наконец, хорошо. Не скрою, все прелести результатов работы инженеров почувствуешь не сразу, как осилишь два тома стандарта, а значительно позже. Когда пообщаешься с очевидцами, опросишь свидетелей. Сейчас томов прибавилось, но, может быть, можно сразу начинать с третьего, поскольку, теперь оно называется CAN_FD. Однако, позвольте продолжить.

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

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

CAN можно установить там, где раньше работал RS485 на витой паре. Витая пара — это не непременное условие, просто удобно сравнивать. Используя витую пару, по CAN, как и по RS485, можно передать сообщения от управляющего контроллера к подчиненному и получить ответ. Сходство бросается в глаза, но, давайте лучше остановимся на отличиях. Кое-какие из отличий могут нести знак минус для некоторых из читателей. Но им бы я посоветовал не огорчаться, а вспомнить закон Ломоносова.

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

Можно получить сообщение и без запроса.
Не надо ждать, когда ответ будет готов, можно спросить в это время еще кого-то.
Подчиненный контроллер тоже может спросить и получить ответ.
Из-за синхронной работы длина шины CAN обратно пропорциональна скорости передачи или типа того.
Максимальная скорость составляет 1 Мбод (10 — на подходе).
То, что сообщение не исказилось при передаче отправляющий знает сразу после последнего бита. Точнее, это знают все на шине.
Если сообщение исказилось для одного, попытка не засчитывается всеми.
Если сообщение удалось передать в шину, то абонент не получит его лишь при условии, что сломался.
Количество контроллеров на шине не должно превышать 127.

Сообщения ограничены по длине. Они состоят из идентификатора, указателя длины в байтах и блока данных, именно с таким количеством байт, как указано. Есть еще несколько служебных битов, но о них пока помолчим, поскольку сервис должен быть ненавязчивым. Идентификатор может быть размером 11 или 29 бит. Блок данных может содержать от 0 до 8 байт (64 — на подходе).

Для конкретики приведу немного цифр. Если хочется работать на скорости 1Мбод, то длина шины не должна быть больше 35 метров (некоторые предпочитают 40, то есть, погорячее). Если необходимо передать что-то на расстояние до 8 км, то скорость не должна превышать 5 Кбод. Кстати, читатель вправе спросить, почему килобод, а не килобит? Потому, что не все боды становятся битами. Как-то так.

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

В те времена, когда 29 битовый идентификатора еще не успели придумать, существовал только 11 битовый. Одни его стали использовать, чтобы запихнуть туда название (номер) нужного вида данных. Другие использовали как адрес контроллера, к которому обращаются. И то и другое имело смысл. Например, можно спросить так:

  • А подай-ка нам, милейший, шато тринадцатого года в литровой бумажной упаковке.

Или так:

  • Заверните мне, пожалуйста, то, что спрятано у вас на самой нижней полке справа.
    Кстати, в CAN может сработать и такая конструкция:
    -Всем лежать! А ты быстро складывай все с полок мне в сумку.
    Но этой конструкцией часто не попользуешься, поскольку после придется какое-то время ждать.
    Ждать пока все ответы не выстроятся один за другим и не поступят в распоряжение запрашивающего контроллера. Мы уже ушли от кино, если что.
    Меня в моем случае устроил бы вариант идентификатора в качестве адреса. Из 11 бит требовалось 7 и еще 4 оставалось на то, чтобы сделать одни сообщения более срочными по сравнению с другими, а также пометить часть контроллеров как главные.
    Некоторое неудобство перекочевало сюда из RS485, а именно, адреса надо было устанавливать вручную на каждом контроллере. Затем проверять и переустанавливать. И, возможно, вернуться к предыдущему шагу и повторить.
    К счастью, к тому времени уже существовали два обстоятельства.

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

Теперь в длинном идентификаторе можно было 24 бита смело отвести для уникального адреса. Еще 5 оставалось, для заботы о том, чтобы поезда различались срочностью, направлением (туда, обратно), наличием вагона-ресторана и вагонов с повышенным комфортом.

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

Еще немного про адресацию. Уникальный номер чипа, как правило, занимает количество битов значительно превышающее 24, например, 96 у STM32FXXX. Поэтому необходимо как-то получить 24 из 96. Я выбрал операцию XOR. Вы можете выбрать что-то другое, но небольшая проблема останется. Это совпадения адресов после редуцирования.

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

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

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

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

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

Вернемся к кодированию идентификатора.

Для целей адресации в расширенном идентификаторе отведено 24 бита, а в стандартном – шесть. Адрес со значением 0x000000 является широковещательным для расширенного идентификатора. Для стандартного идентификатора нулевой адрес (6 его бит) также считается широковещательным. Пять начальных (старших) битов в длинном и коротком идентификаторе, называются заголовком, влияют на смысл сообщения и обозначаются буквами NVADR:

Конечно, для диспетчерского щита потребовалось реализовать только часть этой схемы. В первом проекте со щитом (или на щите, как правильно?) использовались чипы Cortex от NXP, а в следующих проектах (были и такие) уже применялись M0 от STMicroelectronics.

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

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

Запрос с длиной 5 и 6, аналогично, предназначены для пространства двухбайтовых переменных размером 4194304. Два бита используются не для адресации. Один бит управляет записью-чтением. Другой сигнализирует об ошибке.

Далее 7 и 8 обслуживают четырех байтовые слова. Их тоже 4194304.

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

Соединяются контроллеры плоским шлейфом на 6 жил. На питание идут сдвоенные. Микросхема о двадцати ногах — это STM32F042.

С обратной стороны присутствует MAX3051, формирователь CAN в корпусе SOT23-8.
Ну вот, мама кушать зовет.


ссылка на оригинал статьи https://habr.com/ru/post/455620/

Продумываем персонажей игр и диалоги по советам писателей и на примере сторонников теории плоской Земли

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

А еще там разбирается характер персонажей на примере сторонников теории плоской Земли.


Сценарий фильма «Апокалипсис сегодня» (1979) по мотивам книги Джозефа Конрада «Сердце тьмы» (1899)

Предисловие

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

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

Теперь я покажу свои заметки после встреч с писателями и дополню их мыслями из книги Джона Йорка Into The Woods — такие примечания будут отмечены аббревиатурой ITW. Надеюсь, они будут полезны.

Характер против характеристики

В основе характера лежит конфликт между тем, как мы хотим, чтобы нас воспринимали, и тем, что мы действительно чувствуем [ITW]. Или другими словами: конфликт между нашей характеристикой (образом) и нашим реальным характером лежит в основе всего (драмы).

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

А поддерживая свой образ, персонажи говорят так, как хотят выглядеть в глазах других [ITW].

Написание диалогов

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

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

Итак, первое — это создание характера.

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

  • Какой он на публике? Добрый, вспыльчивый, постоянно торопится?
  • Когда он один в туалете, вдали от всех — какие мысли первыми приходят ему в голову?
  • Откуда он родом и куда направляются? Он из бедного или богатого места? Из тихого или оживленного? Разрывается ли они между ними?
  • Что он любит? Что ему не нравится? Если он пришел на свидание, а ему заказали еду, которую он не любит — как он отреагируют?
  • Он умеет водить? Он любит водить? Как он ведет себя на дороге?
  • Он нашел свою старую фотографию: в зависимости от того, когда и с кем был сделан снимок — как он отреагирует?

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

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

«Как дела?», — спрашивает он.

Она отвечает: «Хорошо. Спасибо».

«У меня тоже отлично», — говорит мужчина.

«Мм, понятно», — говорит она. Мужчина прочищает горло.

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

Наглядным примером является начальная сцена в фильме «Социальная сеть» (2010), где герои общаются. В поиске есть куча роликов с анализом, поэтому не буду повторяться.


Социальная сеть (2010, Дэвид Финчер)

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

Референсы персонажей

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

Как-то в пабе я разговорился с алкоголиком. Когда-то он был хорошим застройщиком и риэлтором. Он рассказал одну интересную вещь — свою теорию о вырождении мужчин. Звучала она так: в 70-х и 80-х годах начали массово закрывать мужские клубы. Из-за этого им практически негде было торчать с другими мужчинами (имеется ввиду без жен и женщин). За одним исключением — букмекерских контор. Поэтому спрос на ставки резко возрос, новые конторы открывались как на дрожжах, а мужчины все больше деградировали. Я спросил его, не повлияло ли закрытие шахт на Севере (и последующая массовая безработица) на появление букмекерских контор. Он согласился, довольный таким дополнением своей теории. Но потом он постучал пальцем по виску и сказал: «Но такие люди, как мы, на это не попадаются — знаешь, умные люди. Мы не теряем время в этих букмекерских конторах». С триумфальным кивком он залпом выпил то, что, вероятно, было 25-й пинтой на неделе. Днем, в мрачном пабе. Конфликт персонифицирован.

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

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

Есть такая документалка Behind The Curve («За изгибом», 2018) о группе сторонников теории плоской Земли. Там не очень подробно говорится об их идеологии, зато это отличный фильм для изучения характеров самих персонажей.

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

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

В фильме есть момент, где она говорит что-то вроде (не дословно): «Люди называли меня ящерицей, говорили, что я работаю на ФБР или являюсь марионеткой некой организации».

Затем наступает момент, когда она находится на пороге осознания. Можно заметить, как она замирает при мысли, что вещи, которые про нее говорят — глупы и не правда. Но ведь она говорила то же самое о других людях. Было ли это глупо? А что если теории плоской Земли не соответствует действительности? Была ли она права все это время?

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

Это замечательные пять секунд.

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

В итоге

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

Ваш персонаж готов, но они слишком натянут и не привлекателен? Ему нужны конфликт и образ, трения и запутанность.

Персонажи создают новых персонажей.

Ищите персонажей вокруг себя в реальной жизни.


ссылка на оригинал статьи https://habr.com/ru/post/455612/

Wallarm Offzone2019 HackQuest

image

Всем привет! До старта конференции Offzone2019 осталось 7 дней и команда Wallarm по этому поводу подготовила HackQuest.

С сегодняшнего дня в канале Telegram t.me/offzone2019hackquest каждый день будут появляться задания. Первый, кто решает очередную задачу, получает билет на Offzone2019.

image

Квест стартует уже сегодня в 21.00 по МСК.


ссылка на оригинал статьи https://habr.com/ru/post/455626/

Внимание! Опасный баг в реализации C++ std::map::merge и std::set::merge в Visual Studio 2017

Если Вы используете стандарт C++17 в MS Visual Studio 2017 — будьте осторожны: текущая версия содержит критический баг в реализации std::map::merge и std::set::merge. Подробности — под катом.

Как проявляется баг?

  1. Сложность std::map::merge и std::set::merge вместо заявленной стандартом N*log(size()+N)), где N — размер добавляемой части, оказывается примерно N в квадрате.
  2. Если с помощью merge был добавлен контейнер с достаточно большим количеством элементов — при уничтожении результирующего контейнера получим stack overflow.
  3. Контейнер после работы merge приходит в некорректное состояние, поэтому возможны и другие проявления.

Что говорит Microsoft?

Багрепорт был отправлен мной в Microsoft почти 2 месяца назад.
В Visual Studio 2019 Update 2 Preview 2 должны были исправить.

А вот в текущей версии Visual Studio 2017 15.9.12 не исправлено до сих пор, и, судя по последним сообщениям, ждать еще долго…

Баг заключается в некорректной маркировке цвета добавленных узлов в реализации красно-чёрного дерева.

Как воспроизвести?

//#include "pch.h"  #include <chrono> #include <string> #include <iostream> #include <map> #include <set>   const size_t mainSize = 50'000; const size_t additionSize = mainSize;   auto getMainMap() {   std::map<size_t, std::string> result;   while( result.size() < mainSize )     result.emplace(result.size(), "SomeText");    return result; }   auto getAdditionMap() {   std::map<size_t, std::string> result;   while ( result.size() < additionSize )     result.emplace(mainSize + result.size(), "SomeAdditionText");    return result; }   int main() {   {     auto mainMap = getMainMap();     auto addition = getAdditionMap();      auto start = std::chrono::steady_clock::now();     for ( auto const &elem : addition )       mainMap.emplace(elem);     auto end = std::chrono::steady_clock::now();      std::cout << "manual insertion with copy: "               << std::chrono::duration_cast<std::chrono::microseconds>(end - start).count()               << std::endl;   }    {     auto mainMap = getMainMap();     auto addition = getAdditionMap();      auto start = std::chrono::steady_clock::now();     mainMap.merge(addition);     auto end = std::chrono::steady_clock::now();      std::cout << "std::map::merge: "               << std::chrono::duration_cast<std::chrono::microseconds>(end - start).count()               << std::endl;   } // <---- and stack overflow here because of incorrect mainMap after merge    return 0; } 

Варьируя значение mainSize, можно получать разные результаты — либо только медленное выполнение, либо еще и крах.

Что делать?

Пересмотреть свой код и заменить обращения к merge ручной вставкой. Либо перейти на VS 2019.
А если скомпилированный код уже ушёл к заказчику… Оххх…


ссылка на оригинал статьи https://habr.com/ru/post/455632/