Pull to refresh

Comments 18

Господи, jQuery, Dreamweaver… а я уже стал забывать эти слова...

маленькому кораблю — маленькая торпеда

Я пока изучал как работает jQuery и радовался, как всё просто (особенно по сравнению с тем, как это было в начале нулевых), оказалось, что он мне не особо то и нужен. Современный JS умеет делать всё тоже самое, только шустрее. Правда совместимость со старыми браузерами хуже. Ну и пофигу, всё равно браузеры везде обновляю и если делаю для себя, то излишняя совместимость с древними браузерами точно не нужна.
Bootstrap тоже штука удобная, если нужно быстро что-то накидать. Правда от jQuery они отказались только в 5 версии, которая до сих пор beta. Но для таких слабых устройств проще минимально накидать css только для того, что тебе надо. Сомневаюсь, что там нужен какой-то разухабистый интерфейс.

Я выбрал jQuery mobile потому что он поддерживается в Dreamweaver.
Там сразу во-первых, виден конечный вид страницы без необходимости всё время запускать сервер и браузер.
Во-вторых, Dreamweaver сам собирает все необходимые файлы во фреймворк. Не надо даже смотреть документацию и самому писать хидеры страниц.
Хотел бы я узнать что может заменить Dreamweaver в этом качестве.
Я честно искал, но альтернатив не нашел.

А так не отрицаю что можно ужать и отказаться от jQuery mobile.
Но как я вроде показал этот труд будет практически напрасным.
В интернете гораздо легче найти советы как сделать то или иное с помощью jQuery чем с помощью голого AJAX и JavaScript.
Все же селекторы jQuery — это очень интуитивный подход.

Если что, ни в коем случае не отговариваю использовать что-то.
Селекторы в современном JS не сильно отличаются. Разве что многословно писать приходится. Но зато избавляемся от зависимости в виде "огромной" библиотеки.
Ну а на счёт того, чем заменить. Я обычно использую gulp и плагин browser-sync. Сервер у меня всё равно есть, но и без него работать будет, он локальный сервер поднимает, если нужно. У меня прокси настроен в browser-sync. Просто пишешь код, в чём удобно, а в браузере у тебя всё автоматом подхватывается и обновляется. И css и js, в том числе.
Кстати, я бы с железки убрал лишнее вообще. Страничку и скрипты для управления можно хранить локально, а на железке только ответы AJAX организовать. https тоже иногда можно выкинуть, если железка в закрытой локалке. Можно всякие jQuery грузить из интернета, если железка подразумевает одновременный доступ на неё и в интернет. С bootstrap аналогично.

Не понял, честно говоря, что упрощает или ускоряет применение gulp с browser-sync.
Там написано что-то вроде «помошник в тестировании».
Не могли бы пояснить как вы его конкретно применяете?

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

Ааа. Кажется понял для чего Dreamweaver. Вам просто лень разбираться в HTML. Хотя в вашем случае это было бы даже плюсом, чтобы не тянуть за собой лишнее. gulp больше нужен при разработке дизайна, тут он точно не особо нужен, но и лишним не будет.
В вашем случае даже css не особо нужен. Будет страшненько выглядеть, но работать будет.

Я что-то запутался.
Про gulp написано — «A toolkit to automate & enhance your workflow»
Ни слова про дизайн.
Но как вы в нем можете делать дизайн быстрее чем в Dreamweaver?
Dreamweaver же позволяет визуально конструировать дизайн.
Это же самый кратчайший путь, а фремворки больше заточены на создание приложений.
Но так получилось что я не силен в дизайне вообще и jQuery mobile понравился с первого взгляда.
А на странице gulp я не вижу нигде примеров дизайна.
Может дадите ссылку посмотреть хоть где-нибудь этот дизайн?

Господи, jQuery, Dreamweaver… а я уже стал забывать эти слова…

...AJAX.
Интересно, особенно покопаться сколько ресурсов и памяти будет жрать такой сервер на МК и стоит ли овчинка выделки.
Однако хотел бы указать на то, что заголовок немного нечестный. Сразу бы сказали какой что пост про Азур, а не выбор веб сервера
Статья не про выбор WEB сервера, а про выбор WEB интерфейса.
Прочитал статью, потому что меня интересовал именно WEB сервер на МК.
Но прочитав статью не нашел для себя нужной информации.
Если написали про WEB интерфейс, то где примеры с графикой, шкалами, анимацией? интересно было бы посмотреть слайдеры, индикаторы уровня аудио сигнала, создание кастомной странички пользователя, на которую выносятся только нужные элементы управления. ВЕБ, что в статье легко поднимается на восьмибитном процессоре. Вебом для настройки на МК сейчас никого не удивишь.
Тут дело в том что цель была показать именно скоростную разработку WEB интерфейса. Без необходимости глубокого погружения в WEB технологии.
Типа вот нашли фреймворк, быстренько накидали интерфейс, возможно только для того чтобы переключить дивайс с режима Access Point в режим станции и забыли.
Надо только чтобы пароли не перехватили и чтобы на смартфоне это смотрелось современно.
Дальше ничего более крутого в WEB интерфейсе я делать не предполагал, потому что все остальное предполагается делать через более эффективные каналы.
Например MQTT и облака, или MQTT и собственного брокера.
А там я уже пишу нативное приложение под Windows, которое будет гораздо более удобней чем WEB приложения и будет работать одновременно со многими дивайсами.
Согласитесь, если у вас парк устройств, то работать с каждым индивидуально через их WEB интерфейс совсем не привлекает.
В стаье писали про сжатие
Заголовок спойлера
Сжатие контента. Современные браузеры поддерживают компрессию передаваемых страниц и сопутствующих файлов. Компрессия типичных HTML файлов, скриптов и стилей позволяет уменьшит объем передаваемых данных в 3-4 раза. Сервер HTTP Azure не поддерживает компрессию на лету, для микроконтроллеров компрессия может оказаться более продолжительным процессом чем передача несжатого контента. Есть возможность выполнить компрессию статических файлов сразу же при подготовке контента. И хранить файлы на SD карте уже сжатыми, однако HTTP сервер Azure не поддерживает распознавание сжатых файлов и соответствующую модификацию заголовков HTTP.

Для МК это очень актуально. Только файлы нужно заранее зиповать, что бы хранились уже подготовленными и МК не тратил ресурсы.
В HTTP сервере придется делать связку с файловой системой, что бы распознавать атрибуты файлов и править заголовки сервера, что бы указать, что файл зазипован.
Представленный в статье подход позволяет вроде бы быстро стартануть, но в дальнейшем это превратится в ком проблем, если начать делать, что то сложнее чем было показано.
jQuery mobile понравился еще и тем что позволяет делать одностраничные приложения с очень красивыми плавными переходами от одной панели к другой.
Т.е. то что раньше делали на нескольких страницах у jQuery mobile размещается в одном HTML файле.
Это значит что фреймворк скачивается всего один раз за всю пользовательскую сессию.
Т.е. вместо 400 мс, ну доведете используя сжатые файлы время скачивания до 200 и все!
Но назвать проблемой 400мс язык не поворачивается.

Затем еще надо учесть что выбрана достаточно производительная линейка микроконтроллеров, они умеют развивать поток до 100Мбит в сек. Я данные привел для скорости WiFi в 20 Мбит в сек в медленном режиме Access Point. На Ethernet-е будет быстрее в 5-ть раз.

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

Ваш совет технически правильный, но в моей постановке условий не целесообразный.
Сталкивался с задачей написание web интерфейса для маршрутизатора 50+ страниц с связанной между собой логикой. Использовал связку mongoose + vue.js. Размер всей штуки с сервер который отдает json 800кб и 1,4мб статика собранная vue.js. Сервер отдавал json через websocket. Даже была написана библиотечка компонентов (кнопки, селекты и тд). Так что для чего-то более сложного я бы советовал выбирать mongoose (c++). И использовать один из фреймворков гигантов (vue, react, angular) То на чем умеете писать. Удобнее потом будет поддерживать и сопровождать.
Да, я интересовался на чем сделаны интерфейсы в роутерах. В моем роутере сделано на Angular.
В роутерах действительно надо делать полноценную бизнес логику, там линукс и его специфичная инфраструктура.
Я такую логику делаю в нативных приложениях под Windows.
А так для моделирования схемы данных имею свое приложение, которое генерит исходники на C-и и которые встраиваются прямо в проект firmware. Но об этом может напишу в другой статье.
О, хотелось бы об этом почитать. Так как я все json ручками разбирал и валидировал)
Sign up to leave a comment.

Articles