Русский
Русский
English
Статистика
Реклама

Dash

Перевод Разработка dApps на блокчейне Dash (интервью с разработчиком)

12.01.2021 20:07:52 | Автор: admin
image
Формально, Dash Platform это технологическая среда для создания децентрализованных приложений (Dapps) на базе блокчейна и сети Dash облака, которое разработчики могут интегрировать со своими приложениями.
Недавно опубликована серия видео, объясняющих 4 ключевых составляющих Dash Platform: хранилище Dash Drive, децентрализованный API (DAPI), Имена пользователей на Dash Platform Name Service (DPNS) и Dash Platform Protocol (DPP). Отмечается, что DAPI Dash Platform будет первым в мире децентрализованным HTTP API.
Промо-тексты :) оригинального интервью я опустил, и по существу получилось:


В 2020 Dash Platform находилась на стадии тестирования в Evonet, где разработчики из сообщества исследуют, создают и тестируют сеть, чтобы понять, на что она способна.

Чтобы узнать об этом больше, мы попросили об эксклюзивном интервью активного разработчика из сообщества Dash, который работает под псевдонимом 'readme', чтобы получить инсайдерскую информацию об интригующем релизе под названием Dash Platform.

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


Я сильно увлечён Web3, Интернетом вещей, большими данными и вопросами монетизации всего этого. Преимущество Dash Platform в том, что разработчики могут тут же начать писать код на Javascript и использовать блокчейн с его децентрализованным API (DAPI) для аутентификации, взаимодействия с аккаунтами, хранения мета-данных и аналитики. А ещё есть имена пользователей, которые обеспечивают удобство использования как пользователям, так и разработчикам.

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

Над какими проектами вы работаете прямо сейчас?


Я потратил довольно много времени на изучение возможностей, которые даёт новый основанный на данных подход, прежде чем выбрать тему, которую все знают невзаимозаменяемые токены и совместить её с игрой, которую все любят Minecraft. То есть я работаю над невзаимозаменяемыми токенами, которые хранят структуры зданий в Minecraft их ещё называют чертежами. Я назвал этот проект Dashcraft. Там есть своего рода структуры, которые можно создавать, используя различные строительные блоки внутри игры для этого есть режим игры исключительно для конструирования, называется творческий. То есть это как Лего, можно построить что угодно. Лично мне нравится пиксель-арт и абстрактные структуры. В отличие от анонсированной интеграции Enjin-Minecraft, где они будут хранить типовые игровые предметы и ассеты на блокчейне (например, оружие и доспехи), строительные структуры, хранящиеся в Dashcraft, относятся скорее к искусству и персонализации, которые может создавать кто угодно. Единственное ограничение, которое я задал на Minecraft NFT каждая структура должна быть уникальной, поэтому вы не сможете загрузить на блокчейн точную копию уже существующего. Проект состоит из трёх частей:
  • Minecraft Server Plugin, благодаря которому пользователь сможет входить в игру Minecraft со своим именем пользователя Dash, выбрать своё здание / пиксель-арт / абстрактную структуру с помощью внутриигровых инструментов, создать из этого NFT и отправить это в блокчейн в NFT контракт данных. (http://personeltest.ru/aways/github.com/readme55/Dashcraft)
  • Minecraft Creative Server с обычными плагинами для Строительства и установленным Dashcraft плагином
  • Minecraft NFT Explorer, чтобы просматривать в веб-браузере структуры, дату создания и связанное с ними имя пользователя Dash на блокчейне. (http://personeltest.ru/away/readme.dashdevs.org/minecraft-explorer/)

Аутентификация и загрузка данных сделаны с помощью простого браузерного кошелька, над которым я тоже работаю. Для связи между Minecraft Game и Browser Wallet там есть вариация сервиса Push Notification, который реализован на Dash Platform. Проект Dashcraft недавно был завершён, и вскоре будет его релиз в тестовой сети.

Как вы думаете, будут ли другие игровые приложения интегрировать функционал Dash Platform?


Да, возможность легко работать с платёжными аккаунтами по децентрализованным API, имена пользователей и низкие комиссии за транзакции делают Dash платформу отличной базой для разработки внутриигровых покупок, вознаграждений и ставок. Существует растущий тренд для хранения внутриигровых предметов на блокчейне, и теперь, когда есть контракты данных, всё прекрасно подходит для разработчиков игр, которые хотят интегрировать себе функционал блокчейна. Чтобы использовать учётные данные для входа, разработчики могут применить Dash Блокчейн-ID c именами пользователей, которые могут хранить и профили пользователей, и балансы, и списки контактов, и т. д. Кроме того, мгновенное подтверждение транзакций Dash и возможность сразу же тратить только что полученные средства решает главную проблему разработчиков игр.

Разрабатываете ли вы на Dash Platform что-то ещё?


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

Чем отличается разработка приложений на Dash Platform по сравнению с разработкой на Ethereum?


Ethereum часто называют всемирным компьютером из-за того, что вычисления происходят полностью на стороне нод сети. В этом и есть ключевое различие между Dash Platform и Ethereum, по крайней мере в текущей начальной версии. Активное вычисление децентрализованным приложением на Dash Platform происходит на стороне клиента, или на стороне центрального сервера. Dash Platform нацелена на предоставление разработчикам фреймворка для Web3 Dapps и платежей через DAPI (децентрализованный API), чтобы было просто создавать аккаунты и управлять ими. Это достигается за счёт введения имён пользователей для входа в систему и для работы с данными. Кроме того, Dash Platform предоставляет функционал контрактов данных, которые выполняют функцию децентрализованных баз данных. Главное преимущество разработки на Dash Platform заключается в том, что единое имя пользователя работает как децентрализованный логин, открывающий доступ к неограниченному числу приложений, и в то же время обеспечивающий полный контроль над вашими (криптографически верифицируемыми) личными данными.

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


В недавнем видео, которые выпустили разработчики из сообщества Dash Platform, были продемонстрированы четыре различных Dapps: базовый кошелёк с именами пользователей под названием EvoWallet, альтернатива Твиттеру под названием Jembe, коммерческое PoS-приложение Checkout и бэкенд система для мерчантов InStore. Эти Dapps уже готовы и доступны для тестирования в Evonet, которая является тестовой сетью для разработчиков Dash Platform. Они демонстрируют потенциал интегрированной экосистемы Dapp, который стал возможным благодаря единому децентрализованному логину.

Также идёт работа над интеграцией с Ethereum для задач хранения данных и изучение различных решений на Oracle для взаимодействия между двумя блокчейнами. Есть также команда, работающая над библиотекой для приватного мессенджера на основе популярного протокола Signal, которая хранит свои (обфусцированные) данные на Dash Platform. Кроме того, один из наших разработчиков работает над библиотекой JavaScript атомарных свопов, а на фоне этого всегда проводятся активные исследования на различные темы, например: проверяемые вычисления, управление и приватность.

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


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

Ресурсы для разработчиков:


Developer Discord https://chat.dashdevs.org/
Dash Platform Dev Documentation https://dashplatform.readme.io/
Dash Core Developer Guide https://dashcore.readme.io/docs/core-guide-introduction
Dash Core Github https://github.com/dashpay
Dash Platform Github https://github.com/dashevo

Я бы рекомендовал всем разработчикам присоединиться к нашему активному сообществу. Вы можете получить вознаграждения за различные баунти-программы по разработке Dapp на Dash Platform на https://dashincubator.app/. Узнать больше о проекте можно на https://www.dash.org/ru/developers/.

Вы действительно видите растущий интерес среди блокчейн-разработчиков, изучающих Dash Platform?


Наше сообщество разработчиков растёт еженедельно, а некоторые другие криптопроекты об этом только мечтают. Dash Platform на самом деле открывает новый взгляд на блокчейн-программирование. Требуется некоторое время, чтобы его понять, но у него огромный потенциал. Без широкой огласки уже происходят некоторые невероятные вещи, и всё это на основе обычных контрактов данных и простых кошельков на javascript. Когда Dash Core Group начнёт добавлять дополнительные функции Платформы для разработчиков Dapp может начаться настоящее безумие!

Лучшее из двух миров?


Два ведущих блокчейн-проекта, Биткоин и Ethereum, предлагают миру весьма различные варианты использования. В то время как Биткоин стали использовать как цифровое золото, Ethereum это платформа, где разработчики могут создавать основанные на блокчейне Dapps, работающие в его сети. Однако, у Биткоина и Ethereum всё-таки есть нечто общее: обе эти сети характеризуются высокими комиссиями за транзакции и перегруженностью сети. Именно в этом Dash их превосходит, и это должно привлечь внимание разработчиков из обоих лагерей, потому что децентрализованная сеть Dash это оптимизированное масштабируемое решение, состоящее из мощных, экономически заинтересованных распределённых нод-серверов, которые и обеспечивают Dash его продвинутый функционал. Двухуровневая инфраструктура сети мастернод Dash, состоящая из серверов с высокой производительностью, работает с 2015 года. Это и есть секретный ингредиент Dash, поскольку он позволяет масштабироваться ончейн до количества транзакций, сопоставимого с Paypal, в то же время сохраняя мгновенное подтверждение и комиссию в пределах одного цента.

Мы уже были свидетелями того, как созданный на Ethereum проект Zaigar перешёл с Ethereum на Dash, отказавшись от их собственного ERC-20 токена (ZAI) в пользу Dash, что экономит им тысячи долларов на транзакциях ежемесячно. Возможно, этот случай станет первым из многих? Киберспортивная платформа ReadyRaider также предпочла сотрудничать с Dash для оформления подписок, покупки внутриигровых предметов между игроками, оплаты чаевых и взносов на турнирах.

Сможет ли Dash Platform соперничать с функционалом Ethereum, предложив разработчикам контракты данных, имена пользователей, децентрализованный API и хранение данных на блокчейне? Из этого интервью можно предположить, что успех по большей часть будет зависеть от способности Dash продолжать привлекать в сообщество таких разработчиков, как 'readme', чтобы они создавали свои Dapps на его платформе.

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

P.S. Ссылки на недавнее интервью с одним из разработчиков Dash:
Путь к DashPay (часть 1 из 4)
Путь к DashPay (часть 2 из 4)
Путь к DashPay (часть 3 из 4)
Путь к DashPay (часть 4 из 4)
Подробнее..

Видео трансляция с OvenMediaEngine, до свидания nginx-rtmp-module

15.12.2020 04:09:34 | Автор: admin


Роман Арутюнян (rarutyunyan) выпустил модуль nginx-rtmp-module, это сильно перевернуло взгляд на доступность организации видеовещания. До этого, это казалось каким-то дорогим и сложным делом. 31 декабря Adobe официально хоронит флешплеер и убирает ссылки на скачивание с сайта. Это, конечно, не может не радовать. Эти засранцы то и дело подсовывали включенные по умолчанию галочки, так что пользователю прилетал вместе с флешплеером еще и антивирус mcafee в лучшем случае. То, что это чудовище бесконечно просило обновлений ручками через браузер, знают все. Ходил даже анекдот, предлагающий создателям флешплеера законодательно ограничить паспорта сроком на 1 неделю с возможностью бесконечной перевыдачи.

Кому сдался флешплеер в конце 2020-го, вы хотите сказать? Да дело в том, что флеш плеер единственный поддерживал воспроизведение протокола rtmp в браузере с относительно низкой задержкой. Да и он не так уж и плох, учитывая, что по умолчанию все стриминговые сервисы, youtube или twitch из кодировщика просят передавать им видео по протоколу rtmp. Конечно, приходит более свежий SRT но разговор не об этом. Вы убрали возможность играть видео в браузере по rtmp, а где альтернативы-то? Форматы, работающие по http требуют хорошей буферизации. Задержка выливается в 15 секунд. Это неприемлемо, если вы общаетесь со своей аудиторией онлайн. WebRTC решения плохо дружат с реализацией один ко многим. Ну как плохо, плати, и будет хорошо. Cофт есть на рынке. Только беда еще с покрытием, по моим ощущениям, WebRTC только только нащупал какую-то стабильную фазу, при которой его можно использовать. Но все равно есть небольшие проблемы с форматами видео на разных платформах. Раньше все это выглядело так муторно, что проще было просить ставить флешплеер только ради малой задержки.

В issue к nginx-rtmp-module не я один оставлял вопросы о поддержке форматов передачи видео по http с низкой задержкой (2-3 секунды). Ведь если бы можно было вещать в формате dash и hls до 3 секунд на nginx-rtmp-module, меня бы это полностью устроило. Но ответов на эти вопросы нет. Низкая задержка нужна в 2020 году и без нее ну никак. К сожалению, проект c 2017 года не развивается.

Медиасервер OvenMediaEngine.


Прекрасной альтернативой, отвечающей порывам всех моих желаний, является корейская морковка опенсорсный проект OvenMediaEngine, предлагающий не только средства кодирования и кластеризации (как у nginx-rtmp-module) но и средства воспроизведения т.е. свой html5 плеер. Именно то, чего я так искал, зарелизили наши южнокорейские братья. С большим интересом я крутил его неделю и полностью перебрался на него.

Задержка по WebRTC полсекунды. Задержка по dash low latency 2 секунды. HLS low latency скоро обещают.

Возможности:

  • RTMP Push, MPEG2-TS Push, RTSP Pull Input
  • WebRTC sub-second streaming
  • Embedded WebRTC Signalling Server (WebSocket based)
  • ICE (Interactive Connectivity Establishment)
  • DTLS (Datagram Transport Layer Security)
  • SRTP (Secure Real-time Transport Protocol)
  • ULPFEC (Forward Error Correction) with VP8, H.264
  • In-band FEC (Forward Error Correction) with Opus
  • Low-Latency MPEG-DASH streaming (Chunked CMAF)
  • Legacy HLS/MPEG-DASH streaming
  • Embedded Live Transcoder (VP8, H.264, Opus, AAC, Bypass)
  • Origin-Edge structure
  • Monitoring
  • Experiment
  • P2P Traffic Distribution
  • RTSP Pull, MPEG-TS Push Input

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

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

  1. Показывают, как работают примеры по http и ws протоколу, хотя, очевидно, показывать нужно сразу, как работать на https и wss, все равно же придется заново все перенастраивать. К тому же, о прикреплении бесплатных сертификатов от Lets Encrypt в документации ни слова, хотя официально полностью поддерживают.
  2. Аналогично, после настройки и запуска сервера точка входа публично доступна для всех.(как и у nginx-rtmp-module) Нужно сразу показывать, как защищать точку входа.

Это все мелочи. Похвалю за очень удобные средства отладки. Они предлагают две страницы

http://demo.ovenplayer.com
https://demo.ovenplayer.com

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

Установка. Быстрый старт


Итак, я возьму 20-ую Убунту.

https://airensoft.gitbook.io/ovenmediaengine/v/0.10.10/getting-started

docker run -d \-p 1935:1935 -p 4000-4005:4000-4005/udp -p 3333:3333 -p 8080:8080 -p 9000:9000 -p 10000-10010:10000-10010/udp \airensoft/ovenmediaengine:latest


После ставим certbot. Привязывайте ip к домену, получайте сертификаты.

Далее, получаем имя контейнера докера, например, 87b8610034bc

sudo docker container ls


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

sudo docker cp 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml ./Server.xml


Старый добрый xml. (Мода же на json все дела но благо это вообще не xml как в каком нибудь IIS, который, казалось бы, выступает какой то базой данных для миллиона кнопок в интерфейсе вебсервера.)

Выглядит конфиг так
https://github.com/AirenSoft/OvenMediaEngine/blob/master/misc/conf_examples/Server.xml

Раздел VirtualHost. Нам нужно задать имя сервера и указать пути к сертификатам внутри контейнера.
<Host>    <Names>        <Name>stream.***.ru</Name>    </Names>    <TLS>        <CertPath>/opt/ovenmediaengine/bin/cert.pem</CertPath>        <KeyPath>/opt/ovenmediaengine/bin/privkey.pem</KeyPath>        <ChainCertPath>/opt/ovenmediaengine/bin/chain.pem</ChainCertPath>    </TLS></Host>


Затем, нужно оставить только TLSPort порты.
<Publishers>    <HLS>        <TLSPort>${env:OME_HLS_STREAM_PORT:8080}</TLSPort>    </HLS>    <DASH>        <TLSPort>${env:OME_DASH_STREAM_PORT:8080}</TLSPort>    </DASH>    <WebRTC>        <Signalling>            <TLSPort>${env:OME_SIGNALLING_PORT:3333}</TLSPort>        </Signalling>    </WebRTC></Publishers>

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

Заливаем конфиг обратно
sudo docker cp ./Server.xml 87b8610034bc:/opt/ovenmediaengine/bin/origin_conf/Server.xml

И, соответственно, по заданным путям мы кидаем наши ключи

docker cp /etc/letsencrypt/live/stream.****.ru/chain.pem 87b8610034bc:/opt/ovenmediaengine/bin/docker cp /etc/letsencrypt/live/stream.****.ru/privkey.pem 87b8610034bc:/opt/ovenmediaengine/bin/docker cp /etc/letsencrypt/live/stream.****.ru/cert.pem 87b8610034bc:/opt/ovenmediaengine/bin/


Перезапуск

sudo docker restart 87b8610034bc

Пробуем.

Урл вещания в obs
rtmp://stream.***.ru:1935/app


ключ stream

Линки для паблика

dash https://stream.***.ru:8080/app/stream/manifest.mpddash ll https://stream.***.ru:8080/app/stream/manifest_ll.mpdhls https://stream.***.ru:8080/app/stream/playlist.m3u8webrtc wss://stream.***.ru:3333/app/stream/


Если после запуска трансляции в obs все хорошо и по линкам отдается манифест, можете проверить видео на странице с плеером.

Подписывание ссылок


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

1. Добавить блок SignedPolicy в секцию VirtualHost в Server.xml

<SignedPolicy>    <PolicyQueryKeyName>policy</PolicyQueryKeyName>    <SignatureQueryKeyName>signature</SignatureQueryKeyName>    <SecretKey>secretkey</SecretKey>          <Enables>        <Providers>rtmp</Providers>        <Publishers>webrtc,hls,dash,lldash</Publishers>    </Enables></SignedPolicy>

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

2. Запускаем signed_policy_url_generator.sh с параметрами, описанными внутри.

Например:
sudo bash ./signed_policy_url_generator.sh secretkey rtmp://stream.***.ru:1935/app/stream signature policy '{url_expire:8807083098927}'

url_expire обязательный параметр, который просит в миллисекундах (это не unix timestamp, а currentmillis.com ) указать, когда истечет ссылка.

результат:

rtmp://stream.***.ru:1935/app/stream?policy=eyJ1cmxfZXhwaXJlIjo4ODA3MDgzMDk4OTI3fQ&signature=xjS7NY-l4lY1f9e9sOiRNhPtAqI


rtmp://stream.***.ru:1935/app идет в OBS в Server, остальная часть в Stream key.

3. Если OBS стартанул трансляцию, теперь нужно обязательно подписать необходимые публичные ссылки. Например для WebRTC.

sudo bash ./signed_policy_url_generator.sh secretkey wss://stream.***.ru:3333/app/stream signature policy '{"url_expire":8807083098927}'


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

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

sudo systemctl enable docker


sudo docker update --restart unless-stopped 87b8610034bc


О кодировании видео

Ребята считают OBS самым популярным кодировщиком для своего сервера. Поэтому как и в документации, так и более подробно в блоге можно найти подходящие настройки, максимально снижающие задержку в трансляции. Так же у них есть универсальный энкодер для андройда.
https://play.google.com/store/apps/details?id=com.airensoft.ovenstreamencoder.camera

Еще немного о корейской морковке


Когда пользователь выбирает в плеере в качестве источника webrtc, OME на лету конвертирует аудио в требуемый формат opus.(Это требования стандарта.)

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

Пожелания



  1. Система логов это обычные txt файлики. Было бы очень круто иметь чуть более продвиную визуальную аналитику
  2. Я пробовал новый nginx-unit с его модным json-api в качестве команд управления/конфига. Суть в чем, обновляешь вебсервер, а он продолжает работать, заливаешь сертификаты, а ему не надо перезагружаться, домен, поддомен, добавить заголовки, убрать все налету без перезагрузки. А поверх json-api появляется миллион офигенно удобных админок с UI. Хотя в OME и вроде бы и нет нужды в таком API, но наверняка кто-то что-то потом обязательно придумает)


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

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



Подробнее..

Чтобы первый блин не вышел комом. Советы начинающему разработчику сервиса

26.05.2021 10:15:20 | Автор: admin

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

Специально для статьи я подготовил два идентичных примера на Flask и Dash и выложил их на GitHub. В них иллюстрируется расчет и вывод показателей юнит-экономики абстрактного IT-маркета, который называется Хабр (а почему бы и нет, ведь сейчас все компании начали заниматься электронной коммерцией:).

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

ОПП: не умеешь не берись! Когда речь заходит об ОПП, мне почему-то автоматически вспоминается Django с его классами. Но если посмотреть работы начинающих data scientist-ов или аналитиков данных, то мы увидим совсем другую картину. Классы применяются ради самих классов. В данную структуру языка просто сливается весь код. За что отвечает этот монстр? За все! Как искать ошибки или переписывать код, не понятно. Лично у меня такое мнение на этот счет. Если не знаешь когда, как и почему следует применять ОПП, то лучше для небольших разработок использовать процедурно-функциональный стиль.

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

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

Муки выбора или о разных фреймворках замолвим слово. Сочетание каких технологий можно использовать для создания собственного сервиса? Приведу несколько вариантов, которые сразу приходят на ум. Заранее прошу прощения, что обойду вниманием PHP, Ruby, C#:

  • Flask статичные страницы с шаблонами HTML+CSS

  • Django статичные страницы с шаблонами HTML+CSS

  • Flask Rest API/FastAPI/Django Rest Framework динамические страницы HTML+CSS+фреймворк Javascript (Vue, React, Angular)

  • Dash (по сути работает Flask) Dask (по сути работает React)

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

  • Нужно выводить таблицы, графики, интерактивные элементы здесь и сейчас Dash

  • Нужно рендерить отдельные показатели на статичной странице. Есть время на эксперименты с дизайном, но нет помощи фронтенд-разработчика Flask

  • Нужно выводить разноплановую информацию, нужна интерактивность. Есть много времени, есть ресурсы, плюс поддержка верстальщика и фронтенд-программиста FastAPI Vue.js

Теперь приведу скриншоты работ на Flask и Dash и сделаю несколько замечаний касательно данных платформ.

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

В проекте Flask файл, который отвечает за вывод результатов, страницы html и фреймворк css это разные сущности. Документация по Bootstrap4 довольно качественная, но так как у меня нет навыков верстки, мне не удалось добиться корректного вывода всех сводных таблиц.

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

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

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

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

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

Не все то золото, что YAML-файл. Идею применения yaml файла для хранения констант проекта я почерпнул из одного видео-ролика практикующего data scientist-а на Youtube. Что в этом плохого или хорошего я не знаю. Решать только вам.

А не замахнуться ли нам на Docker. Небольшое лирическое отступление. Чего мне реально не хватает в Windows, так это Docker. В Windows 10 эту проблему решили, а вот в предыдущих версиях пользователям остается лишь устанавливать Docker Toolbox. Но в настоящее время разработка и поддержка данного продукта завершена, хотя архивный файл можно по-прежнему скачать на официальном аккаунте Docker на GitHub. Лично у меня по некоторым причинам установлен Windows 8.1, поэтому я задался вопросом, как еще можно заполучить в распоряжение эту программу. Установку второй операционной системы я отмел сразу, а вот вариант с виртуальной машиной меня заинтересовал. Для экономии ресурсов я выбрал Debian 10. Если выделить под нужды ВМ один процессор и три гигабайта оперативной памяти, то вполне можно тестировать свои идеи. Но стоит оговориться, что если захочется собрать и запустить контейнер с Apache Airflow, то указанных вычислительных мощностей будет недостаточно.

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

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

И вот вам конкретный пример. Я построил контейнер на Dash, а дашборд в браузере не отображается. В локальном варианте все было нормально. Оказалось, я просто забыл поменять в файле app.py хост с 127.0.0.1, на 0.0.0.0.

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

На этом все. Всем здоровья, удачи и профессиональных успехов!

Подробнее..

Категории

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

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