Прототипирование

" Вы вообще очень странные существа, наконец сказал визирь. Вы даже устроены удивительно у вас мягкие ткани тела торчат наружу, а кость находится глубоко внутри.
А что тут такого? опешил я.
Нет логики, сказал кубарь. Логично, когда организм защищает панцирем свои мягкие ткани от внешней среды. Но какой смысл держать кости внутри организма, окружив их мягкой ранимой тканью? Словно вас раздирает что-то изнутри, словно вы опасаетесь агрессии изнутри больше, чем от окружающей среды." _{-- Леонид Каганов (рассказ 'Там где нет ветра')}

История tru3bicon

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

Суть tru3bic0n

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

Описание tru3bic0n

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

Применение tru3bic0n

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

Контекст tru3bic0n

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

Технологии tru3bic0n

На ранних итерациях для небольших партий - наиболее продуктивным способом изготовления представляется вытачивание рамы из монолитных заготовок посредством ЧПУ-фрезерования. В мелкосерийном производстве для оптимизации потерь времени/материала/оснастки целесообразными выглядят технологии литья в заполняемую форму по SLA 3D-печатным испаряемым моделям и металлическая 3D-печать по SLM-процессу. Относительно картриджей для электроники - пока вполне здравим смотрится планомерный путь от полимерной SLA/DLP/LCD 3D-печати, через двухкомпонентное литье в силиконовые формы, к штамповке пластиком в пресс-формах под давлением.

Ценность tru3bic0n

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

Планы tru3bic0n

Сейчас концепция корпуса еще довольна сыра и поверхностна, но если вектор фидбека окажется в позитивном ключе - планирую интенсивную проработку/дополнение/исправление. Относительно реализации, на данный момент есть только FDM-напечатанные габаритные модели - запланированные посредством ЧПУ-фрезерования прототипы из Д16Т отложены на март/апрель/май по причине тотального отстуствия в ДефолтСити вменяемых розничных поставщиков крупных алюминиевых заготовок, прототипы посредством литья через выгораемые модели пока малореальны по факту отсутствия у потенциальных изготовителей SLA-3D-принтеров с достаточно крупной рабочей камерой, прототипы посредством SLM-3D-печати теплопроводящими сплавами еще нецелесообразны по факторам чрезмерных затрат времени и ресурсов, которые требуются для этой сыроватой технологии. Буду рад любой конструктивной критике концепта, любым рацпредложениям по конструктиву, любой полезной информации для совершенствования корпусировки.

"- Куб значит частица куб значит воксель куб значит пиксель куб значит цель куб значит выбор куб значит свобода куб значит жизнь куб значит всё...
- Куб начинается и куб заканчивается я живу ради куба - у жизни нет другого смысла и у жизни есть смысл - смысл значит куб.
- Жизнь бессмысленна без цели, а у меня есть цель - у меня есть куб!" _{-- я (небольшая графоманская импровизация на тему философии кубарей в scp-стиле)}

Так сложилось исторически, что мой анонс opensource-проекта корпуса в кубической орбитальной пространственной раме оказался несколько противоречивым Вероятно, не будучи мастером изящной словестности, немного переборщил с краткостью/структурированием/метафоричностью. Данным постом попробую (для начала) немного раскрыть факторы гибкости, модульности и универсальности получившегося конструктива. Что ж, как говорят американцы японцы - лучше единожды лицезреть, нежели стократно невчитать.

Итак, представляю вашему вниманию десяток монтажных юзкейсов tru3bic0n в рендерах под спойлерами.

Напряженка с пространством? Две нехитрых горизонтальных монтажных скобы и можно не беспокоиться о габаритах корпуса, который теперь не занимает полезного пространства:

Закончилось место на стене? Крепим остальные корпуса к потолку вертикальным монтажными скобами:

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

Верхняя грань уже занята или нужно больше радиаторов? Крепим по бокам парочку пластин с сайд-радиаторами и теплокубиками:

Лениво сверлить стены/потолки? Монтируем корпус на vesa-крепеж монитора:

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

Есть потребность в частых вылазках на хакатоны/митапы/lan-пати? Добавляем складную рукоять и корпус превращается в "офигительный вместительный сундук":

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

Множество периферии порождает хаотичное проводное спагетти? Монтируем кабель-органайзеры на диагональные ребра и упорядочиваем спагети наматыванием:

Нужно больше корпусов в упорядоченном виде? Стекируем их комбо-крепежами хоть по всем 6 граням:

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

ps: все юзкейсы доступны под Creative Commons Attribution-Share Alike 3.0 License, модели под GPLv3 планирую опубликовать чуть позже.

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

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

Big Fucking Printer

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

• Разработать систему разметки поля

• Придумать маркер для нанесения краски на огромную площадь

• Переделать всю электронику робота, не кататься же на бееедуине, верно? Никто ведь так не делает, правда?

• Разработать стек навигации для робота

• Написать пару*строк кода

Ну что, строим?

Конечно же нет, ведь нужно выбрать из чего, как и сколько это будет стоить. Для решения вопроса с навигацией мы потратили не мало времени и ни одно копьё было сломано.SLAMотвергли наши программисты-питонисты-(дата сатанисты). Инерциальный датчик отвергли программисты-электронщики. А вот езда по тросу понравилась всем. Еще были такие варианты: расставить лазеры, расставить метки, использовать энкодеры на колёсах, лазерная рулетка,GPSи много всего другого. Размер нашего холста: 40x50 метров. Для определения текущего положения робота с точность до 1 см использовалась связка энкодера и инфракрасного датчика расстояния. При помощи ввёртышей и талрепов натягивается трос каждые 5 метров. На роботе устанавливается каретка с энкодером, ее отклонение фиксирует датчик расстояния. Трос проходит через энкодер и при смещении робота относительно троса, смещается и каретка. Конструкция хоть и простая, но на таких расстояниях крайне эффективная.

Допустим мы знаем наше положение на поле, но чем и как мы будем рисовать? А почему бы не использовать готовые решения? Итак, мы обзавелись обычным аэрографом, компрессором с ресивером и огромной направляющей из алюминия длинной в 5 метров. Каждые 10 сантиметров робот останавливается, аэрограф совершает поступательное движение по рельсе и наносит часть изображения. Для приведения аэрографа в движение к нему прикрутили мотор с шестерней, а на рельсе установили зубчатую рейку, бережно отфрезерованную из обрезков фанеры.

Теперь-то строим?

Почти. Моделируем. СвязкаSolidWorksиFusion360, запихнутая вGazebo это отдельный способ извращений, но команда состоит из творческих людей с различными взглядами на жизнь. Так или иначе, лучший файлообменник телеграмм соединяет сердца инженеров. Модель робота была кропотливо разработана вCADсистемах (а с нашим бюджетом мы не могли позволить купить лишних запчастей) и протестирована в симуляторе, ведь пруды чистые, а не черновые.

Итого, детали в пути, и мы приступаем к проектированию плат и написанию кода. Робототехников хлебом не корми, дай на питончике, да на плюсах покодить,а вот держи. Собственно мозгами робота сталиRaspberryPi,STM32-Discoveryи несколько плат с камушками серииSTM32F1. Их связь осуществляется черезUART. Для питания сего изобретения были выбраны литиевые аккумуляторы в сборке 12s8p, переваренные из батареиTeslaи два 12-вольтовых гелиевых аккумулятора. В качестве движителей общим решением были избраны моторыNema-23 с планетарными редукторами 1:4. Дешёвые драйверы двигателейTB6600 расплавились при первом включении, пришлось срочно искать замену DM860H.

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

Полевые испытания

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

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

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

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

Финальный эксперимент?

Чтобы управа района одобрила покраску Чистых Прудов, нам было необходимо продемонстрировать работоспособность робота. Итак, в последний раз мы отправляемся в хоккейную коробку. Что по изменениям? К краскопульту добавили шторки, чтобы краска не летела во все стороны, а также не намерзала на винтовой передаче. Добавили систему подачи краски в ресивер краскопульта. В качестве краски использовали колер, разбавленный спиртом. Как вы понимаете, спирта было потрачено много. Гелиевые аккумуляторы дополнились сборкой 4s8pиз тех же аккумуляторовTesla, которыеPanasonic.

Рисовать решили логотипYouTube-канала Техникум, они ездили с нами на испытания, поэтому мы захотели их отблагодарить.Окраска квадрата 5x5м заняла около 30 минут. На удивление, первый видимый результат получился удовлетворительным.

Ало, пустите на пруд?

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

P.S.

Сейчас мы продолжаем совершенствовать робота. Первоочередная задача перенос стека навигации на aruco метки, чтобы робота можно было использовать в помещениях. 17 апреля в университете науки и технологий НИТУ "МИСиС" пройдёт день открытых дверей. Мы будем рисовать логотип университета в центральном лобби, фотоотчёт будет в инсте.

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

Предыстория

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

Знакомство мое с этой темой происходило в нескольких направлениях.

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

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

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

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

Проблема бесконечного потока информации

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

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

Что я тогда сделал

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

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

Теперь про код

Из библиотек нам понадобится по большому счету только telethon

from telethon import TelegramClient, events, syncfrom telethon.tl.functions.channels import JoinChannelRequestimport re

Чтобы сделать робота, который будет подключаться к телеграму по API нам понадобится зарегистрировать свое приложение на странице https://my.telegram.org/, войти в аккаунт, нажать на "API development tools", заполнить первые 2 поля, в Platform выбрать Desktop.

Скопировать App api_id, App api_hash в соответствующие переменные ниже. А в переменную PHONE_NUMBER ввести номер телефона, который привязан к аккаунту телеграмм.

API_ID = 1234567 # вставье свой api_idAPI_HASH = 'your_hash'PHONE_NUMBER = '+7xxxxxxxxxx'  

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

 CHANNELS = (             'channel1_name',  # здесь вводятся имена каналов              'channel2_name',  # без https://t.me, @ или ссылок - просто имя    'channel3_name                 )  

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

# мэппингnames = {    'channel1_to_post': ['interesting_text1',                          'interesting_text2'],    'channel2_to_post': ['other_channel_interesting_text1',                          'other_channel_interesting_text2',                          'other_channel_interesting_text3'],}# "разворачивание" под другой формат хранения + приведение к низкому региструd = {}for name in names.keys():    for t in names[name]:        d[t.lower()] = name.lower()print(d)

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

client = TelegramClient('session', API_ID, API_HASH)client.start()for channel in CHANNELS:    client(JoinChannelRequest(channel))

Далее собственно ожидание нового сообщения, проверка по шаблон и принятие решения, куда делать репост

# Ожидание новых постов и пересылка@client.on(events.NewMessage(CHANNELS))async def handler(event):    print(f'received text: {event.message.message}')        for tmp in d.keys():      await client.forward_messages(d[tmp], event.message)client.run_until_disconnected()

В итоге получилась целая сетка телеграм каналов (в каждом из которых выходит по паре твитов в день, в отличие от 150 в исходных каналах)

t.me/tesla_twits- Tesla
t.me/apple_twits- Apple
t.me/amazon_twits- Amazon
t.me/moderna_twits- Moderna
t.me/pfizer_twits- Pfizer
t.me/google_twits- Google
t.me/facebook_twits- Facebook
t.me/microsoft_twits- Microsoft
t.me/yandex_twits- Яндекс
t.me/mailru_twits- Mail.ru
t.me/mts_twits- МТС
t.me/aeroflot_twits- Аэрофлот
t.me/rosneft_twits- Роснефть
t.me/sber_twits- Сбер
t.me/gazprom_twits- Газпром
t.me/afk_twits- АФК Система
t.me/nornickel_twits- Норникель
t.me/vtb_twits- ВТБ
t.me/rusal_twits- Русал
t.me/lukoil_twits- Лукойл

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

Всем добра!

Вот уже несколько лет производители электроники говорят о новой прорывной технологии, которая изменит привычные нам устройства и подход к их проектированию: никаких больше механических кнопок и переключателей, сокращение толщины до 2 мм, снижение веса на 70%, а себестоимости на 30%. Причем речь идет не о будущих серийных устройствах типа экрана с двойным сложением, который недавно представила Samsung, а о технологии производства, которая уже сейчас используется в автомобилях, бытовой технике и IoT-гаджетах. Эта технология называется литье с интегрированной / встроенной электроникой или In-Mold Electronics (IME).

На Хабре эту интересную тему еще почему-то не затрагивали. Исправляем это досадное недоразумение.

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

А теперь давайте обо всем по порядку. Литье с интегрированной электроникой это одно из направлений литья с декорированием в форме, о котором мы уже рассказывали на Хабре. В англоязычных инженерных публикациях такая технология называется In-Mold Decoration (IMD). Напомним, что корпус декорируется под давлением прямо в пресс-форме или в процессе выдувного формования.

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

Принцип маркировки в форме (In-Mold Labeling, IML) Источник: Maspi S.r.l.

На схеме выше показана суть технологий IMD и IML:

1. Сначала на тонкопленочный пластик наносят нужный рисунок текст, декор или текстуру (например, лого фирмы-изготовителя или подписи для кнопок). Это делается за счет трафаретной или цифровой печати. Получается так называемая аппликация.

2. Аппликацию помещают в пресс-форму для литья.

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

4. Форма заполняется полимером, и печатная этикетка приклеивается к пластику.

5. На выходе при раскрытии формы мы получаем готовую деталь пластикового корпуса уже со встроенной графикой.

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

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

В чем разница между декорированием в форме (IMD) и маркировкой в форме (IML)?

Если графика или текстура внутри пресс-формы наносится не на всю поверхность изделия от края до края, а локально, на отдельный участок, то такой тип декорирования называется маркировка в пресс-форме или In-Mold Labeling (IML). С помощью этой технологии можно добавлять цвет, графические элементы и текстурированные области.

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

И вот теперь мы возвращаемся литью с электроникой (In-Mold Electronics), которая стала логическим продолжением предыдущих двух технологий. Похоже, что первое коммерческое внедрение IME было реализовано в инновационной подвесной консоли для автомобиля Ford в 2012 году. Сегодня же IME применяется в производстве бытовой техники, автомобильных панелей, медицинского оборудования, аэрокосмической и носимой электроники.

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

На схеме ниже показано, как это работает:

Источник изображения: Functional Ink Systems for In Mold Electronics by DuPont

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

2. Термоформование придает печатным носителям трехмерную форму, которая соответствует форме для литья под давлением.

3. Литье под давлением.

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

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

Пока эта технология еще воспринимается потребителями как новаторская, сами дорожки-проводники выглядят как элементы декора. :-) Со временем промдизайнеры и hardware-стартапы наверняка предложат свежие идеи по использованию возможностей такого литься.

Источник фото: аналитический отчет IDTechEx за 2020 год.

На фото выше серийные устройства и прототипы, созданные по технологии In-Mold Electronics.

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

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

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

Емкостное сенсорное управление и пользовательские интерфейсы

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

Вот, как американская химическая компания Dupont, один из мировых разработчиков токопроводящих чернил для IME, представляет в своей презентации интерфейсы для автомобилей настоящего и будущего:

Подводим итоги

Автопром это всего лишь одна из многих сфер применения IME, которые мы уже называли выше. Но давайте на ее примере рассмотрим реальный кейс. Возьмем потолочную консоль в автомобиле, которая была спроектирована с использованием печатной платы и классического пластикового корпуса, состоящего из десятков компонентов и сборных деталей, и сравним ее с консолью финской компании TactoTek, которая сейчас разрабатывает свою технологию in-mold structural electronics (IMSE):

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

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

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

Скептики как будто правы: этот no-code не заменяет код не реализует алгоритм, то есть, ветвления циклы и прочее, а только позволяет накидать на чистый лист квадратики, которые как-то там взаимодействуют друг с другом. Элементы платежных систем, фрагменты веб-документов, формы и чаты, таблицы с фильтрами. Всё это связывается в пёструю мешанину MVP и гордо именуется no-code решением.

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

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

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

Важная оговорка: рассмотренная здесь задача выбрана только для демонстрации примера расчетов no-code, а терминология может раздражать, например, специалиста 1С. Терминология и организация не важны, мы обсуждаем механизм расчетов без кода.

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

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

Проводка означает отражение сумм документов на сальдо договора и остатках на складах. В результате проводки мы снимем пометку Черновик с документа и изменим сальдо по договору на сумму движения. Если на эту дату записи Сальдо нет, то мы создадим её. Также мы пересчитаем остатки товаров на складе. Если записи по остаткам на этот день нет, то мы её создадим.

Данные, введенные в систему согласно этой структуре, выглядят примерно таким образом:

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

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

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

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

Вот так выглядит и работает конструктор запросов, в котором мы выбираем нужные нам данные:

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

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

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

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

В следующем случае запрос объединит таблицы шапки документа, справочника договоров, регистров сальдо с фильтром на дату документа:

Будь мы программистами SQL, мы бы написали операторы JOIN ON и WHERE, написав соответствующие условия на объединение таблиц и отбор только тех Сальдо, которые относятся к дате документа. Здесь же мы задали имя формулы в нашей колонке Движение, а затем использовали это имя в фильтре по дате, взяв в квадратные скобки. Конструктор сам извлёк и объединил нужные нам данные, мы только наложили дополнительное условие по дате сальдо.

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

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

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

Вычисленные значения можно присвоить вместо имеющихся в базе данных, записав их в поле SET Присвоить:

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

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

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

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

Получившийся запрос Сальдо вставим в выражение в поле SET, чтобы получить корректное значение сальдо, даже если записи о предыдущем сальдо нет:

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

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

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

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

• ROUND(x, 2) округление x до двух знаков после запятой (аналог в экселе ОКРУГЛ())

• IF(A, B, C) если условие A верно, то вернуть B, иначе C (аналог ЕСЛИ())

• x IS NULL Истина, если x пустое или неизвестно (аналог ЕПУСТО())

• SUM(x) просуммировать все x с группировкой по остальным полям (аналог СУММА())

• abn_ID возвращает внутренний ID объекта, нужна для однозначного его определения

Этот запрос делает всё то, что мы собирались сделать в начале этой заметки инвертирует пометку Черновик у документа, пересчитывает сальдо договора, остатки товаров на складе и их средневзвешенную себестоимость. То есть, он проводит документы, но также умеет откатить проводку и вернуть все остатки, себестоимости и сальдо, как было!

Он использует результаты трёх вложенных запросов собирает данные по остаткам, себестоимости и сальдо. Они просты и однотипны:

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

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

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

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

Применимость low-code: случаи, когда уникальная интеграция и визуализация занимают 90% усилий проекта и длятся, условно, 4 дня на проекте в 1 неделю. Часто базу данных и бэкенд можно накликать за 1 день, вместо 1-2 недель в традиционной разработке.

Пример, рассмотренный в статье, был сделан по ТЗ для простого приложения в 1С. В конструкторе с чистого листа были реализованы бизнес-сущности и формы ввода документов, которые уже есть в 1С. Для сравнения приведу некоторые факты (сравнение весьма субъективное, ибо 1С крут в своём сегменте, а тут нам нужно быстро собрать MVP):

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

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

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

Ещё, говоря о серьезном продукте, следует вспомнить про релизы, версионность, масштабируемость, авто-тесты, CI/CD и прочие сопутствующие вещи. Здесь всё достаточно просто конструктор, так же как и любая система, может быть покрыт стандартными процедурами. Можно выгрузить его состояние в гит, сравнить версии, оформить релиз и процедуру отката, но это тема отдельной статьи.

Это вторая часть из цикла статей про прототипирование IIoT-решения на Raspberry PI и Yandex IoT.

В первой части мы реализовали основные функции на Raspberry PI:

• сбор телеметрии с промышленных датчиков по протоколу Modbus;

• их передачу в облако;

• локальный мониторинг процесса в реальном времени.

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

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

Требуемый функционал

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

• принимать телеметрию устройства;

• накапливать телеметрию в хранилище;

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

Посмотрим, какие инструменты для решения этих задач есть в Яндекс Облаке.

Доступные инструменты

Сбор и обработка телеметрии

Yandex IoT Core

В первой части мы уже познакомились с Yandex IoT Core и достаточно подробно разобрали его функционал. Если кратко, это MQTT-брокер от Яндекса, с помощью которого осуществляется обмен сообщениями между реестрами и устройствами.

Его мы и используем, чтобы отправлять телеметрию устройства в облако (как именно? велком в первую часть)

Yandex Cloud Functions

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

Этот сервис позволяет разворачивать serverless-функции (на данный момент на Python, Node.js, Bash, Go и PHP), а также обладает механизмом триггеров - запуска развернутых функций по какому-либо условию (таймеру, событию).

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

Yandex Message Queue

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

Этот механизм будет полезен, если в качестве хранилища использовать ClickHouse или схожие аналитические колоночные СУБД, плохо переносящие единичные вставки - в очереди можно накопить пачку сообщений и отправить их на вставку одним большим пакетом.

Хранение телеметрии

Для хранения данных Яндекс Облако предоставляет большое количество Managed Services для разных СУБД.

Managed Service любой СУБД, позволяет быстро развернуть готовый к работе кластер с необходимым хранилищем. Также в рамках облака можно быстро масштабировать ресурсы кластера в случае увеличения нагрузки.

Доступные на текущий момент СУБД:

• PostgreSQL

• ClickHouse

• MongoDB

• MySQL

• Redis

• SQL Server

По умолчанию, доступ к кластеру возможен только сервисами, развернутыми в рамках той же облачной сети (Yandex Virtual Private Cloud). Но при создании кластера можно включить публичный доступ, и тогда ресурс будет доступен из любой точки интернета.

Использование накопленной телеметрии

Yandex DataLens

Это сервис визуализации данных и анализа данных. Позволяет достаточно быстро создавать дашборды на основе данных из разнообразных источников.

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

Yandex DataSphere

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

Работа ведется в ноутбуках JupyterLab, есть возможность выбора ресурсов, на которых будет выполняться каждая отдельная ячейка (количество ядер, GPU).

Дополнительные инструменты

Yandex Monitoring

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

Настройка сохранения телеметрии

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

Для этого нам нужно развернуть и настроить 4 элемента:

• IoT Core: создать реестр, устройство, наладить передачу сообщений по MQTT (сделано в первой части);

• Managed Service for PostgreSQL - развернуть кластер, создать таблицу для хранения телеметрии;

• Cloud Functions - написать функцию-обработчик сообщения с телеметрией: функция должна записывать payload сообщения в БД;

• Cloud Functions - настроить триггер IoT Core, который будет запускать функцию-обработчик при появлении нового сообщения в топике реестра.

Частично здесь мы будем опираться на пример подобного решения из документации Яндекс Облака.

Настройка PostgreSQL

Для начала подключаем и настраиваем кластер Postgres:

Нам подойдет самая минимальная конфигурация - b2.nano (если впоследствии проект перерастет во что-то большее, ее легко можно будет расширить):

Заводим пользователя и базу данных:

В разделе хосты нужно будет разрешить публичный доступ к ресурсу:

Это нужно для того, чтобы база была доступна для обращения из Cloud Functions.

Создадим кластер. Теперь придется подождать некоторое время пока кластер развернется и его статус поменяется с Creating на Alive.

После того, как кластер развернулся, заходим в него и создаем таблицу:

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

CREATE TABLE telemetry_hist( telemetry_timestamp timestamp,  device_nm varchar(200),  payload varchar(2000));

Такой подход удобен ещё и тем, что если в процессе доработки проекта поменяется структура payload-а, сохранение в БД не сломается и телеметрия не будет теряться.

Создание функции-обработчика

Функция будет получать сообщения из MQTT-брокера и записывать данные в таблицу, созданную ранее.

В каталоге в консоли выбираем Cloud Functions:

Создаем функцию с названием iot-core-handler и каким-нибудь говорящим описанием.

В открывшемся редакторе выбираем среду выполнения. Мы будем использовать Python 3.7 (preview).

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

Помимо редактора кода, можно разворачивать код из архивов в Object Storage или загруженных напрямую.

Мы будем использовать код, предоставленный в документации Яндекс Облака (гитхаб), немного поправив его под наши нужды.

Правки касаются формата таблицы и payload сообщений:

• Функция makeInsertStatement:

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

def makeInsertStatement(event_ts, payload_json, table_name):    msg = json.loads(payload_json)    msg_str = json.dumps(msg)    logger.info(msg_str)    insert=  f"""INSERT INTO {table_name} (telemetry_timestamp , device_nm , payload) VALUES ('{event_ts}','iot_test_device', '{msg_str}')"""    return insert

• Функция makeCreateTableStatement:

  Изменим выражение в соответсвтии с форматом таблицы.

def makeCreateTableStatement(table_name):    statement = f"""CREATE TABLE {table_name} (    ( telemetry_timestamp timestamp,      device_nm varchar(200),      payload varchar(2000)    );    """    return statement

• Функция msgHandler:

  • Изменим переменную event_id на event_ts (96 строка) и будем формировать ее следующим образом:

    event_ts = json_msg["event_metadata"]["created_at"]
    

  • Изменим значение переменной table_name на название нашей таблицы (98 строка):

    table_name = telemetry_hist
    

  • В функцию makeInsertStatement в качестве первого аргумента отправляем не event_id, а event_ts (99 строка):

    sql = makeInsertStatement(event_ts, event_payload, table_name)
    

Код с уже внесенными правками можно найти в этом гисте. Вставим его в файл index.py.

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

Теперь, перед созданием версии функции, в форме под редактором необходимо заполнить параметры развертывания:

• Точка входа: укажем index.msgHandler - это имя функции в файле index.py, которая будет вызываться в качестве обработчика. Указывается в формате <имя файла с функцией>.<имя обработчика>

• Таймаут, с: 10 секунд -максимальное время выполнения функции. Облачная функция может выполняться не более 10 минут.

• Память: 128 МБ - объем необходимой для функции памяти

• Сервисный аккаунт - укажем (или создадим, если его еще нет) сервисный аккаунт с ролями serverless.functions.invoker и editor

• Переменные окружения - обратите внимание, разработанная функция использует 6 переменных окружения, которые необходимо заполнить в соответствующих полях. Нужно указать следующее:

  • VERBOSE_LOG параметр, отвечающий за вывод подробной информации о выполнении функции. Введем значение True.

  • DB_HOSTNAME имя хоста БД PostgreSQL для подключения.

  • DB_PORT порт для подключения.

  • DB_NAME имя базы данных для подключения.

  • DB_USER имя пользователя для подключения.

  • DB_PASSWORD пароль, который был введен при создании кластера

Все данные для подключения (кроме пароля) можно найти в обзоре развернутого Managed Service for PostgreSQL.

В итоге мы получаем такое заполнение полей:

Создадим версию функции (кнопка Создать версию).

Настройка триггера IoT Core

Вернемся в раздел Cloud Functions и выберем подраздел Триггеры.

Создадим триггер (кнопка Создать триггер).

• В блоке Базовые параметры:

  • В поле Имя введем имя триггера.

  • В поле Тип выберем Yandex IoT Core. Так мы укажем сервису, что будем работать с обработкой событий IoT Core. Кроме этого источника, для решения других задач можно обрабатывать сообщения Message Queue, события Object Storage, Container Registry, логов Cloud Logs, а также запускать функцию по таймеру.

• В блоке Настройки сообщений Yandex IoT Core:

  • В поле Реестр введем iot_test-reg - реестр к которому привязано наше устройствою

  • В поле Устройство выберем Любое устройство (т.к. мы отправляем сообщения в топик реестра)

  • В поле Топик укажем топик, в который устройство отправляет данные:

    • $registries/<ID реестра>/events

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

• В блоке Настройки функции:

  • Выберем функцию для обработки данных, созданную ранее (iot-core-handler).

  • В поле Тег версии укажем $latest - тогда триггер будет запускать последнюю развернутую .

  • В поле Сервисный аккаунт укажем созданный ранее сервисный аккаунт.

  • Остальные поля оставим пустыми.

Создадим триггер с заданными настройками.

Проверка работоспособности

Всё готово!

Теперь (если всё сделано правильно) каждое сообщение, отправляемое устройством, будет через созданный триггер инициировать вызов функции. Которая, в свою очередь, положит отправленный payload в таблицу на Postgres.

Проверим логи выполнения функции (Cloud Functions -> Функции -> iot-core-handler -> Логи).

Здесь отображаются сообщения, выводимые функцией в процессе работы, в том числе, сообщения об ошибках. Если сообщений об ошибках нет (а есть информационные сообщения, начинающиеся с [INFO]) - функция работает корректно.

Посмотрим теперь заполнение таблицы telemetry_hist в нашей БД (Managed Services for PostgresSQL -> telemetry_store -> SQL). Вводим имя пользователя и пароль и попадаем в редактор SQL.

Вводим простой запрос для получения выгрузки из таблицы

SELECT * FROM telemetry_hist

И видим всю историю отправленных пэйлоадов:

То есть всё работает: теперь телеметрия попадает в облако, накапливается в развернутой БД и доступна для дальнейшего анализа в любое удобное время из любой точки планеты!

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

Отправило ли устройство хотя бы одно сообщение с момента деплоя функции и триггера?

• Если нет - просто ждем пока это произойдет)

• Если отправляло - смотрим логи выполнения функции.

  • Если логи пустые - стоит проверить триггер (в частности правильно ли указан топик и функция).

  • Если в логах ошибки - разбираемся с кодом.

  • Если функция отрабатывает и ошибок нет - проверяем настройки подключения к БД и имя таблицы.

Пришло время сказать правду, зачем я начал писать на Хабр. Хотя я занимаюсь mHealh, digital health и прототипированием софта всего 9 лет официально, цифровизация алгоритмов науки и информатизация практики меня интересуют более 20 лет. Недавно мои коллеги (или соавторы), которым я помогал в работе последние 4 года, в том числе и как сисадмин, попросили меня найти им программистов для улучшения evolutionary prototyping и допиливания мобильных приложений. На Хабре таких статей десятки вроде. Если вы считаете, что рыночно стоит доделать нижеперечисленные прототипы, то пишите, я им передам контакты и прибыль пополам (примерно) с ними. Сразу скажу, мне ничего от этого финансово не перепадёт, будет только удовлетворение, что две стороны нашли друг друга, как происходит в журнале Врач и ИТ, например))

Номер один. Персональная программа здорового образа жизни Баланс

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

2. Дифференциальная диагностика, терапия и профилактика головной боли

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

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

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

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

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

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

Подбирает алгоритм хирургического лечения пациентам с язвенными гастродуоденальными кровотечениями (ЯГДК), согласно последним национальным клиническим рекомендациям Российского общества хирургов и международным руководствам. Программа позволяет персонифицировано определять и проводить следующую тактику: ведение больных на догоспитальном этапе, оценку необходимости зондирования желудка, диагностическую и лечебную эндоскопию, ведение больных с массивной кровопотерей, медикаментозный гемостаз, прогнозирование рецидива ЯГДК, ведение больных при рецидиве кровотечения, ведение пациентов с кровотечениями, ассоциированными с приёмом нестероидных противовоспалительных препаратов. Программное обеспечение предназначено для работников здравоохранения профильных специальностей, ординаторов и студентов медицинских ВУЗов.

6. Мобильное приложение Лечение заболеваний желудка и двенадцатиперстной кишки

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

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

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

8. Программа для выполнения авторской методики внутрисуставных инъекций

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

9. САНАТА - метод аудиовизуальной психокоррекции

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

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

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

11. Шкала оценки уровня ригидности

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

12. Тест оценки уровня агрессивности

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

13. Тест оценки тревожности

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

14. Индивидуальный подбор растений для экологического и медицинского фитодизайна

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

15. Дифференцированный подбор рецепта медицинского и экологического фитодизайна

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

16. Учебное пособие для врачей Основы фитотерапии

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

17. Программа оптимизации и прогресса технологий инновационной продуктивности физических и юридических лиц

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

18. SmartMedFitoLabs BioSoftPatent

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

19. Feedback: diagnosis, rating, correction

Программа на базе ПрЭВМ 2017614931 помогает проводить через смартфон или планшет верифицированное (с видеофиксацией) голосование для подсчёта более объективного рейтинга и оценки специальных параметров наружной, печатной, телевизионной, радио-, интернет-рекламы, а также самих товаров и услуг для персонализации target group, lifetime value и покупок клиентов в кратко- и долгосрочном плане. Программа на 50 основных уровнях использует улучшенные (как ноухау) методы медицинской, социальной и медиапсихологии, психиатрии, психодиагностики, client-centered, cognitive therapy, аутотренинга, психогигиены, санологии, экологии человека, ТРИЗ, omni-channel brand health, customer experience marketing, cross-device service blueprint, brand lift, Яндекс.Взгляда, programmatic backstage adverts, addressable, connected и advanced television для индивидуализации продукции под боли и цели покупателей.

20. Подбор методов медицинской реабилитации психосоматических расстройств при постковидном синдроме

Данная программа является дополнением к программам для ЭВМ 2017614931 и 2019618242 и 2021612109, помогая, на основе актуальных научных и патентных открытых международных англоязычных источников информации проводить онлайн и офлайн персонифицированный подбор методов медицинской реабилитации психосоматических расстройств (депрессивных, тревожных, соматоформных) при постковидном синдроме (Post-COVID-19 syndrome, по МКБ-10 - U09.9), в частности: физиотерапии, психотерапии, лечебной физкультуры, Fitwel-техник, бальнеотерапии, курортологии, диетотерапии, фитотерапии, витаминотерапии, рефлексотерапии, медицинского фитодизайна, телемедицины, цифровых медицинских технологий, аппаратов и устройств для этого. Программа позволяет пациентам и специалистам в сфере здравоохранения подбирать подходящие под индивидуальные симптомы методики реабилитации.

21. Сервис Iotmedecohome для создания и оптимизации оздоровительных, зелёных и умных (IoT) загородных объектов недвижимости и экодевелопмента

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

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

Кстати, началось моё увлечение созданием ИТ-продуктов и кодингом в 2001-м году, когда я сам, вот этими самыми кривыми ручонками, скачал программу Adobe PageMaker, скомпилировал, сверстал, поправил в тексте ссылки на интернет, распечатал свою первую книгу (я не пиарюсь, честно, она давно везде есть и не приносит прибыли абсолютно, как и всё остальное, что публикую здесь) и потом её размножил, разброшировал и стал раздавать коллегам и пациентам для пропаганды святого оздоровления и всемогущего саморазвития. Потом я стал потихоньку делать всякие простые приложения, экзешники и сайты на JavaScript, а затем учить разработке софта студентов медицинских и психологических специальностей.

Ну а сейчас мы стартап Fitwel-технопарк #ВОИР, который подали в акселератор ВШЭ, МТС и 3 другие места для инвестиций и ТП). Это как бы минитехнопарк, экоковоркинг, мобильное приложение и онлайн-сервис для создания и техноброкерства программ, зарегистрированных патентов членов ВОИР и затем готовых продуктов в сфере Fitwel, в том числе новых IoT-устройств для здоровья, также и против COVID-19. Используются там три специализированные методики и программы для ЭВМ и Big Data с техниками ТРИЗ для обучения студентов, аспирантов, научных и педагогических сотрудников основам изобретательства, регистрации интеллектуальной собственности, а также их дальнейшей коммерциализации. Всё это только в сферах экологии, медицины, биологии, психологии, фитодизайна и т.п.

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

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

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

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

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

Архитектура системы определяет скорость ее развития. Красивая и правильная архитектура вдохновляет работать и помогает команде разработки.

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

Если система проста и удобна внутри, то она так же проста и удобна снаружи. У пользователей меньше проблем, а значит и у разработчиков тоже.

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

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

Модель

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

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

При реализации объектной модели клиентам рекомендуется ориентироваться на модель сервер-приложения.

Логика

Упрощайте алгоритмы. Делите сложные части на простые. Не переусердствуйте.

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

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

Алгоритм должен легко читаться: в тексте, в любой нотации моделирования, в коде.

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

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

Нейминг решает

Если назвать бокал стаканом, то назначение "пить" вроде бы не меняется, но что-то все-таки не то.

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

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

Имена объектов и методов в конечном счете становится языком команды разработки, заказчика ПО и даже пользователей.

MVP и прототипы

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

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

Рефакторинг

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

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

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

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

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

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

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

Выводы

Не усложнять.

Ничего не прятать.

Называть все своими именами.

Не стоять на месте.

Не поддаваться отчаянию, если не получилось.

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

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

Напомню, что в результате анализа мы пришли к следующей структуре объекта:

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

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

Какие есть варианты?

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

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

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

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

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

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

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

А что у нас?

Второй вариант - это использование специализированных документоориентированных (или документных, как больше нравится) баз данных, реализующих NoSQL-подход к хранению и обработкенеструктурированной или слабоструктурированной информации. Наиболее часто данные хранятся в виде JSON объектов, но с предоставлением производителями СУБД инструментария для доступа к данным внутри этих структур.

У такого подхода, применительно к проектируемой системе, можно выделить несколько плюсов:

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

• ограничиваем ситуации случайного воздействия на данные - модифицировать json объект гораздо сложнее, чем данные в колонке.

• проще описывать объекты в коде - иногда можно вообще не описывать структуру документа в коде, а работать прямо с полями в JSON.

Но есть и минусы:

• невозможно нативно реализовать проверки данных при размещении в хранилище.

• валидацию данных придется проводить в коде.

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

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

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

Делаем прототип

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

Создадим следующие таблицы:

Для описания объектов в табличном виде:

• r_objects, базовые данные по объектам: тип, дата создания и ссылка на хранилище атрибутов.

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

Для описания объектов в виде JSON:

• objects. Данные по объектам, где в поле data формата jsonb хранятся искомые атрибуты.

Остальные таблицы - это различные вспомогательные хранилища.

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

Методика тестирования

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

• добавление данных по объекту. Критерий успешности: объект с данными появился в хранилище, метод вернул в ответе его идентификатор.

• обновление данных по объекту. Критерий успешности: данные в хранилище были изменены, метод вернул отметку об успехе. Удаление данных в системе не предусматривается, поэтому удаление объекта является операцией, аналогичной обновлению.

• извлечение данных по объекту. Критерий успешности: объект с данными возвращен в ответе на запрос. Извлечение объекта происходит по конкретному идентификатору, по критериям поиска и постранично (пагинация).

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

Тестирование показало следующие результаты:

Первая (высокая) часть графика - это получение объектов по случайной странице - пагинация. Здесь в обоих случаях пришлось применить небольшой трюк - так как Postgres не агрегирует точное число строк в таблице, то узнать, сколько всего записей на объеме данных теста простым count - это долго, и для получения количества записей пришлось брать статистику данных по таблице. Также время получения данных на страницах свыше 10000-й неприлично велико, поэтому верхняя планка для получения случайного номера страницы была установлена в 10000. Учитывая специфику нашей системы, получение пагинированных данных не будет частой операцией, и поэтому такое извлечение данных применяется исключительно в целях тестирования.

Вторая (средняя) часть графика - вставка или обновление данных.

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

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

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

Результаты тестов на 40000 запросов приведу в виде таблицы:

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

Что получилось?

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

В современном мире всё большую популярность приобретает методика под названием customer development для тестирования идей и гипотез о будущем продукте. Методику придумал "крёстный отец Кремниевой долины" Стив Бланк.
Одним из числа сильных инструментов в "разработке клиентов" является интервью, когда вы можете побеседовать с респондентом. Однако им не всегда можно воспользоваться ввиду разных причин, которые условно можно свести к объёму бюджета и имеющемуся времени. Но во многих ситуациях можно воспользоваться опросом. Причём опросом, который можно автоматизировать за счёт применения чат-бота и нейронной сети для определения смысла слов, которые написал респондент в ответ на заданный вопрос.

В этой статье сконцентрируюсь на алгоритме работы чат-бот для проведения опроса. Как сделать чат-бота для VK писал в отдельной статье на Хабре. Использовал: Python, MySQL, API VK и готовую нейросеть от RusVectores.

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

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

• Нейросеть для понимания смысла текста, вводимого пользователем

• База данных для хранения вопросов интервью

• Описание алгоритма работы чат-бота

Нейросеть для понимания смысла текста, вводимого пользователем

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

В данном решении была использована готовая нейросеть от сервиса RusVectores, обученная на корпусе НКРЯ с использованием алгоритма word2vec CBOW с длиной вектора 300.

НКРЯ это совокупность русскоязычных текстов, Национальный Корпус Русского Языкав полном объёме. Содержит 270 миллионов слов, объём словаря 189 193 слова.

Word2vec CBOW алгоритм, благодаря которому слово на естественном языке представляется в виде числового вектора. Т.е. определяет координату слова в смысловом пространстве. CBOW это аббревиатура Continuous Bag of Words. Она обозначает алгоритм, который есть в word2vec. Данный алгоритм называют моделью мешка слов, он предсказывает слово по контексту. Ещё один алгоритм в word2vec - Skip-gram предсказывает контекст по слову.

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

Более подробно о word2vec можно почитать в статье "Немного про word2vec: полезная теория".

О векторном представлении слов (эмбеддинге) хорошо и с примерами описано в статье "Что такое эмбеддинги и как они помогают машинам понимать тексты".

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

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

База данных для хранения вопросов

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

В базе данных таблица с вопросами выглядит так (фрагмент):

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

Описание алгоритма работы чат-бота

Начало опроса

По договорённости с пользователем он заходит на страницу сообщества в ВК и инициирует диалог, нажав кнопку Сообщение.

Бот здоровается и спрашивает разрешения начать опрос. Текст приветствия задавал в разделе "Управление" "Сообщения" на странице сообщества в ВК.

Если пользователь ответил что-то близкое по смыслу со словом да, то бот начинает задавать вопросы. Как определить, что пользователь одобрил старт интервью? Для этого как раз нужна нейросеть, чтобы определить смысловую близость введённых пользователем слов к словам: да, можем, можно, начинай, ок. Для этого воспользуемся API сервиса RusVectores.

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

фрагменты кода из bot_methods.py
_{модуля, в котором реализованы все методы бота}

def _identify_phrase(user_id, user_message):    """    identify start question or greeting    return number of phrase in database    """    # identification variable, on start set "I don't know"    identi = 'I dont know'    # find in database current position in conversation between user and chatbot    identi = get_current_position_in_conversation(user_id)    if identi != 'err':        # if the conversation has just begun        if identi == '0':            # define greetings            similarity = _get_similarity(user_message, u'привет здравствуйте добрый')            if similarity > 0.5:                identi = "greetings"            else:                # define start interview or not                identi = _start_or_not(user_message)        # if the conversation continues        elif identi == '1':            # define start interview or not            identi = _start_or_not(user_message)        else:            pass                return identi

Вначале определим возможность начать опрос исходя из ответа пользователя с помощью метода _start_or_not():

def _start_or_not(user_message):    """    define <identi>: start or don't start interview    """    if user_message != 'старт' or user_message != 'Старт':        _identi = 'I dont know'        # define if user agree to start interview        start = _get_similarity(user_message, u'да можем можно начинай ок')        # define if user don't agree to start interview        later = _get_similarity(user_message, u'нет позже потом завтра')        if start > later and start > 0.15:            _identi = 'start'        elif later > start and later > 0.15:            _identi = 'later'    else:        _identi = "start"    return _identi

Если пользователь решил сначала поприветствовать бота, то нужно понять это и поприветствовать в ответ. Для этого проверим на смысловую близость сообщения от пользователя со словами приветствия с помощью метода _get_similarity(). Данный метод будет использоваться и далее для определения смысловой близости сообщений пользователя.

def _get_similarity(text1, text2):    """    Function return similarity between text1 and text2    text1 - user message    text2 - key words    """    text1.strip()  # delete empty space on start and end of string    text2.strip()    text1_words = text1.split(' ')    text2_words = text2.split(' ')    similarity = 0.0 # init variable    try:        for word1 in text1_words:            if word1 != '':                for word2 in text2_words:                    if word2 != '':                        # prepare url for request to API rusvectores.org                        # url example https://rusvectores.org/ruscorpora_upos_cbow_300_20_2019/дело__папка/api/similarity/                        url = '/'.join(['https://rusvectores.org/ruscorpora_upos_cbow_300_20_2019',                                         word1 + '__' + word2, 'api', 'similarity/'])                        # GET request to API rusvectores.org                        r = requests.get(url, stream=True)                        # sum similarity of couple of words                        similarity = similarity + float(r.text.split('\t')[0])    except Exception as e:        log_exception = str(e)    # average similarity    similarity = similarity/len(text2_words)    # return similarity between text1 and text2    return similarity

Переменная similarity содержит числовое обозначение смысловой близость фраз text1 и text2. Чем ближе similarity к 1, тем ближе фразы по смыслу.

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

фрагмент кода из mysqldb_methods.py
_{модуля, в котором реализованы все методы для работы с MySQL базой данных}

def get_current_position_in_conversation(user_id):    """    find in database current position in conversation between user and chatbot    using in bot_methods.py    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        query = "SELECT `question_num` FROM `conversations` WHERE `user_id`=%(user_id)s LIMIT 1"        cursor.execute(query, {'user_id': user_id})        result = cursor.fetchone()        if result is None:            identi = '0'        else:            identi = result[0]        conn.close()    except Exception as e:        identi = 'err'        return identi

Таким образом мы обрабатываем три сценария взаимодействия с чат-ботом:
- старт опроса (понимаем согласен пользователь начать опрос или нет с помощью функции _start_or_not()),
- обмен приветствиями, если пользователь поздоровался (понимаем по смысловой близости к словам приветствия с помощью функции _get_similarity());
- движение по структуре вопросов с помощью функции get_current_position_in_conversation() для определения текущего положения в структуре вопросов.

Давайте рассмотрим движение по структуре вопросов более подробно.

Стоп-слова

Одним из важных моментов является удаление "стоп-слов", т.е. слов, которые можно с лёгкостью удалить из предложения и при этом его смысл не потеряется. Вот набор стоп-слов, которые я использовал в данном проекте:

stop_words = [u'а',u'большой',u'бы',u'быть',u'в',u'весь',u'вот',u'всей',u'вы',u'говорить',u'год',u'для',u'до',u'еще',u'если',u'же',u'знать',u'и',u'из',u'или',u'к',u'как',u'который',u'мочь',u'мы',u'мне',u'на',u'наш',u'него',u'нее',u'них',u'но',u'о',u'один',u'она',u'они',u'оно',u'оный',u'от',u'ото',u'по',u'с',u'свой',u'себя',u'сказать',u'та',u'такой',u'такое',u'только',u'тот',u'ты',u'то',u'у',u'что',u'это',u'этот',u'я']stop_characters = [u'.',u',',u' - ',u'- ',u' -',u':',u';',u'?',u'',u'!',u'_',u'(',u')',u'=',u'+',u"#",u'$',u'@',u'%',u'*',u'   ',u'<',u'>','1','2','3','4','5','6','7','8','9','0']

С помощью метода _clear_text() очищаю предложение от стоп-слов:

Движение по структуре вопросов

Для определения в каком направлении опроса двигаться исходя из ответов респондента воспользуемся функцией _define_conversation_way():

def _define_conversation_way(user_message, identi):    """    define in which way we are goin to?    """    # all questions, unless  3 has two ways: 'yes' (positive) or 'no' (negative)    if identi != '3' and identi != '6':        yes = _get_similarity(user_message, u'да заказывал просить')        no = _get_similarity(user_message, u'нет никогда')    elif identi == '6':        # the question number 6 has different ways: 'delivery' or 'self-delivery'        yes = _get_similarity(user_message, u'заказываю доставку')        no = _get_similarity(user_message, u'еду сам ищу аналог')    elif identi == '3':        # the question number 3 has different ways: 'from store' or 'delivery'        yes = _get_similarity(user_message, u'магазин сам')        no = _get_similarity(user_message, u'доставка почта все перечисленное курьер дом')    if yes > no and yes > 0.15:        _way = 'yes'    elif no > yes and no > 0.15:        _way = 'no'    else:        _way = 'I dont know'    return _way

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

bot_methods.py
_{полный код модуля, в котором реализованы все методы бота}

# -*- coding: utf-8 -*-"""Bot methods.Realizes all what bot can do."3. Использование API сервиса RusVectores"https://github.com/akutuzov/webvectors/blob/master/preprocessing/rusvectores_tutorial.ipynb"""import re  # for work with regular expressionsimport requests  # for using HTTP requestsfrom bot_config import stop_wordsfrom bot_config import stop_charactersfrom mysqldb_methods import get_current_position_in_conversationfrom mysqldb_methods import get_question_from_DBfrom mysqldb_methods import write_current_question_number_for_userdef get_bot_answer(user_id, user_message):    """    using in views.py    make answer to user    """    answer = ''    # delete stop-words and punctuation characters in sentence    user_message = _clear_text(user_message)    # identify what to do: start or continue conversation    identi = _identify_phrase(user_id, user_message)    if identi == 'greetings':        answer = get_question_from_DB('1')        write_current_question_number_for_user(user_id, '1')    elif identi == 'start':        answer = get_question_from_DB('2')        write_current_question_number_for_user(user_id, '2')    elif identi == 'later':        answer = "Когда у вас будет возможность пройти интервью напишите мне 'старт'."    elif identi == 'I dont know':        answer = "Я не совсем вас понимаю...\nУточните, пожалуйста."    elif identi == 'end':        answer = "Спасибо за ваше участие в интервью!"    else:        # if top-level question: 1, 2 or 3 etc.        if len(identi) == 1:            # define in which way we are goin to?            way = _define_conversation_way(user_message, identi)            if way == 'yes' or way == 'no':                if way == 'yes':                    # going to positive way                    question_num = '.'.join([identi,'1','1'])                if way == 'no':                    # going to negative way                    question_num = '.'.join([identi,'2','1'])                answer = get_question_from_DB(question_num)                if answer != 'None':                    write_current_question_number_for_user(user_id, question_num)                else:                    question_num = str(int(identi) + 1)                    answer = get_question_from_DB(question_num)                    write_current_question_number_for_user(user_id, question_num)            else:                # if way='I dont know'                answer = "Я не совсем вас понимаю...\nУточните, пожалуйста."        else:            # if subquestion: e.g. identi=2.1.1 or 3.2.2 etc.            identi_numbers = identi.split('.')            next_num = str(int(identi_numbers[2]) + 1)            question_num = '.'.join([identi_numbers[0],identi_numbers[1],next_num])            answer = get_question_from_DB(question_num)            # if we get end of subquestions in this top-level-question            if answer == 'None':                # going to the next top-level question                question_num = str(int(identi_numbers[0]) + 1)                # checking that the question is the last                if _is_the_last_question(question_num):                    answer = get_question_from_DB(question_num)                    question_num = 'end'                else:                    # is not the last question                    answer = get_question_from_DB(question_num)                        write_current_question_number_for_user(user_id, question_num)            return answerdef _is_the_last_question(question_num):    """    define is the last question?    by the condition (len(identi) == 1) of the function "get_bot_answer"    question_num has lenght 1    """    is_the_last = True    question_num = str(int(question_num) + 1)    question = get_question_from_DB(question_num)    if question != 'None':        is_the_last = False    return is_the_lastdef _define_conversation_way(user_message, identi):    """    define in which way we are goin to?    """    # all questions, unless  3 has two ways: 'yes' (positive) or 'no' (negative)    if identi != '3' and identi != '6':        yes = _get_similarity(user_message, u'да заказывал просить')        no = _get_similarity(user_message, u'нет никогда')    elif identi == '6':        # the question number 6 has different ways: 'delivery' or 'self-delivery'        yes = _get_similarity(user_message, u'заказываю доставку')        no = _get_similarity(user_message, u'еду сам ищу аналог')    elif identi == '3':        # the question number 3 has different ways: 'from store' or 'delivery'        yes = _get_similarity(user_message, u'магазин сам')        no = _get_similarity(user_message, u'доставка почта все перечисленное курьер дом')    if yes > no and yes > 0.15:        _way = 'yes'    elif no > yes and no > 0.15:        _way = 'no'    else:        _way = 'I dont know'    return _waydef _identify_phrase(user_id, user_message):    """    identify start question or greeting    return number of phrase in database    """    # identification variable, on start set "I don't know"    identi = 'I dont know'    # find in database current position in conversation between user and chatbot    identi = get_current_position_in_conversation(user_id)    if identi != 'err':        # if the conversation has just begun        if identi == '0':            # define greetings            similarity = _get_similarity(user_message, u'привет здравствуйте добрый')            if similarity > 0.5:                identi = "greetings"            else:                # define start interview or not                identi = _start_or_not(user_message)        # if the conversation continues        elif identi == '1':            # define start interview or not            identi = _start_or_not(user_message)        else:            pass                return identidef _start_or_not(user_message):    """    define <identi>: start or don't start interview    """    if user_message != 'старт' or user_message != 'Старт':        _identi = 'I dont know'        # define if user agree to start interview        start = _get_similarity(user_message, u'да можем можно начинай ок')        # define if user don't agree to start interview        later = _get_similarity(user_message, u'нет позже потом завтра')        if start > later and start > 0.15:            _identi = 'start'        elif later > start and later > 0.15:            _identi = 'later'    else:        _identi = "start"    return _identidef _clear_text(sentence):    """    delete stop-words and punctuation characters in sentence    """    try:        # sentence to low-case        sentence = sentence.lower()        # delete stop-characters        for char in stop_characters:            sentence = sentence.replace(char, '')        # delete stop-words        words_of_sentence = sentence.split(' ')        result = ''        for word in words_of_sentence:            if word not in stop_words:                result = result + ' ' + word    except Exception as e:        result = str(e)    return resultdef _get_similarity(text1, text2):    """    Function return similarity between text1 and text2    :param text1: user message    :param text2: key words    """    text1.strip()  # delete empty space on start and end of string    text2.strip()    text1_words = text1.split(' ')    text2_words = text2.split(' ')    similarity = 0.0 # init variable    try:        for word1 in text1_words:            if word1 != '':                for word2 in text2_words:                    if word2 != '':                        # prepare url for request to API rusvectores.org                        # url example http://rusvectores.org/araneum_none_fasttextcbow_300_5_2018/дело__папка/api/similarity/                        url = '/'.join(['http://rusvectores.org/araneum_none_fasttextcbow_300_5_2018',                                         word1 + '__' + word2, 'api', 'similarity/'])                        # GET request to API rusvectores.org                        r = requests.get(url, stream=True)                        # sum similarity of couple of words                        similarity = similarity + float(r.text.split('\t')[0])    except Exception as e:        log_exception = str(e)    # average similarity    similarity = similarity/len(text2_words)    # return similarity between text1 and text2    return similarity

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

Для удобства приведу полный код модуля с методами для работы с базой данных:

mysqldb_methods.py
_{полный код модуля, в котором реализованы все методы для работы с MySQL базой данных}

# -*- coding: utf-8 -*-"""Methods for work with MySQL database."""import MySQLdb  # before using it do in ssh: pip install mysqlclient""" import configuration variables for connect to MySQL database:"""from mysqldb_config import HOSTfrom mysqldb_config import USERfrom mysqldb_config import PASSWORDfrom mysqldb_config import DATABASEdef write_current_question_number_for_user(user_id, question_num):    """    write question number to database for this user    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        if question_num == '2':            query = (                "INSERT INTO `conversations`(`user_id`, `question_num`) "                "VALUES (%s, %s)"            )            data = (user_id, question_num)        else:            query = (                "UPDATE `conversations` "                "SET `question_num`=%s "                "WHERE `user_id`=%s "            )            data = (question_num, user_id)        cursor.execute(query,data)        conn.commit()  # commit transaction        conn.close()    except Exception as e:        exception = str(e)def get_current_position_in_conversation(user_id):    """    find in database current position in conversation between user and chatbot    using in bot_methods.py    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        query = "SELECT `question_num` FROM `conversations` WHERE `user_id`=%(user_id)s LIMIT 1"        cursor.execute(query, {'user_id': user_id})        result = cursor.fetchone()        if result is None:            identi = '0'        else:            identi = result[0]        conn.close()    except Exception as e:        identi = 'err'        return identidef get_question_from_DB(question_num):    """    return question text from database    """    try:        conn = MySQLdb.connect(host=HOST, user=USER, passwd=PASSWORD,                                db=DATABASE, charset='utf8', init_command='SET NAMES UTF8')        cursor = conn.cursor()        query = "SELECT `question_text` FROM `questions` WHERE `question_num`=%(num)s LIMIT 1"        cursor.execute(query, {'num': question_num})        result = cursor.fetchone()        if result is not None:            question_text = result[0]        else:            question_text = "None"        conn.close()    except Exception as e:        question_text = str(e)        return question_text

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

скрипт views.py
_{"точка входа" для приёма сообщений пользователя и отправки ответов бота в чат}

# -*- coding: utf-8 -*-from __future__ import unicode_literalsimport jsonimport threading  # for async executing tasks with VK APIimport vk  # vk is library from VKfrom django.views.decorators.csrf import csrf_exemptfrom django.shortcuts import renderfrom django.http import HttpResponsefrom bot_config import *  # import token, confirmation_token and over constants from bot_config.pyfrom bot_methods import get_bot_answer@csrf_exempt  # exempt index() function from built-in Django protectiondef index(request):  # requested url    if (request.method == "POST"):        data = json.loads(request.body)  # take POST request from auto-generated variable <request.body> in json format        if (data['secret'] == secret_key):  # if json request contain secret key and it's equal my secret key            if (data['type'] == 'confirmation'):  # if VK server request confirmation                """                For confirmation my server (webhook) it must return                confirmation token, which issuing in administration web-panel                your public group in vk.com.                Using <content_type="text/plain"> in HttpResponse function allows you                response only plain text, without any format symbols.                Parameter <status=200> response to VK server as VK want.                """                # confirmation_token from bot_config.py                return HttpResponse(confirmation_token,                                     content_type="text/plain",                                     status=200)            if (data['type'] == 'message_new'):  # if VK server send a message                # t - is new thread to async execute answer_to_message()                t = threading.Thread(target=_answer_to_message, args=(data,))                t.start()                return HttpResponse('ok', content_type="text/plain", status=200)    else:        return HttpResponse('see you :)')# send anser to user messagedef _answer_to_message(data):    session = vk.Session()    api = vk.API(session, v=5.5)    user_id = data['object']['user_id']    user_message = data['object']['body']    # get bot answer    answer = get_bot_answer(user_id, user_message)    # token from bot_config.py    api.messages.send(access_token = token, user_id = str(user_id), message = answer)

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

Успехов!

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

От кого и для кого

Доброго времени суток! Меня зовут Николай, и я хочу рассказать свою историю и поделиться своим небольшим опытом в разработке своей первой игры. С чего начинал и какие трудности пришлось преодолеть на пути разработки. Статья ориентирована на тех, кто начинает, думает начать или уже разрабатывает свою первую игру. Зачем? Потому что на стадии разработки своей первой игры, сам не однократно читал статьи о подобном опыте, после прочтения которых "наматывал сопли на кулак" и продолжал разработку дальше. От идеи до выпуска в магазин.

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

С чего все начиналось

Шел третий курс универа

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

Выбор направления

Появилась острая необходимость найти "дело", которое будет приносить удовольствие, не придется отрываться от современного мира на длительный срок и иметь финансовый достаток в перспективе сравнимый с моей по образованию профессией. Конец 4 курса универа и мой выбор пал на IT индустрию, а именно на python разработчика. Уделив 2 недели теории, в частности технической документации языка, я начал развивать логику и выполняя задачки каждый день на протяжении полугода, пока в конце декабря 2018 года не обнаружил геймдев.

А вот и Unity!

Выглядит комично или даже банально, но я повелся на клик-бэйт видео с подобным названием "Как сделать свою первую игру за 15 минут" или "Делаю крутую игру за 5 минут без регистрации и смс". Посмотрев данные материалы, в голове появилась мысль, выделить себе пару дней в своем графике, и утолить свое любопытство, установив данную среду разработки на свой компьютер. Потыкав разные кнопочки, и написав код методом "copy-paste", я пришел в неописуемый восторг! Моя творческая натура внутри меня ликовала. Ведь это было так приятно наблюдать за тем, что ты "сам" написал пару минут назад, сейчас заставляет кубик крутиться, перемещаться или менять цвет. Так уж вышло, что средой разработки установленной на мой компьютер оказалась Unity.

Почему Unity?

Он бесплатный, не такой сложный в освоении, большое сообщество и тонны ресурсов для самообучения, поэтому отлично подходит для начинающих разработчиков. Мобильный рынок заполнен проектами созданные на Unity. Даже такие крупные компании как Blizzard, Riot Games, CD Project RED выпустили всеми известные хиты как Hearthstone, Wild Rift и Gwent, используя эту платформу. Приняв волевое решение, я решил уйти в геймдев на пару с Unity.

Подготовка к разработке

Формирование идеи

Определившись с выбором рабочей платформы для разработки игры, я отправился читать статьи людей, у которых имелся уже хоть какой то опыт в данной сфере, чтобы выбрать нужное мне направление. ПК или смартфоны? 2Д или 3Д? Сингл или мультиплеер?
Прочитав большое количество статей и проанализировав их, все советы сходились к тому, чтобы:

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

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

Мой выбор

2Д мобильная аркада с сетевым режимом до 6 человек , рейтинговой системой и вознаграждением. Разработка, которой заняла отнюдь не 2 , а все "12 месяцев".

Аргументы "за":

• Мне показалось заставлять двигаться 2Д объекты будет проще, чем те же 3Д;

• Мобильный рынок огромен и его доля более половины всей игровой индустрии;

• Писать сюжеты для игр я не умею, да и опыта в этом нет никакого, поэтому я решил сделать упор на веселье. А играть всегда веселее вместе! Поэтому сетевая;

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

Аргументы "против":

• Игра уже становилась не так уж проста, как советовали более опытные коллеги;

• Сложность и продолжительность разработки для не опытного "птенца" увеличивалась многократно.

Аргументы "за" были очень привлекательны и я решил рискнуть. Как говорится - "Чем чёрт не шутит" и "Была не была"!

Знакомство с Unity и его изучение

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

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

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

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

Как только я накидал определенный план действий и уже собирался начать делать свой первый будущей "шедевр", встал серьезный вопрос

Где я возьму картинки, музыку и остальные элементы для своей будущей игры? Ведь я совершенно не умею сам это создавать

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

А ты сам все это нарисовал? А музыку ты писал тоже сам?

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

Совет: Не чурайтесь использовать чужие наработки или шаблоны, которые продают или прибегать к работе фрилансеров! Это взаимосвязанная выгода! Конечному пользователю все равно, сами вы рисовали самолетик несколько часов или потратили 10$ на его покупку в магазине, ведь главное результат!

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

Совет: Отслеживайте скидки на продаваемые ассеты в различным магазинах, особенно под новый год! Можно приобрести кучу ассетов по выгодной цене со скидкой до 90% в такое время.

Непосредственная разработка

Первые шаги

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

На этом этапе моя игра имела следующий вид:

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

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

От простого к сложному

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

Интерфес и меню

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

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

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

• усталость

• потеря интереса

• неувереность в своих силах

• все кажется адом и этому нет конца и края

Совет: Скажу то, что я прочитал когда сам проходил этот этап. НЕ СДАВАЙСЯ! Как бы не было сложно, ни в кое случае НЕ СДАВАЙСЯ и НИ ШАГУ НАЗАД! Дойдя до самого конца ты познаешь лавину экстаза и самоудовлетворения от того, что ты не бросил все! И разумеется бесценный опыт!!!

Однопользовательский режим

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

Оптимизация

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

Я начал оптимизировать свой проект, только спустя 8 месяцев разработки. Из-за чего оптимизировать надо было много и долго:

• картинки

• материалы

• звук

• шейдеры

• настройки камеры, рендеринга

• интерфейс

• скрипты

Это заняло у меня еще не меньше двух недель.

Совет: Не затягивайте с оптимизацией! Изучите сразу вопрос, как стоит правильно использовать определенные настройки в работе с теми или иными ресурсами в вашем проекте, чтобы добиться наилучшей производительности.

Одна голова хорошо, а несколько лучше

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

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

Реклама и внутриигровые покупки

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

Софта для рекламных интеграций имеется множетство, в том числе и от самой Unity, так называемая Unity Ads. Однако, мой выбор пал на Google AdMob. Почему не Unity Ads? Почитав обзоры, я узнал, что контент рекламы содержит казино, рулетки и ставки. Тут уже на вкус и цвет, как говорится, но я не хочу чтобы реклама была связана с подобного рода сервисами. Я использовал межстраничную и рекламу с вознаграждением.

Совет: Реклама с вознаграждением, намного лучше, ведь игрок сам нажимает на просмотр рекламы, чтобы получить какие-либо "плюшки" в игре. Разработчик и пользователь в плюсе!

Покупки в игре, я реализовал подобным образом:

Финальная версия игры

"12 месяцев" кропотливой работы , и финальная версия выглядит примерно так:

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

Совет: Тут необходимо открыть еще одно "второе" дыхание , к ранее уже открытым +100500

Публикация игры

Большим плюсом выбора Unity - кроссплатформенность, что позволяет один проект выпустить на всех желаемых платформах (Android, iOS,PC,WebGl и др). К моменту написания статьи игра была опубликована только для Android в Google Play Market, но не за горами ios в Apple Store.

Какие "подводные камни" имеются?

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

Так в чем же проблема и где те самые "подводные камни"?

Политика конфиденциальности

Для публикации она не является необходимым элементом, однако, если в вашем приложении имеется реклама или внутриигровые покупки, то в кратчайшие сроки стоит обзавестись данной "бумажкой" и указать сссылку на неё в Google Play Console. К счастью, есть моножество ресурсов, которые генерирует данный документ за считанные секунды и сразу предлагают разместить на их сайте, удовлетворяя запросам гугла.
Если проигнорировать предупреждения от гугл, что у вас отсутствует политика конфидециальности, то приложение могут легко снять с публикации.

Совет: Не откладывайте на потом этот пункт, делайте его паралельно с публикацией!

Идентификатор клиента OAuth

Если у вас в игре имеется система достижений, рейтинга от гугл или вы хотя бы сохраняете данные игры в облаке от гугл, то необходимо, чтобы пользователь проходил процесс авторизации используя гугл аккаунт, а значит предоставлял некоторые разрешения на управления его данными. Теперь по порядку. При настройке игровых сервисов в Google Play Console, необходимо создать приложение для авторизации пользователя в Google Cloud Platforms, настроить учетные данные для идентификатора клиента OAuth, и Окно запроса доступа OAuth. Пожалуй это главный "подводный камень".
Сложность состоит не в его первоначальной настройке, чтобы сервисы исправно работали, а в том что приложение было опубликовано и не имело ограничений по количеству пользователей. Если вы намерены создавать крупнобюджетный проект, которые будет привлекать тысячи игроков, то вам придется обязательно пройти этот этап.

Сайт игры

Это не является обязательным пунктом, но лучше сделать сайт, где будут размещены новости вашего проекта, а так же политика конфиденциальности и прочие материалы для ознакомления. Оказывается в 2021 году сделать легкий и простой сайт достаточно просто. С шаблонами для разработки сайтов в Word Press, не долго думая, я останавливаюсь на нем. Для сайта необходим хостинг и собственный домен. Взвесив все "за" и "против", решил потратить пару тысяч рублей на его аренду, сроком на 48 месяцев и не "париться". В сети огромное количество предложений, так что проблем с этим тоже не было. Пару часов уходит на его настройку, и еще пару часов на наполнение его контентом. И вот уже есть свой собственный сайт для игры!

Совет: Чтобы получить заветную галочку во вкладке Окно запроса доступа OAuth в Google Cloud Platforms, иметь сайт игры и свой домен , где так же будет размещена политика конфиденциальности - является обязательным пунктом!

Совет: Так же, если используете рекламу от Google Admob, то сайт тоже необходим. В корневую папку вашего сайта добавляется файл app-ads.txt. Это позволяет рекламодателям понять, какие источники объявлений имеют право продавать рекламный инвентарь. Если не пройти авторизацию, то доход с рекламы будет сильно снижен!

GDPR

Еще одно бюрократическое препятствие осталось, на пути для публикации. Если ваше приложение имеет рекламу, то она может быть персонализированной, а значит ваше приложение собирает данные пользователей, чтобы успешно показывать рекламу. GDPR- (General Data Protection Regulation) -этозакон, принятый Европейским Парламентом, который описывает правила защиты данных для граждан ЕС. Это значит,чтобы показывать персональну рекламу, необходимо перед первым запуском вашей игры, пользователь должен принять соглашение, что ознакомлен с политикой конфиденциальности вашего приложения, а так же прочитать в каких целях будет использоваться его персональные данные и дать согласие/отказаться на их обработку. Разумееется это распространяется на резидентов из стран ЕС.

После выполнения всех выше изложенных пунктов, мое приложение успешно опубликовано в Google Play Market и не знает никаких проблем.

Краткая выжимка советов

• Изучите рынок, и определитесь с направлением и жанром игры. Главное не стройте в начале "наполеоновские"планы, которые могут и не реализоваться!

• Распишите план действий и пытайтесь четко следовать ему, попутно внося небольшие правки. Старайтесь укладываться в установленные планом сроки.

• Обязательно спрашивайте мнение ваших близких и друзей о вашей игре на протяжении всей разработки.

• Не стесняйтесь приобретать ресурсы для ускорения разработки и повышения качества своего проекта.

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

• Изучите базовые навыки работы с редактированием изображений и звуков.

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

• Научитесь использовать на базовом уровне Git. Незаменимый помощник при разработке игры, чтобы контролировать внесенные изменения.

• Последнее и наверно самое важное. Никогда не сдавайтесь , верьте в себя, упорно трудитесь и рано или поздно, но у вас все обязательно получится! Если получилось у меня и миллионов других начинающих разработчиков данного ремесла, то почему не должно получится и у вас!?

Заключение

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

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

Если я где-то ошибся и был не прав - буду рад правкам и пожеланиям в комментариях. Готов ответить на любые вопросы по данной теме.

Чтобы не было недопониманий на счет даты релиза.

Впервые игра была опубликована 2 декабря 2019 года, и это было 10 месяцев разработки. После я был вынужден отдать долг своей родине. Срочную службу в армии я нес до 2 декабря 2020. После демобилизации, я сразу продолжил разработку. И 4 февраля 2021, после "12 месяцев" разработки, я выпустил проект.

Если Вам интересно посмотреть на результат моей работы, то вы можете найти в Google Play Market.

Название игры - Starlake

Arduino + max30102 + ЦОС = SpO2

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

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

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

- мозги для управления выше указанным, модуль на stm32f103.

- и то куда все это выводить led дисплей на i2c.

Ну и конечно нашелся готовый проект какого то китайца: https://github.com/Jasoji/stm32-max30102со своими ошибками и проблемами, но об этом всем дальше.

Исходник моего проекта сделанного в Eclipse: https://Tranider@bitbucket.org/Tranider/stm32_oxymeter

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

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

Исследование кода показало почему были такие рваные и не стабильные показания. В файле max30102.cв функции max30102_cal, есть такие строчки:

if (R >= 0.36 && R < 0.66)

spo2 = (uint8_t)(107 - 20 * R);

else if (R >= 0.66 && R < 1)

spo2 = (uint8_t)(129.64 - 54 * R);

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

Самое печальное, что эти коэффициенты, находятся в лабораторных условиях для конкретных сборок (имеется ввиду max30102 и им подобные). Короче их лучше не трогать и эти коэффициенты описаны в документации на эту микруху, а еще там описана методика и принцип измерения.

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

Вторая проблема это перепутанные местами значения красного и инфракрасного.

Поэтому приступим к изменениям:

- изменение красного и инфракрасного.

- увеличение настроек АЦП (хочется видеть сердцебиение и не синус).

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

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

if(s.red> s.iRed) {// Уровеньс икдиодавышечемс красного<o:p>

sampleBuff[0].red= s.iRed;

sampleBuff[0].iRed= s.red;

} else{

sampleBuff[0].red= s.red;

sampleBuff[0].iRed= s.iRed;

}

В общем этот код выставляет красный и инфракрасный правильным образом.

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

Это то что я увидел когда вытащил показания АЦП наружу. Внутри-процессорная отладка наше все).

Если значения ИК будут в раёне 108к, то значение красного в раёне 101к. И это среднее значение еще и плавает в пределах пары своих амплитуд. И это при том что мне казалось что в этот момент я замер дабы не шевелить пальцем. Печально конечно что халявы не вышло и придется городить ЦОС. И это только первая проблема, вторая проблема ниже:

Видите эта подставка с проседанием по амплитуде, это так работает сердце и из за этого не так просто найти экстремум.

А теперь приступим к решению проблем.

Начнем с формулы.

SpO2 = aR²+bR+c

Где

R = (ACred/DCred) / (ACired/DCired)

a,b,c - калибровочные коэффициенты (именно они находятся в лабораторных условиях, для конкретной измерительной схемы). Для max30102значения можно найти в документации на эту микруху.

ACred - размах одного периода от максимума до минимума в относительных единицах.

DCred -постоянная составляющая сигнала. Я брал среднеквадратичное значение АЦП за последние несколько секунд.

т.е. выходит что сатурация измеряется по одному сердцебиению.

Далее необходимо найти экстремумы.

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

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

Поэтому для измерения уровня оксигинации есть два подхода:

1.Выставить минимальное разрешение АЦП, что автоматически отфильтрует эту просадку. Но тут при выводе рисунка колебания, сердцебиение будет больше похоже на синус.

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

Нас интересует второй подход. Оригинальный сигнал с АЦП выкидываем сразу на дисплей (там сердцебиение в своем оригинале).

• Дальше сигнал пропускам через фильтр и получаем почти синус.

• Ищем местоположение экстремума на синусе.

• В том же месте где был найден экстремум в синусе, ищем тот же экстремум но в оригинальном сигнале.

• Найденные значения в формулу расчета.

Вот собственно и все... дальше остается подставить в формулу и вывести график на экран.

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

Всем привет! Меня зовут АлександрБобко, я работаю менеджером проектов в инновационной лаборатории EPAM MadeRealLab. Это подразделение, которое занимается созданием быстрых прототипов иконцептовдля клиентов компании из самых разных отраслей. А еще команды лаборатории часто работают над разными социальными инициативами и проектами.

В своем первом посте наHabrя решил рассказать, как мы с коллегами приняли участие ввиртуальном хакатоне "Hack for Pink"и поделиться решением, за которое взялиГран-при. Речь о зеркале-домашнем помощнике при диагностикерака груди.

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

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

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

Команда

Основу составили ребята изPhysicalTechnology практики, которая занимается разработкой физических продуктов и устройств. Нетипичная для IT-компании гибридная командав Минскепоявилась около полутора лет назад и объединила инженеров и консультантов в областях электроники, медицинских, космических и других технологийиз6стран. А еще к нам присоединились коллеги из подразделенияInnovationconsulting,

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

Творческий процесс

ХакатонEsteeLauderдлился 2 недели, над решением мы работали в свободное время.Как все проходило:сперва собрали командуэнтузиастов,дальше я организовал совместный воркшоп,чтобы подумать о существующих проблемах,побрейшнтормитьи прийти к нескольким звонким идеям на стыке инженерии и креатива. Обмен творческими флюидами проходил онлайн.Кто-то из участников не знал друг друга, таким составом мы раньше не креативили, анужно было найти общий язык, настроиться на одну волну и обдуматьважные моменты. В общем,челленджнепростой, но мы справились в течение нескольких часов.Такие сжатые сроки намне в новинку:частонасхожиепервичныесессиис клиентом у тебябывает меньше60 минут.

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

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

C-Truemirror

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

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

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

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

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

• LIDAR, которыйактивно используется в геодезии и картографии для съемки объектов в высоком качестве исупердетализации. Такой модульможно также встретитьхоть вновомiPad, хотьв роботах-пылесосах. В нашемконцептетехнология поможет определить поверхностные изменения в текстуре кожи (например, появление углублений и припухлостей) и проанализировать их форму.

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

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

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

ВперспективеC-TrueMirrorмог бы распознаватькаждого члена семьи (по аналогии стехнологией распознавания лиц в смартфонах) и запоминать данные по отдельности.Да и при помощи такого зеркала можно было бы проводить онлайн-тренировки или использовать для телемедицины.

В результате всенашипредположения подтвердились и получилихороший отклик от фокус-групп.

Воплощение идеи и презентация

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

Поэтому мы с уверенностью сосредоточилисьна демонстрации жизнеспособности идеи ивзаимодействияпользователяс C-TrueMirrorв реальности. За 1,5 дня нашли нужные детали,камеру,датчики,обрезали зеркало и собрали прототип. Потом сняли видеоролик, в которомвоссоздали интерфейс устройстваи показали его использование. Элементы дополненной реальности и часть задуманного функционала рисовали фломастерами, проекцию на зеркало делали прямо с манекена.

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

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

Перспективы и новые направления развития

Важно отметить, чтоC-TrueMirrorзадумывался какумный домашний помощник,а не инструмент для полноценной медицинской диагностики.Послехакатонамы много общались с онкологами и собирали от них обратную связь. Врачи подтвердили, что наше решение будет действительно полезным для пользователей в качестве инструмента популяризации регулярной самодиагностики. Да и компьютер может быстрее обратить внимание пользователя на неочевидные внешние изменения. А дальше уже идет территория медиков, потому что онкологию в принципе сложно диагностировать (тем более в домашних условиях): нужно проводить спектральный анализ, УЗИ, обследования, измерять температуру на глубине 3-4 сантиметров, использовать специальную технику и руками доктора делать пальпации.

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

Мы планируем, что в будущем C-TrueMirrorможно будет использовать не только для диагностики груди, но и лица, определять проблемы и заболевания кожи, в том числе и онкологические.

БлагодарюколлегМихаилаИргера, Марину Дайнеко, РоманаАлиевича,АрамаМанукяна, Яна Федорова, Максима Цвика, Ольгу Полещук и Артема Панасенко заидеи, классную работу и вклад в создание этого проекта!

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

- Ооо, ты инженер конструктор?

- Да!

- Скажи что-нибудь как инженер конструктор!

-Крыльчатка насоса.

- Бог с ним, отправляй, по замечаниям исправим...

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

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

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

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

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

• Создание проекта с подробным описанием задачи

Итак,подстава 1

Все зависит от полноты и качества информации на начальной стадии ТЗ. Во избежание переделок старайся навязать заказчику начало сроков проектирования только после утверждения эскизной проработки всех узлов устройства. Если заказчик даже немного адекватен, то идет навстречу, потому что тоже не хочет, чтобы вертикальный виброконтейнер с эксцентриковым электрическим приводом оказался с гидравлическим или вообще без привода=)) Так что на 1-м этапе чаще всего идет подбор вариантов компоновки и подбора комплектующих. И тут, как правило, становится ясно, что же хочет заказчик проекта. Ведь он "всегда прав". Главного конструктора, который должен постоянно держать руку на пульсе проекта и сам увязывать все дополнительные пожелания у тебя нет, поэтому требуй качественное ТЗ.

• Несерьезность, студенчество, подработка;

Подстава 2

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

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

• Наличие привлекательного портфолио с результатами сложных расчётов, проектирования, фото.

Подстава 3

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

• Оплата больничных;

Подстава 4

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

• Когда заказчик - начальник, а ты хотел от этого уйти;

Подстава 5

Тут лучше выбрать позицию сотрудничества на равных условиях, и начать следует с головы. Дай себе установку, что ты и заказчик работаете на равных условиях, не идете на компромиссы, не наступаете себе на тапки, а сотрудничаете. Ты же помнишь, что эффективность применения станков с ЧПУ ВОЗРАСТАЕТ при повышении точности, наличии сложных условий обработки, при необходимости перемещения детали и инструмента в пяти-шести координатах и т.д.? Вот и старайся не отходить от четких переговоров по делу с заказчиком и не бойся задавать много сложных вопросов, чтобы видеть проект со всех сторон! Вы коллеги, и никаких пирамид. Поверь, от этого будет комфортно вам обоим.

• Нет постоянной загруженности и стабильных денег;

Подстава 6

Быстрее, выше, сильнее. В империю нарциссизма надо до смерти хотеть все успеть, охватить, стать лучшей версией себя, выйти из зоны комфорта (хотя это термин был придуман для бизнеса изначально). Тут может получиться, что пропадет мотивация, если ты заметишь себя за 8-м часом черчения проекта стоимостью 700 рублей, например. Выдохни! Этот заказ может быть таким, но это вовсе не значит, что все заказы одинаковые. И с этой прекрасной мыслью повысь износостойкость своей нервной системы - забей на все, выпей чаю, дочерти, и верь в следующий заказ. Желательно верить сильно, а то захочется вернуться на работу, позабыв, как все начиналось.

• Общение с коллегами;

Подстава 7

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

• Придётся постоянно развиваться в направлениях, о которых ты возможно раньше и не задумывался (либо не хотел задумываться): продажи, маркетинг, бухгалтерия, стратегия и тактика ведения переговоров, сильное имя и многое другое.

Подстава 8

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

• Инженерный фриланс в СНГ развит очень слабо, поскольку инженерная деятельность, как правило, очень сильно привязана к конкретному производству.

Подстава 9

Есть такое, но это не проблема века. Все в твоих руках. В помощь Peopleperhour, Профессионалы ru, weblancer net, Linkedin, Яндекс Услуги , а также твои знакомства. Вспомни метод неполной взаимозаменяемости, где требуемая точность замыкающего звена размерной цепи достигается некоторым заранее установленным риском путем включения в нее составляющих звеньев без выбора, подбора или изменения их значений. Размещай резюме везде ыыыы!! Где-то точно выстрелит.

• В регионах нужно ИМЯ

Подстава 10 или опытные дядьки

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

• Тайм менеджмент

А это вот не подстава, акрутая тема.

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

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

No-code сейчас в тренде. Статей на эту тему пока не много, хотя они появляются достаточно регулярно. На Хабре по тегу no-code и его вариантам я нашел всего около 15 статей и первая из них появилась только в июне 2020 меньше года назад! Во время чтения одной из статей у меня возникла идея собрать разные варианты no-code сценариев и снабдить некоторых из них, наиболее востребованных, инструкциями по реализации. Мне кажется, это будет интересно многим. Внизу после туториала, вы найдете пока небольшой, но пополняемый список сценариев и опрос, а пока давайте посмотрим как реализовать один простой сценарий.

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

Описание задачи

Предположим, вам нужен временный адрес, который не жалко засветить при регистрации на малоизвестном сайте или сайте с репутацией, вызывающей вопросы. После регистрации или когда надобность в адресе отпадет, можем удалить или оставить, но временно заблокировать его (см. об этом шаг 10c ниже) вдруг нужно будет позже восстановить пароль. Идея простая и очевидная и такие сервисы наверняка есть, хотя я сам ими не пользовался. Говорят, что существует такой сервис у Apple, когда при регистрации с помощью Apple Id, он предлагает подменить основной почтовый адрес временным. Хорошая идея, но в данном случае она доступна только владельцам яблочных гаджетов, более того, сайт на котором нужна регистрация, должен принимать Apple Id. Также я сам видел бота, который предлагал временный адрес почты. Это был простейший бот, но он почему-то не работал.

Получаются два стартовых условия: 1) делаем свой, кастомный и настраиваемый сценарий; подробнее об этом см. варианты развития сценария шаг 11 почти в самом конце; 2) обходимся без единой строчки кода.

Конечно, сценарий будет зависеть от сторонних сервисов и их поставщиков, а также будет, скорее всего, платным. Но есть и хорошие новости, он может быть создан на коленке за считанные минуты. В самом худшем случае, если вы делаете это первый раз или если вдруг что-то пойдет не так, за 1-2 часа максимум. В последние несколько лет количество новых no-code сервисов растет как на дрожжах, так что сценарий может быть реализован разными способами и мы можем выбирать наиболее удобный вариант и таким образом снизить зависимость от провайдеров no-code. Поэтому добавляем еще условие: 3) задействованные сервисы должны быть легко заменяемыми и настраиваемыми. В одной статье не получится полностью описать, как реализовать все 3 условия, но будем считать это заделом на будущее развитие сценария (шаг 11). Кроме того, сейчас не будем подробно сравнивать разные альтернативы и объяснять, почему именно эти варианты выбраны. Об этом есть множество других публикаций (примеры есть по ссылкам в следующем абзаце) и, конечно же, можете написать обо всех альтернативах в комментариях.

Альтернативы no-code

Если вы в первый раз слышите о no-code, возможно вам будет интересно почитать вводные обзоры и статьи для знакомства с отдельными сервисами. Для старта подойдет небольшой обзор No-code как отличная альтернатива для быстрого решения бизнес-задач. Взвешиваем pro et contra Движение No-code конец программистов? Разбираем плюсы и минусы. Введение в один из инструментов на Хабре n8n. Автоматизация ИБ со вкусом смузи.

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

Техническое задание

Нужно получить временный адрес и указать его при регистрации на каком-то левом сайте/сервисе сомнительного качества или с репутацией, вызывающей вопросы. И далее мы должны будем получить письмо или как-то прочитать его. Нас интересует только ссылка или код регистрации в теле письма, поэтому достаточно его извлечь и переслать дальше. Вот только куда? На основной адрес? Но зачем нам это письмо на почте, может лучше в виде короткого сообщения в чате или даже СМС-ки. Можно подключить WhatsApp, Slack или другой мессенджер. Но удобнее всего, конечно, Телеграм, для него и сделаем сценарий.

Проблемы, которые должен решать сценарий: 1) в общем случае текст письма может быть длинным, в то время как текст сообщения ТМ ограничен до 4096 символов, нужно обрезать длинные письма или разбивать их на части, 2) нам нужно также извлечь из письма ссылку или код для регистрации, т.е. нужно уметь обработать не только plain-text, но и HTML.

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

Шаг 1. Регистрируемся в Zapier

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

Шаг 2. Создайте новый Zap

Нажимаем [MAKE A ZAP] см. скриншот

Шаг 3: Укажите название запа и выберите триггер

Нужно как-то назвать Зап/сценарий и настроить триггер, который его запускает.

a) Жмем на Name your zap и вводим название запа. Вы можете выбрать любое. Я назвал его TMP Email Zap.
b) Далее в строке поиска вводим: email, Zapier покажет доступные почтовые сервисы.
c) В качестве триггера доступны различные приложения, но они потребуют дополнительных действий и регистрации новых сервисов, скорее всего. Нам не нужны такие трудности, выбираем простейший и первый в списке вариант Email by Zapier. См. скриншот выше.

Шаг 4: Выберите событие триггера

a) В разделе Trigger event нажмите на Choose an event
b) Тут вариантов не много: выбираем New inbound Email. См. скриншот выше.
c) Нажмите дальше [Continue]

Шаг 5: Выберите адрес email

Укажите адрес почты:

a) Появится поле для ввода email-адреса. Можете добавить любое слово. Но важно использовать ТОЛЬКО буквы в нижнем регистре или цифры, иначе вы не сможете пройти дальше.
b) Сохраните полученный адрес (кнопка [Copy]), вы будете использовать его для регистрации на левом сайте.
c) Нажмите дальше [Continue]. См. скриншот выше.

ВНИМАНИЕ!!!

Не показывайте никому этот адрес. Иначе вы рискуете попасть на спам. После чего, в лучшем случае, вы превысите бесплатные лимиты и сценарий перестанет работать, а в худшем случае придётся заплатить рублем, причём не деревянным, а зелёным по текущему курсу ЦБ. Хотя Zapier не очень дорогой, но платить только за спам совсем не хочется.

Шаг 6: Протестируйте email адрес

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

a) Попробуйте отправить письмо на адрес, который вы получили на шаге 5b.
b) После отправки письма нажмите кнопку [Test Trigger]
c) Если ничего не происходит или Zapier пишет что-то вроде Request no found, подождите несколько секунд и еще раз нажмите кнопку письму нужно время, чтобы дойти до сервера Zapierа
d) Если письмо все еще не пришло, проверьте, правильно ли вы скопировали адрес
e) После того как Zapier получит тестовое письмо, он покажет содержание письмо и все доступные поля (sender, subject и пр. их довольно много).
f) После тестирования, нажмите кнопку [Continue]

Шаг 7: Настройте бота, получателя сообщения

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

a) Откройте Telegram и бота по этой ссылке @co_notbot. Если у вас еще нет Телеграма, его нужно установить.
b) При входе нажмите кнопку [Start] или введите команду /start. Ждите некоторое время пока бот отработает команду. Появится сообщение с Главным меню бота и две кнопки внизу.
c) Нажмите на кнопку [Подключить]. См. скриншот выше.
d) Откроется следующее окно, в котором появится больше вариантов и кнопок. Нас интересует кнопка [Webhook]. Нажмите на нее и подождите до 1-3 секунд. См. скриншот ниже:

e) В следующем сообщении от бота вы получите вебхук, который нужно будет скопировать и затем добавить в наш Zap на шаге 9a.

ВНИМАНИЕ!!!

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

Шаг 8: Выбираем Action

a) Вернитесь в Zapier и нажмите кнопку [Action].
b) В строке поиска наберите web
c) Из списка выберите Webhook by Zapier. См. скриншот выше

a) далее выберите Action event, нажмите на [Choose an Event]
b) из списка выберите вариант [POST]. См. на скриншоте выше.
c) Нажмите дальше [Continue]

Шаг 9: Добавьте вебхук и параметры

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

a) в поле [URL] введите адрес вебхука, который вы получили на шаге 7e. На скриншоте приведен пример. У вас должна быть точная копия с токеном и адресом.
b) в поле [Payload Type] оставьте вариант [Form]
c) в следующем разделе [Data] нужно будет добавить/задать передаваемые параметры вебхука. Нам нужно будет задать одно поле text и его значение, в котором будет передаваться сообщение.
d) в поле text можно сначала добавить значение [Subject], [Sender], [Body Plain] или [Stripped Text] из письма
e) если тестирование (шаг 10) пройдет успешно, можно попробовать обрабатывать и передавать значения из html (об этом см. шаг 11c). Можно пробовать разные варианты и смотреть, что получится в результате. Если после выполнения Zapier будет выдавать сообщения об ошибках, попробуйте задать статическую строку, например, Hello world! и посмотрите, что получится.
f) остальные поля, ниже раздела [Data], заполнять и изменять не нужно

Шаг 10: Тестирование отправки письма и всего сценария

a) после того как все поля будут заполнены вы можете снова протестировать отправку письма и весь сценарий. Отправьте новое тестовое письмо и нажмите кнопку [Test & Review]
b) если тест пройдет успешно, то вы получите ответ в зеленой зоне и сообщение вроде Test was successful включите Zap/сценарий, нажмите на переключатель [off] [on];
c) обратным действием можно выключить (или на время заблокировать) этот сценарий позже

Шаг 11: Развитие сценария: извлекаем ссылки, добавляем фильтр, укорачиваем текст

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

a) проверка длины текста и самостоятельно решаем обрезать текст или делить его на куски < 4096 символов, чтобы не превысить лимиты Телеграма; можно реализовать по-разному, модулем Formatter by Zapier, например;
b) можно пересылать не каждое сообщение, а пропускать все сообщения через фильтр, который оставит только нужное и уберет спам, например. См. Filter by Zapier;
c) можно сделать более сложную обработку входящих писем и извлекать ссылки и/или картинки из HTML кода письма (Formatter by Zapier). Как вариант, после этого картинки можно пропустить через один из сервисов распознавания изображений для извлечения чисел/текста/номеров/лиц и пр.
d) можно самостоятельно зарегистрировать бота Телеграм и подключить один из бот-конструкторов; и тогда сможем реализовать бота по-своему и не будем зависеть от работоспособности стороннего бота. Правда попадем в новую зависимость от сервиса-конструктора;
e) можно сделать новый чат, куда с помощью аналогичного вебхука вместо письма настроить получение RSS, уведомлений или любого другого потока сообщений;
f) и наконец, можно сделать отдельные шаги взаимозаменяемыми, чтобы не зависеть от отдельного провайдера сервиса no-code. Например, вместо Zapierа можно использовать n8n или Integromat.

Как я обещал, кратко перечислю более-менее простые сценарии no-code. Выберите наиболее интересные на ваш взгляд.

• Кастомный фильтр спама на базе AI/ML

• Временная почта для регистраций (см. пример этого выше)

• Агрегатор и фильтр вакансий/новостей/объявлений/rss

• Сканирование и учет чеков и финансовых операций

• Кастомный uptime-мониторинг для сайтов, серверов

• Уведомления и команды Умного дома

• No-code решения для скилов Алексы или навыков Алисы

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

Привет!

Я часто видел заголовки подобные "Apache Kafka vs RabbitMQ vs NATS", но что делать если что-то не устраивает в готовых решениях? Можно подстроиться, а можно изобрести что-то своё. Я пошел вторым путём. В этой статье я хотел бы рассказать про свою реализацию брокера сообщений. Если стало интересно, добро пожаловать под кат.

1.1 Сохранение заказов

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

Уточнение 1: обрабатывая заказ нужно однозначно избежать ситуации когда один заказ обрабатывается дважды.

Уточнение 2: было несколько ДЦ и допускалось, что они могут иногда не иметь между собой связь, а еще внутри ДЦ может рушиться сеть.

Уточнение 3: разумеется отправлять на сборку нужно сразу (считаем каждый склад расположенным на своих независимых нескольких ДЦ).

Постановка задачи в таком виде увы не имеет явного решения :( Однако при наличии определённых допущений всё же реализуема.

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

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

1.2 Портативный анализатор

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

У меня всплыла в голове идея мутанта, и окончательно сформировалась.

2. Цель

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

Основная цель - иметь брокер сообщений.

Требование 0: брокер должен хранить сообщения и предоставлять доступ к ним в течении какого-то времени (Блокирующее).

Требование 1: очередь должна работать на слабом железе (Блокирующее). Интересно что это требование было и в "крупном интернет магазине" ибо выделение железа было затруднительным, а выделяемые ресурсы не всегда были стабильными.

Требование 2: если узел брокера умеет принимать сообщение, то нужно иметь возможность послать туда сообщение, даже если у него нет связи с другими узлами (Блокирующее).

Требование 3: если сообщение было послано в один узел за сообщения определённого типа, то оно в конечном счёте должно появиться во всех узлах отвечающих за сообщение этого типа доступным для получения (Желательное).

Требование 4: если одинаковое сообщение было послано в два узла брокера, отвечающего за сообщения одного типа, то сообщения не должны задублироваться в конечном счёте (Желательное).

*`В конечном счёте` - по прошествии времени. Если были разрывы соединений, то после их восстановления.

Начиная подбирать готовые решения мы начали упираться в их ограничения.

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

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

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

Других готовых решений я не рассматривал.

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

3. Реализация (краткое описание)

3.1 Общие понятия

Cluster - сервис в котором хранятся очереди, обработчики и ссылки на другие кластера.

Queue - очередь. Очередь хранится в кластере. Очередь принимает сообщения, сохраняет их в хранилище и выдаёт по требованию. Что бы получить сообщение нужно передать ID последнего прочитанного сообщения.

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

ExternalCluster - ссылки на другие кластера. Можно например положить сообщения из своего кластера в другой. Или наоборот забрать из другого кластера сообщения и положить в очереди этого кластера.

3.2 Очередь изнутри

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

Предполагается 4 вида сохранения:

• сохранить сразу после добавления сообщения

• ничего не делать после добавления сообщения

• помечать очередь, что она изменилась после добавления сообщения

• дождаться, что сообщение сохранится после добавления сообщения, сохранение происходит периодически

Очереди поддерживают подписку. Однако подписка реализована так, что одна подписка - один читатель и подписки работают независимо.

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

3.3 Хранение данных

Для хранения данных сообщения было решено выделить хранение в отдельный слой. То есть хранилище может быть как диком (уже реализовано) так и неким облачным хранилищем (s3) и даже БД (предстоит реализовать).

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

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

Обработчики могут не только перемещать блоки. На данный момент реализованы следующие обработчики:

• Выгрузка блоков из памяти

• Перемещение блоков между местами хранения

• Удаление старых блоков

• Копирование сообщений между очередями

Копирование сообщений между очередями

Для копирования используется механизм вставки "уникального сообщения". Уникальность определяется по уникальности пары "источник + внешний ID". Благодаря такому подходу можно настроить копирования очереди в двунаправленном режиме. Особенности реализации таковы, что наибольшая производительность достигается если копирование идёт с нарастающим внешним ID и при этом этого сообщения ещё нет в очереди. То есть в однонаправленном копировании. Так же рекомендуется ограничить количество источников разумным количеством (например 1000) в рамках одной очереди.

FIFO

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

3.4 Примеры сценариев работы

Сохранение события для сервисов в дата центрах (например сохранение заказа)

Подготовка кластеров:

• Разворачивается N кластеров Capella Queue

• В каждом кластере создаётся очередь для приёма события

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

• Для каждой очереди определяется обработчик копирования сообщений в другие очереди (в каждую или по кругу или по любой другой схеме)

Реализация сохранения:

Для сервиса который сохраняет событие определяется К кластеров Capella Queue из подготовленных и определяется надёжность M (M < K)

Далее при необходимости сохранения события Сервис:

• Определяет для сообщения глобально уникальную связку источник+внешний ID. Так же рекомендуется указать сегмент

• Сохраняет сообщение в M Кластеров

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

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

Сохранение события для удалённых устройств (например для анализатора)

Подготовка кластеров:

• Разворачивается кластер на устройстве

• Разворачиваются кластеры в датацентрах, куда хочется выгружать данные

• В каждом кластере создаётся очередь для приёма события

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

• Настраиваются обработчики для копирования сообщений (настраиваться может как на устройстве так и в ДЦ)

Реализация сохранения:

События сохраняются в очередь на локальном кластере. Нужно определить для сообщения глобально уникальную связку источник+внешний ID. Благодаря обработчикам копирования сообщения будут доступны как на устройстве так и в ДЦ

4. Ближайшие планы

1. Сделать туториал, с описанием основных кейсов.

2. Прикрутить безопасность.

3. Прикрутить использование сервисом SSL сертификатов.

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

5. Обновление параметров очередей, кластеров и обработчиков.

6. Функционал для контроля того, что сообщение отреплицировалось в другие кластера.

7. Метрики.

Код

На github