В принципе могу, но мне показалось они не слишком выше M4 (168 против 216мгц, возможно сама архитектура более шустрая)
Периферии там правда… можно 5 прибором моих на одном МК сделать.
Ну возможно вы правы, в плане сложностей оно может того не стоить.
Просто мне нужен по суть MK, как числодробилка, а лучше с DSP модулем, внешней периферии посути минимум, несколько i2, i2s и дисплей не большой. Может Вы посоветуете что-то более верное?
На данный момент ковыряю stm32F407, но уже вижу что его производительности совсем впритык.
Но халявные чипы MT 6xxx конечно очень прельщают)
Очень интересная статья, спасибо, и назрел такой вот вопрос, возможно косвенный, но все же.
А насколько возможно использовать в bare-metal, процессоры ARM которые скажем стояли в средствах коммуникации? Ну вот чисто потенциально…
Ведь сами по себе они достаточно мощные, плюс aliexpress как кладезь в плане их доступности.
Вот на данный момент имею:
MT6235, MT6575, есть документация на само железо, есть u-boot — с чего так сказать начать, имею ввиду стратегически, ковырял u-boot но пока ничего интересного не нашел (по крайней мере то что вы описали)
Да, я о чистом Си. Писал и пишу на текущий момент, пришел к нему из Python и очень рад.
А насчет «undefined behaviour» и различных «стреляний:
Да, на С++ очень просто выстрелить себе в ногу. Даже множеством разных способов. Но для некоторых людей это плюс. Возможность выстрелить себе в ногу предполагает возможность стрелять вообще куда-угодно, как-угодно и сколько-угодно.
Да, результаты могут быть ужасными.
Но и мощь устрашающа.
согласитесь, странно изучать Windows Server 2003 или Pascal в 2017 году
Странно быть стильно-модно-молодежным Angular разработчиком, и на слова " у тебя течет виртуальная память в приложении", пожать плечами и сказать «а что такое виртуальная память».
Язык не более чем инструмент, а при изучении, чем он проще — тем лучше.
Хочу уточнить, есть простые языки, а есть легкие. К моему мнению, простой язык, это Си: что написал — то получил, не никаких неявных состояний, каких то магических функций и других, с точки зрения прозрачности, вещей. К легким языкам, могу отнести Python. Нет избытка синтаксиса ( я не о скобочках), простая структура, некоторые стили программирования уже в коробке.
Боюсь спросить, какой результирующий размер «мигалки», при наличии стольких зависимостей?
ЗЫ. Боюсь, потому что очевидно что он будет огромен. Заранее говорю, что это не попытка упрекнуть в Вашей RTOS, просто интересно.
Я лишь спросил, где та самая грань, когда есть «командная» и «не командная» разработка.
Ну, для меня командная разработка, это писать какую то свою часть кода, при этом мне не нужно обсуждать что-либо с другим членом команды, если моя часть описана в документации (ну окей, четко выделена, имеет границы)… для других видимо, командная работа это непосредственная балабольня о том как назвать тот или иной метод, заваривание чая в одной кружке на двоих… ну вы понимаете?
Проблема в том, что понятия командная работа перешла все разумные границы (я уже не о удаленке /офисной работе), люди предпочитают болтать, рассказывать о чем то, тренировать свои ораторские навыки, ли ж бы не сесть и не написать, то что должно быть (дока/тесты/реадми файлы).
Agile Coach
ScrumMaster
Простите, кто эти люди и зачем они вобще нужны, какие реальные задачи они решают?
Еще раз повторю, если что то правильно и полно описано, это не требует обсуждений. Люди просто не умею фокусировать свои мысли и идеи. И проблема, здесь не в удаленке или отсутствии командной работы, проблема тут именно в людях и их квалификации.
Хотел добавить насчет «яндекс и гугл». Один, весьма колоритный персонаж, как то сказал «есть успешные проекты, а есть на которых красивый код» (с) А. Соловьев
ЗЫ. Притензии к карме были не к Вам лично, это скорее общий призыв.
Разница между статическим и динамическим выделением памяти
Мне кажется, можно ограничиться тем, что статическая память известна на момент компиляции, а динамическая нет, иначе за слова «статическая память выделяется в стеке.» сейчас полетят метеориты в Ваш огород.
Вот у меня «горит» от таких комментариев, честное слово, что для Вас работа в команде, черт возьми? Крестить вместе детей? Или может уик-энд вместе проводить?
О какой командности вы говорите? Я должен чуять нутром что напишет Вася из соседнего отдела разработки?
Я вместо любой комадности и «двиганья листочков» выберу скорее несколько разделов ВиКи, по стилю написания кода в команде.
Я скорее предпочту тикеты на функциональность и описания на API своего модуля, нежели часовые балабольства. А знаете почему? Потому что это написано в отличии от того что можно сказать и забыть, сказать и не выполнить, сказать и потом спасая свою шкуру переиначить что либо по другому. и т.п.
Парное программирование? Да к черту его, неужели, в этом мире (компании) не найдется какого нить core-разработчика, который может посмотреть в код джуна и сказать что там не так?
ЗЫ. Не понимаю, зачем опускать и без того отрицательную карму, если Вам не нравится комментарий ставьте минус ему, аккаунт то причем, я ж Вам денег не должен…
Основная суть в том, что на момент создания каркаса приложения для тестирования, вы не описываете страницы целиком, а делаете некую структуру модулей внутри страницы. К примеру, есть страница товаров, она включает в себя:
— виджет Товар
— виджет калькулятор (общая цена зачеканных товаров)
— виджет препросмотр (ну например там фотки посмотреть)
Создаем три класса виджетов, и оперируем только входящими для них элементами, и состояниями.
Например для товара это будет, чекбокс выбора, атрибут цены. Для других все точно такое же (для калькулятора результирующая цена, для предпросмотра текущее фото, общее кол. фоток)
Уточнение: Виджетом я называю какую либо активною, порождающую сущность, иными словами, такую, которая может мне вернуть новую страницу, элементом же я называю сущности, которые работают с текущей страницей: Айтем товара, это виджет, так как он мне может вернуть страницу товара, а вот фильтр на странице каталога (по цене например) уже будет элементом, так как он изменяет лишь содержимое страницы, не меняя ее структуры
Далее вы пишите PageItemViewet класс (непосредственно PageObj, которая вам реализует работу с каталогом) и создаете композицию из предопределенных виджетов, при этом не забывая о согласовании интерфейсов между классами:
— pageobj должен сам иметь счетчик ссылок, на множества елементов (вы должны хранить ссылку на каждый товар, и только при использовании товара (выделении, проверки цены ) непосредственно пересоздавать ваш виджет.
— pageobj обязан знать, кто его вызвал, и где он находится, более того для каждого pageobj при создании необходимо проверять текущее положение в веб-приложении, я обычно проверяю в конструкторе уникальных элемент для данной страницы, как пример: при создании при переходе на страницу каталога, я смотрю на заголовок каталога, если он совпадает с тем, куда меня отправил предыдущий шаг — значит я на верной странице. данное действие избавляет от необходимости в тестах, чекать каждый чих переходов (но злоупотреблять им не следует, обычно это основные страницы (каталог, о магазине, контакты, определенный товар)
— все елементы (не активные виджеты) обязательно должны иметь автообновляемые свойства, иначе вы рискуете потерять целостность вашего состояния (вы добавили товар, спрашиваете у калькулятора какова текущая общая стоимость, он вернул 10, вы добавили еще один товар, спрашиваете у калькулятора, а теперь? — он вернул 10, очевидная ошибка, сохраненное предыдущее состояние.)
— реализация getter-ов должна быть сугубо на стороне элементов, и только они должны вам отдавать информацию со страницы. Pageobj являюется только агрегатором виджетов, и хранилищем текущего состояния теста (страницей выполнения).
Как то так. Спасибо за внимание)
Мы договорились, что никаких логических проверок типа assert в таких классах быть не должно – только взаимодействие с UI
Очень интересно… что вы тогда тестируете
1. Ввел креды: logtester/passtester
2. Зашел на страницу — как мне узнать под тем ли я юзером? Нужно найти метод который мне вернет юзера так? А что если таких проверок 10000, если это какая нить форма огромная?
Второй момент, Вы показали только код ваших инпутов, а теперь покажи ваши километровые трайкетчи метода submitForm() и waitForAuthPage(), ведь ошибок может быть масса — как вы их разделяете? Простой пример ошибка валидатора пароля: слишком короткий, и запрещенные символы.
В общем, не хочу Вас обидеть или еще что, но Ваша идея (ту которую я увидел из кода) — это плохой стиль. При такой вариации, сложно делать data-driven тесты, сложно так же управлять потоками данных (представьте лапшу из if, если Ваш фреймворк будет тестировать форум с большим discretionary access control).
На самом деле, немного оффтопа, за время, которое я провел за автотестами, у меня выработался набор небольших правил:
— Композиция, никакого наследования, никаких гетеров/сеттеров, меньше тра/кетчей, все только по тай-маутам (элемент должен появиться рано или поздно, если нет — упали)
— PageObject не всегда хорош, Widget/Elements куда удобнее, особенно когда на проекте 100500 разных Drop-Down листов и не только.
— Все проверки строго по данным, которые берутся из базы/мусора/бумажки. В фреймворке только проверка перехода через страницу (деление страниц до тех пор, пока не будет уникального идентификатора). Страница должна самодостаточно себя определить, как абстрактный элемент теста: страница корзины одинакова — будет она вызвана из личного кабинета, или из айтема покупки, а вот виджеты «Добавленные покупки» уже будет другой, в таком случае в страницу Корзина я могу добавить автопроверку в конструктор при переходе на нее, и если переход состоялся куда я не ожидал (нет на страницы скажем h1 «Корзина») то я «заваливаюсь».
— Приучитесь писать run-конфигурации для тест-энвайромента: есть 100 тестов, они все разрозненны, но есть тест сьюты, которые должны проверять функциональности. Берем пачку тестов, засовываем в конфигурацию, прикрепляем в бранчу/тикету/ — готово. Это облегчает запуск, и всегда из ранее готовых тестов можно «набрать» нужную функциональность, обозвать для нее конфигурацию, и запускать.
Если касаться именно веб сервисов, то нужно разделять быстрые задачи и медленные. Вторые обычно кладутся с очередь задач и там исполняются, по окончанию пользователь может забрать результат.
Если же требуется решение в реальном времени, то задачи с недетерминированным временем в рантайм выносить нельзя. Сегодня у Вас 5000 точек, завтра будет 10к, после -1млн. Очевидно что человек, выполнивший такую операцию повесит сервер для всех.
Что касается реализации, о которой вы спросили, то лично я бы таки выносил это в очередь, и делал на concurrent futures, с очередью, что касается чистого пайтона. Если бы скорость меня не устроила, я бы написал расширение DLL/SO на С++/С и просто бы его использовал и пайтона. Возможно это не самый простой способ, ноя не люблю полагаться на сторонний код, если реализация подобного занимает немного времени.
Второй момент, я не придирался к вашей реализации, возможно в жизни она действительно хороша и эффективна, я даже не сомневаюсь в этом. Единственное что меня смутило, что Вы обозвали питон не параллельным из коробки, указали примеры на сторонних библиотеках, при этом не привели решения, который таки дает «коробочный» питон.
А можно ли на чистом Python писать на самом деле быстрый и параллельный код?
Вот с этого места.
не увидел «чистого» питона в статье, уж простите.
Возможно у нас просто разные взгляды на «чистый питон», тогда я уточню. Для меня это пайтон, который ставится из коробки и используется только функционал его встроенных модулей.
Периферии там правда… можно 5 прибором моих на одном МК сделать.
Просто мне нужен по суть MK, как числодробилка, а лучше с DSP модулем, внешней периферии посути минимум, несколько i2, i2s и дисплей не большой. Может Вы посоветуете что-то более верное?
На данный момент ковыряю stm32F407, но уже вижу что его производительности совсем впритык.
Но халявные чипы MT 6xxx конечно очень прельщают)
А насколько возможно использовать в bare-metal, процессоры ARM которые скажем стояли в средствах коммуникации? Ну вот чисто потенциально…
Ведь сами по себе они достаточно мощные, плюс aliexpress как кладезь в плане их доступности.
Вот на данный момент имею:
MT6235, MT6575, есть документация на само железо, есть u-boot — с чего так сказать начать, имею ввиду стратегически, ковырял u-boot но пока ничего интересного не нашел (по крайней мере то что вы описали)
А насчет «undefined behaviour» и различных «стреляний:
Да, на С++ очень просто выстрелить себе в ногу. Даже множеством разных способов. Но для некоторых людей это плюс. Возможность выстрелить себе в ногу предполагает возможность стрелять вообще куда-угодно, как-угодно и сколько-угодно.
Да, результаты могут быть ужасными.
Но и мощь устрашающа.
Странно быть стильно-модно-молодежным Angular разработчиком, и на слова " у тебя течет виртуальная память в приложении", пожать плечами и сказать «а что такое виртуальная память».
Язык не более чем инструмент, а при изучении, чем он проще — тем лучше.
Хочу уточнить, есть простые языки, а есть легкие. К моему мнению, простой язык, это Си: что написал — то получил, не никаких неявных состояний, каких то магических функций и других, с точки зрения прозрачности, вещей. К легким языкам, могу отнести Python. Нет избытка синтаксиса ( я не о скобочках), простая структура, некоторые стили программирования уже в коробке.
ЗЫ. Боюсь, потому что очевидно что он будет огромен. Заранее говорю, что это не попытка упрекнуть в Вашей RTOS, просто интересно.
Ну, для меня командная разработка, это писать какую то свою часть кода, при этом мне не нужно обсуждать что-либо с другим членом команды, если моя часть описана в документации (ну окей, четко выделена, имеет границы)… для других видимо, командная работа это непосредственная балабольня о том как назвать тот или иной метод, заваривание чая в одной кружке на двоих… ну вы понимаете?
Проблема в том, что понятия командная работа перешла все разумные границы (я уже не о удаленке /офисной работе), люди предпочитают болтать, рассказывать о чем то, тренировать свои ораторские навыки, ли ж бы не сесть и не написать, то что должно быть (дока/тесты/реадми файлы).
Agile Coach
ScrumMaster
Простите, кто эти люди и зачем они вобще нужны, какие реальные задачи они решают?
Еще раз повторю, если что то правильно и полно описано, это не требует обсуждений. Люди просто не умею фокусировать свои мысли и идеи. И проблема, здесь не в удаленке или отсутствии командной работы, проблема тут именно в людях и их квалификации.
Хотел добавить насчет «яндекс и гугл». Один, весьма колоритный персонаж, как то сказал «есть успешные проекты, а есть на которых красивый код» (с) А. Соловьев
ЗЫ. Притензии к карме были не к Вам лично, это скорее общий призыв.
Мне кажется, можно ограничиться тем, что статическая память известна на момент компиляции, а динамическая нет, иначе за слова «статическая память выделяется в стеке.» сейчас полетят метеориты в Ваш огород.
Звучит так, как будто для работы в команде, нужно спать в одной постели.
О какой командности вы говорите? Я должен чуять нутром что напишет Вася из соседнего отдела разработки?
Я вместо любой комадности и «двиганья листочков» выберу скорее несколько разделов ВиКи, по стилю написания кода в команде.
Я скорее предпочту тикеты на функциональность и описания на API своего модуля, нежели часовые балабольства. А знаете почему? Потому что это написано в отличии от того что можно сказать и забыть, сказать и не выполнить, сказать и потом спасая свою шкуру переиначить что либо по другому. и т.п.
Парное программирование? Да к черту его, неужели, в этом мире (компании) не найдется какого нить core-разработчика, который может посмотреть в код джуна и сказать что там не так?
ЗЫ. Не понимаю, зачем опускать и без того отрицательную карму, если Вам не нравится комментарий ставьте минус ему, аккаунт то причем, я ж Вам денег не должен…
Опять 895
Что б родители не говорили что сын разгильдяй и не доучился по профессии… просто пришел, и просто получил)))
— виджет Товар
— виджет калькулятор (общая цена зачеканных товаров)
— виджет препросмотр (ну например там фотки посмотреть)
Создаем три класса виджетов, и оперируем только входящими для них элементами, и состояниями.
Например для товара это будет, чекбокс выбора, атрибут цены. Для других все точно такое же (для калькулятора результирующая цена, для предпросмотра текущее фото, общее кол. фоток)
Уточнение: Виджетом я называю какую либо активною, порождающую сущность, иными словами, такую, которая может мне вернуть новую страницу, элементом же я называю сущности, которые работают с текущей страницей: Айтем товара, это виджет, так как он мне может вернуть страницу товара, а вот фильтр на странице каталога (по цене например) уже будет элементом, так как он изменяет лишь содержимое страницы, не меняя ее структуры
Далее вы пишите PageItemViewet класс (непосредственно PageObj, которая вам реализует работу с каталогом) и создаете композицию из предопределенных виджетов, при этом не забывая о согласовании интерфейсов между классами:
— pageobj должен сам иметь счетчик ссылок, на множества елементов (вы должны хранить ссылку на каждый товар, и только при использовании товара (выделении, проверки цены ) непосредственно пересоздавать ваш виджет.
— pageobj обязан знать, кто его вызвал, и где он находится, более того для каждого pageobj при создании необходимо проверять текущее положение в веб-приложении, я обычно проверяю в конструкторе уникальных элемент для данной страницы, как пример: при создании при переходе на страницу каталога, я смотрю на заголовок каталога, если он совпадает с тем, куда меня отправил предыдущий шаг — значит я на верной странице. данное действие избавляет от необходимости в тестах, чекать каждый чих переходов (но злоупотреблять им не следует, обычно это основные страницы (каталог, о магазине, контакты, определенный товар)
— все елементы (не активные виджеты) обязательно должны иметь автообновляемые свойства, иначе вы рискуете потерять целостность вашего состояния (вы добавили товар, спрашиваете у калькулятора какова текущая общая стоимость, он вернул 10, вы добавили еще один товар, спрашиваете у калькулятора, а теперь? — он вернул 10, очевидная ошибка, сохраненное предыдущее состояние.)
— реализация getter-ов должна быть сугубо на стороне элементов, и только они должны вам отдавать информацию со страницы. Pageobj являюется только агрегатором виджетов, и хранилищем текущего состояния теста (страницей выполнения).
Как то так. Спасибо за внимание)
Очень интересно… что вы тогда тестируете
1. Ввел креды: logtester/passtester
2. Зашел на страницу — как мне узнать под тем ли я юзером? Нужно найти метод который мне вернет юзера так? А что если таких проверок 10000, если это какая нить форма огромная?
Второй момент, Вы показали только код ваших инпутов, а теперь покажи ваши километровые трайкетчи метода submitForm() и waitForAuthPage(), ведь ошибок может быть масса — как вы их разделяете? Простой пример ошибка валидатора пароля: слишком короткий, и запрещенные символы.
В общем, не хочу Вас обидеть или еще что, но Ваша идея (ту которую я увидел из кода) — это плохой стиль. При такой вариации, сложно делать data-driven тесты, сложно так же управлять потоками данных (представьте лапшу из if, если Ваш фреймворк будет тестировать форум с большим discretionary access control).
На самом деле, немного оффтопа, за время, которое я провел за автотестами, у меня выработался набор небольших правил:
— Композиция, никакого наследования, никаких гетеров/сеттеров, меньше тра/кетчей, все только по тай-маутам (элемент должен появиться рано или поздно, если нет — упали)
— PageObject не всегда хорош, Widget/Elements куда удобнее, особенно когда на проекте 100500 разных Drop-Down листов и не только.
— Все проверки строго по данным, которые берутся из базы/мусора/бумажки. В фреймворке только проверка перехода через страницу (деление страниц до тех пор, пока не будет уникального идентификатора). Страница должна самодостаточно себя определить, как абстрактный элемент теста: страница корзины одинакова — будет она вызвана из личного кабинета, или из айтема покупки, а вот виджеты «Добавленные покупки» уже будет другой, в таком случае в страницу Корзина я могу добавить автопроверку в конструктор при переходе на нее, и если переход состоялся куда я не ожидал (нет на страницы скажем h1 «Корзина») то я «заваливаюсь».
— Приучитесь писать run-конфигурации для тест-энвайромента: есть 100 тестов, они все разрозненны, но есть тест сьюты, которые должны проверять функциональности. Берем пачку тестов, засовываем в конфигурацию, прикрепляем в бранчу/тикету/ — готово. Это облегчает запуск, и всегда из ранее готовых тестов можно «набрать» нужную функциональность, обозвать для нее конфигурацию, и запускать.
Если же требуется решение в реальном времени, то задачи с недетерминированным временем в рантайм выносить нельзя. Сегодня у Вас 5000 точек, завтра будет 10к, после -1млн. Очевидно что человек, выполнивший такую операцию повесит сервер для всех.
Что касается реализации, о которой вы спросили, то лично я бы таки выносил это в очередь, и делал на concurrent futures, с очередью, что касается чистого пайтона. Если бы скорость меня не устроила, я бы написал расширение DLL/SO на С++/С и просто бы его использовал и пайтона. Возможно это не самый простой способ, ноя не люблю полагаться на сторонний код, если реализация подобного занимает немного времени.
Второй момент, я не придирался к вашей реализации, возможно в жизни она действительно хороша и эффективна, я даже не сомневаюсь в этом. Единственное что меня смутило, что Вы обозвали питон не параллельным из коробки, указали примеры на сторонних библиотеках, при этом не привели решения, который таки дает «коробочный» питон.
Вот с этого места.
не увидел «чистого» питона в статье, уж простите.
Возможно у нас просто разные взгляды на «чистый питон», тогда я уточню. Для меня это пайтон, который ставится из коробки и используется только функционал его встроенных модулей.