[AlexandrY 3]

Платформа - это инфраструктура, набор готовых решений разных уровней, протоколов обмена, устройств и т.п.

Сюда относится в том числе и набор гаджетов на странице в браузере.

 

Только не надо переделывать наш язык. Инфрастуктура - это инфраструктура, платформа - это платформа. А мы говорим о фреймворке.

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

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

 

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

 

Сочувствую. А мне вот этого не хочется от гигантов.

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

 

Чем лабуда на яваскрипте отличается от лабуды на дельфи? ;)

 

Интерпретацию в среде броузера от компиляции в нативный код платформы отличаете?

Просто я тут недавно с шумом вытеснил решение по автоматизации производства сделанное в виде WEB приложения на PHP и заменил его на нативное сделанное в RAD studio, причем делая его чуть ли не левой ногой.

 

[Johnny81 0]

Только не надо переделывать наш язык. Инфрастуктура - это инфраструктура, платформа - это платформа. А мы говорим о фреймворке.

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

 

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

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

 

Сочувствую. А мне вот этого не хочется от гигантов.

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

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

 

Интерпретацию в среде броузера от компиляции в нативный код платформы отличаете?

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

 

Просто я тут недавно с шумом вытеснил решение по автоматизации производства сделанное в виде WEB приложения на PHP и заменил его на нативное сделанное в RAD studio, причем делая его чуть ли не левой ногой.

И какие выводы можно сделать из этого факта? На нашем предприятии, к примеру, итерации были такие - php -> delphi -> 1C :)

[zltigo 2]

Просто я тут недавно с шумом вытеснил решение по автоматизации производства сделанное в виде WEB приложения на PHP и заменил его на нативное сделанное в RAD studio, причем делая его чуть ли не левой ногой.

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

 

[AlexandrY 3]

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

 

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

Потребитель будет видеть только сервисы и то не все.

 

Да и откуда у меня возникнет "уникальный протокол" если все будет сделано на глобальном фреймворке?

Но фреймворк не определяет сервисы.

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

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

 

 

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

 

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

Но заводик использует исключительно Windows. А разработка на RAD на порядки проще. И все, он проиграл.

Поэтому для меня главный индикатор это наличие RAD тулсов.

Вот нет у Rassberry инструментов RAD, значит с Rassberry что-то не то.

[zltigo 2]

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

Но заводик использует исключительно Windows. А разработка на RAD на порядки проще. И все, он проиграл.

Проблему лично я сейчас увидел не в том, что "WEB" или "RAD", а в том, что ЛЕПИЛИ что-то под заказчика. Именно лепили, конечно не на пустом месте, а в меру своего предыдущего опыта. Если-бы у каждого из вас был базовый продукт близкий к "коробочному" для решения подобного класса задач, то тогда и можно было говорить о сравнении результатов ПОДХОДА к делу, а не о сравнении "лепнины".

 

[one_man_show 0]

Проблему лично я сейчас увидел не в том, что "WEB" или "RAD", а в том, что ЛЕПИЛИ что-то под заказчика.

А я увидел проблему в том, что собеседники хотя и говорят об одном и том же, что Raspberry Pi невозможно использовать в промышленных решениях, но все-таки каждый стремится указать друг другу, как нужно правильно работать и что его опыт лучше это показывает )))

 

Мне не нравится фраза "ЛЕПИЛИ что-то под заказчика", когда тебе предстоит реализовать весь нижний уровень проекта автоматизации горнотранспортного комплекса. При этом, под нижним уровнем понимается установка базовой станции, точек доступа на жд станциях, бортовых комплексов на каждой единице горнотранспортного оборудования, АФУ, учебные классы, учебное оборудование, системы управления МСУ СЦБ, завязать несколько жд станций на диспетчерскую, установить диспетчерский пульт... Все это у тебя на полке в виде коробочного продукта просто не может быть. особенно когда в процессе реализации проекта заказчик вдруг приобретает 12 самосвалов Коматсу и твои бортовые комплексы также приходится на них устанавливать, хотя они были разработаны для электровозов ))) Именно разработаны, а не взяты в виде коробочного продукта, причем все, начиная с корпуса

 

Игорь, мне правда, без поддевки, было бы интересно ознакомиться с Вашим опытом в области угольных разрезов, если не затруднит, дайте какие-нибудь ссылки. Причем, мне интересно всё, в том числе, удалось ли Вам изначально правильно посчитать подобные проекты, не просчитавшись с затратами. которые вылезли по мере реализации. У меня, например, ничего не сошлось именно из-за того, что Заказчик постоянно хотел вносить свои изменения. В результате поездок в год оказалось не 2, как рассчитывал, а более 5. К слову, одна поездка обходилась в 300 тыс.р.

[zltigo 2]

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

Стоп! Вообще-то слово "лепили" относилось в том контексте исключительно к некоему софту сделанному НЕ Вами для какого-то "заводика". Вы-же почему-то сейчас начали разновор

1) О себе

2) О своем железе.

Игорь, мне правда, без поддевки, было бы интересно ознакомиться с Вашим опытом в области угольных разрезов, если не затруднит, дайте какие-нибудь ссылки. Причем, мне интересно всё, в том числе, удалось ли Вам изначально правильно посчитать подобные проекты, не просчитавшись с затратами. которые вылезли по мере реализации. У меня, например, ничего не сошлось именно из-за того, что Заказчик постоянно хотел вносить свои изменения. В результате поездок в год оказалось не 2, как рассчитывал, а более 5. К слову, одна поездка обходилась в 300 тыс.р.

Напишу в личку. Вечером.

 

[one_man_show 0]

Стоп! Вообще-то слово "лепили" относилось в том контексте исключительно к некоему софту сделанному НЕ Вами для какого-то "заводика". Вы-же почему-то сейчас начали разновор

1) О себе

2) О своем железе.

Всё! пора в отпуск :)

Напишу в личку. Вечером.

ОК, спасибо!

[Reanimatorr 1]

Я вижу в малинке возможность относительно просто создавать свои устройства с полноценным экраном управления.

(либо тач, либо экран с кнопками по краям).

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

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

 

Еще я вижу в ней относительную простоту сопряжения с низкоуровневыми устройствами.

 

Вот сейчас есть проект установки, пока кстати выбрали за основу именно J1900. В нем есть несколько тупых исполнительных модулей (из серии PIC18), которыми надо управлять. Как сопрячь их с X86? Ставить плату расширения на кучку RS-232/485?

[A. Fig Lee 0]

Еще я вижу в ней относительную простоту сопряжения с низкоуровневыми устройствами.

 

Вот сейчас есть проект установки, пока кстати выбрали за основу именно J1900. В нем есть несколько тупых исполнительных модулей (из серии PIC18), которыми надо управлять. Как сопрячь их с X86? Ставить плату расширения на кучку RS-232/485?

Дык там очень мало периферии

[syoma 1]

Еще одно мнение по поводу почему Распберри и Ардуино отличаются от других отладочных плат или в чем их специфика:

Распберри, в отличии от отладочной платы - это как бы реклама. Реклама того, что на нем можно сделать. Т.е. с учетом всех сайтов, приложений и шильдов можно легко найти ответы на вопросы - "А это можно сделать? А вот это? А как это сделать?" - причем в виде примеров и роликов на ютуб. Т.е. человек, покупая распбери, уже знает точно, что на нем можно реализовать, и даже во многих случаях - как. Ведь в 95% случаев нужно просто повторить какое либо решение, а не изобретать новое с нуля. И в оставшихся 5% - немного допилить.

 

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

 

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

[AlexandrY 3]

Распберри, в отличии от отладочной платы - это как бы реклама. Реклама того, что на нем можно сделать. Т.е. с учетом всех сайтов, приложений и шильдов можно легко найти ответы на вопросы - "А это можно сделать? А вот это? А как это сделать?" - причем в виде примеров и роликов на ютуб. Т.е. человек, покупая распбери, уже знает точно, что на нем можно реализовать, и даже во многих случаях - как. Ведь в 95% случаев нужно просто повторить какое либо решение, а не изобретать новое с нуля. И в оставшихся 5% - немного допилить.

 

Наивное заблуждение.

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

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

На сетевом стеке, WEB-е, файловой системе, кое каким оконным фреймворкам, и несчастном интерфейсе камеры.

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

А далее идет отсылка к линуксовому софту где якобы все можно найти.

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

 

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

Я открываю какой нибудь опенсорс типа Apache WEB сервер под Pasberry и понимаю, что любого гика решившего это использовать во встраиваемом дивайсе для работы с железом я обгоню с обычным lwIP на STM32.

Причем гик поставив lwIP на Raspberry уроется еще сильней.

[syoma 1]

Наивное заблуждение.

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

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

На сетевом стеке, WEB-е, файловой системе, кое каким оконным фреймворкам, и несчастном интерфейсе камеры.

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

А далее идет отсылка к линуксовому софту где якобы все можно найти.

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

 

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

Я открываю какой нибудь опенсорс типа Apache WEB сервер под Pasberry и понимаю, что любого гика решившего это использовать во встраиваемом дивайсе для работы с железом я обгоню с обычным lwIP на STM32.

Причем гик поставив lwIP на Raspberry уроется еще сильней.

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

Опять же знать все невозможно - я,например, знаю в линуксе только пару команд, а lwIP - тем более темный лес. Но я знаю чего я хочу. Поэтому я запущу макет на Raspberry за вполне определенное время без этих знаний, а потом приду к AlexandrY или другому такому же спецу и скажу "Сделай мне такое же, только на STM32 и чтобы надежно работало". И сделают. И за вполне определенное время. И не сомневаюсь, что во время разработки вы еще десять раз заглянете в исходники Raspberry чтобы посмотреть "а как же там это сделано?". А еще у инженера не будет отмазки по срокам из-за того, что типа не влезло или вообще невозможно реализовать - так вот же есть пример и он работает!

[one_man_show 0]

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

 

1. Есть известная робототехническая платформа REEM-C, представляющая собой человекоподобного двуногого робота.

Эта платформа очень популярна, и многие Университеты Мира покупают или арендуют эту платформу для проведения своих исследований. Например, недавно Technische Universitдt Mьnchen получил этого робота для проведения своих исследований в Institute for Cognitive Systems.

Специально привожу все ссылки, чтобы было понятно, что это не "детский сад". Хотя, уверен, найдутся собеседники, для которых это не показатель.

 

2. Если обратить внимание на параметры платформы, увидим, что она выполнена на 100% на основе фреймворка ROS (Robot Operating System). Не буду утомлять примерами других платформ на основе этой ОС, изучив сайт, можно найти множество известных решений, от простых трехколесных тележек, до шагающих с продвинутыми манипуляторами.

 

3. Заглянув в недра ROS, например, в раздел библиотек для последовательных интерфейсов, которые используются для связи с внешним миром, можно увидеть три популярных для робототехники клиента с точки зрения интерфейса: Arduino, EmbeddedLinux и Windows.

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

 

Обратите внимание, REEM-C - это уже серийно выпускаемая платформа, ROS - уже очень популярный в профессиональных кругах фреймворк, и никого не удивляет наличие в нем "ответной части" для Ардуино. То есть, макетируем, используя ROS и подходящие железки, а серийно выпускаем, базируясь на своих разработках.

[zltigo 2]

А еще у инженера не будет отмазки по срокам из-за того, что типа не влезло или вообще невозможно реализовать - так вот же есть пример и он работает!

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