Комментарии 18
Господи, jQuery, Dreamweaver… а я уже стал забывать эти слова...
Я пока изучал как работает jQuery и радовался, как всё просто (особенно по сравнению с тем, как это было в начале нулевых), оказалось, что он мне не особо то и нужен. Современный JS умеет делать всё тоже самое, только шустрее. Правда совместимость со старыми браузерами хуже. Ну и пофигу, всё равно браузеры везде обновляю и если делаю для себя, то излишняя совместимость с древними браузерами точно не нужна.
Bootstrap тоже штука удобная, если нужно быстро что-то накидать. Правда от jQuery они отказались только в 5 версии, которая до сих пор beta. Но для таких слабых устройств проще минимально накидать css только для того, что тебе надо. Сомневаюсь, что там нужен какой-то разухабистый интерфейс.
Там сразу во-первых, виден конечный вид страницы без необходимости всё время запускать сервер и браузер.
Во-вторых, Dreamweaver сам собирает все необходимые файлы во фреймворк. Не надо даже смотреть документацию и самому писать хидеры страниц.
Хотел бы я узнать что может заменить Dreamweaver в этом качестве.
Я честно искал, но альтернатив не нашел.
А так не отрицаю что можно ужать и отказаться от jQuery mobile.
Но как я вроде показал этот труд будет практически напрасным.
В интернете гораздо легче найти советы как сделать то или иное с помощью jQuery чем с помощью голого AJAX и JavaScript.
Все же селекторы jQuery — это очень интуитивный подход.
Если что, ни в коем случае не отговариваю использовать что-то.
Селекторы в современном JS не сильно отличаются. Разве что многословно писать приходится. Но зато избавляемся от зависимости в виде "огромной" библиотеки.
Ну а на счёт того, чем заменить. Я обычно использую gulp и плагин browser-sync. Сервер у меня всё равно есть, но и без него работать будет, он локальный сервер поднимает, если нужно. У меня прокси настроен в browser-sync. Просто пишешь код, в чём удобно, а в браузере у тебя всё автоматом подхватывается и обновляется. И css и js, в том числе.
Кстати, я бы с железки убрал лишнее вообще. Страничку и скрипты для управления можно хранить локально, а на железке только ответы AJAX организовать. https тоже иногда можно выкинуть, если железка в закрытой локалке. Можно всякие jQuery грузить из интернета, если железка подразумевает одновременный доступ на неё и в интернет. С bootstrap аналогично.
Там написано что-то вроде «помошник в тестировании».
Не могли бы пояснить как вы его конкретно применяете?
Да, я забыл написать, но моя технология заточена на однократное использование интерфейса. Просто настроить дивайсу правильное подключение и больше не трогать.
Дальше предусматривалась работа парка устройств по 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 интерфейс, то где примеры с графикой, шкалами, анимацией? интересно было бы посмотреть слайдеры, индикаторы уровня аудио сигнала, создание кастомной странички пользователя, на которую выносятся только нужные элементы управления. ВЕБ, что в статье легко поднимается на восьмибитном процессоре. Вебом для настройки на МК сейчас никого не удивишь.
Типа вот нашли фреймворк, быстренько накидали интерфейс, возможно только для того чтобы переключить дивайс с режима Access Point в режим станции и забыли.
Надо только чтобы пароли не перехватили и чтобы на смартфоне это смотрелось современно.
Дальше ничего более крутого в WEB интерфейсе я делать не предполагал, потому что все остальное предполагается делать через более эффективные каналы.
Например MQTT и облака, или MQTT и собственного брокера.
А там я уже пишу нативное приложение под Windows, которое будет гораздо более удобней чем WEB приложения и будет работать одновременно со многими дивайсами.
Согласитесь, если у вас парк устройств, то работать с каждым индивидуально через их WEB интерфейс совсем не привлекает.
Для МК это очень актуально. Только файлы нужно заранее зиповать, что бы хранились уже подготовленными и МК не тратил ресурсы.
В HTTP сервере придется делать связку с файловой системой, что бы распознавать атрибуты файлов и править заголовки сервера, что бы указать, что файл зазипован.
Представленный в статье подход позволяет вроде бы быстро стартануть, но в дальнейшем это превратится в ком проблем, если начать делать, что то сложнее чем было показано.
Т.е. то что раньше делали на нескольких страницах у jQuery mobile размещается в одном HTML файле.
Это значит что фреймворк скачивается всего один раз за всю пользовательскую сессию.
Т.е. вместо 400 мс, ну доведете используя сжатые файлы время скачивания до 200 и все!
Но назвать проблемой 400мс язык не поворачивается.
Затем еще надо учесть что выбрана достаточно производительная линейка микроконтроллеров, они умеют развивать поток до 100Мбит в сек. Я данные привел для скорости WiFi в 20 Мбит в сек в медленном режиме Access Point. На Ethernet-е будет быстрее в 5-ть раз.
Далее следует учесть, что картинки сжимать бесполезно, динамический трафик сжимать не оправдано, а при использовании на этапе отладки сниферов гораздо удобнее наблюдать несжатые файлы фреймворка.
Ваш совет технически правильный, но в моей постановке условий не целесообразный.
В роутерах действительно надо делать полноценную бизнес логику, там линукс и его специфичная инфраструктура.
Я такую логику делаю в нативных приложениях под Windows.
А так для моделирования схемы данных имею свое приложение, которое генерит исходники на C-и и которые встраиваются прямо в проект firmware. Но об этом может напишу в другой статье.
Разработка защищённого WEB интерфейса для микроконтроллеров