Код мало того что не "хорошо оптимизирован", он вообще написан ужасно с точки зрения производительности. Одно и тоже вычисляется в цикле несколько раз и т.д. и т.п.
Не нужно использовать циклы для работы с матрицами. Все современные процессоры давно поддерживают Advanced Vector Extensions, которые позволяют существенно ускорить работу с матрицами.
Если уж в статье упоминается про NumPy, то именно её и надо было использовать для вычислений. Под капотом она использует высокооптимизированный код, написанный на C, и, насколько я знаю, используется тот самый AVX. Все можно было свести к паре строчек кода и работало бы оно максимум раз в 10-15 медленее чем на видеокарте.
Ну и как написали выше, есть более быстрые алгоритмы.
Хочу вас расстроить, но любой опытный коптеростроитель соберет такой коптер за один день при условии наличия всех комплектующих и использования готового полетного контроллера. И да, у меня есть свой коптер. Другое дело если делать свой полетный контроллер, но зачем изобретать велосипед.
На самом деле все не так плохо. Я сам закончил институт ~3.5 года назад. И могу с уверенностью сказать что более-менее головастые из нашей группы на 4 — 5 курсе уже имели полную/частичную занятость. И после получения диплома просто отнесли его своему работодателю. Если вам нужны по настоящему головастые ребята, то нужно искать их среди студентов 3 — 4 курсов. Звать их к себе на практику/подработку. Как-то так.
Пользуюсь ExtJS уже около трех лет. Не могу не ответить на Ваш пост.
При подключении страницы в браузер грузится около 6 мегабайтов всякого добра и это время весьма и весьма заметно.
Вы, случайно, не ext-all-debug-w-comments.js используете? Иначе я не могу могу понять откуда у Вас такой объем данных. Глянул на свой достаточно большой проект на ExtJS, в котором кроме него еще используется OpenLayers + HighCharts. Всего 2 мегабайта получилось.
Учить ExtJS жутко трудно. Она огромная, непонятно с чего начинать. Учебники и книжки в основном относятся к третьей версии, а она, в свою очередь, мало похожа на версию 4, в которой почти все сделано по-другому. По этой же причине почти бесполезны форумы, ибо все, что там написано, давно устарело.
Либо у Вас совсем плохо с английским, либо Вы очень плохо искали: docs.sencha.com/ext-js/4-1/#!/guide/getting_started. Достаточно большой объем информации, которого вполне достаточно чтобы понять что к чему. Плюс куча готовых примеров.
Стыдно сказать, но я банальное приложение писал с нуля почти неделю, страдая при этом резкими перепадами настроения. Мне все время хотелось биться головой об стену — непонятно было абсолютно все. Ни одну технологию я с такими страданиями не учил.
Попробуйте написать какой-нибудь простенький компонент из ExtJS на чистом JavaScript, да так, чтобы оно во всех браузерах работало. Вот тут я думаю будет повод биться об стену.
В 4 версии ваше приложение должно быть сделано по принципу MVC. На практике это означает, что даже hello world будет состоять из десятка файлов, разложенных по нескольким разным каталогам. И прежде чем приступить к программированию любой задачи, эти файлы надо будет создать и разложить.
Ну во первых ваше приложение никому и ничего не должно. Вы можете написать его точно так же как и в третьей версии. Вот только когда оно разрастется будет очень грустно. Про десяток файлов, думаю вы тоже преувеличили: app.html, app.js, контроллер и представление.
С данными тоже не все благополучно. Хранилище предполагает, что все данные всегда совершенно однородны. Можно, правда, описывать какие-то вложенные сущности на манер «один ко многим», но эти дополнительные данные только читаются — записать их нельзя, что делает всю затею бесполезной.
В ExtJS есть связи 1 к 1 и 1 ко многим. С записью там тоже все порядке. Нужно только правильно связать модели и указать для них прокси.
Описание интерфейса — это нечто. Он описывается чисто декларативно — и это плюс. Но как он описывается, господи. С помощью декларации данных Яваскрипта — а видов данных там немного, массивы да хеши. Поэтому любой экран, всего с парой контролов, — это длиннющая портянка декларативного кода, со структурами, многократно вложенными друг в друга.
Помню на первом курсе института писали GUI приложение на Assembler'е под Windows. Вот там было «Но как он описывается, господи.» А для ExtJS есть Sencha Architect, в котором можно очень быстро накидать любую формочку и т.д. При условии, что Вы умеете работать с менеджерами расположения.
Поэтому любое изменение интерфейса или кода, даже исправление грамматической ошибки, обязательно предполагает долгий розыск того места, где, собственно надо править.
Возможно Вам нужно дробить вьюшки на более мелкие компоненты? Когда я делаю какую-то формочку или какой-то грид, то я просто создаю новый компонент, который наследую от Ext.grid.Panel или Ext.form.Panel и т.д. и ложу в отдельный файл. Да и к тому же если в приложении нужно одну и ту же фомочку заюзать в несколких местах, достаточно добавить
requires: ['MyApplication.view.MyForm']
и в нужном месте вставить
{
xtype: 'myform'
}
В библиотеке есть ошибки. Не очень много, но есть. Однако из-за общей сложности они превращаются в кошмар — их невозможно никак исправить. Непонятно, от чего они происходят, непонятно, что надо изменить, непонятно, вообще в чем дело.
Пожалуй единственный абзац, с которым можно согласиться и то не полостью. Ошибки есть. Не всегда быстро удается выявить причину. Но вот с правкой особых проблем нет. Всегда можно написать какой-нибудь override для стандартного компонента. Вот с обновлением на новую версию все гораздо печальнее.
Или пишут тебе пользователи — у нас не грузится таблица. Открываешь — и правда, не грузится. Вчера грузилась, а сегодня нет, притом, что в этом месте ты ничего не менял.
Если что-то где-то сломалось, значит все-таки что-то где-то изменилось.
В целом мне кажется, что статья очень субъективная. Я не являюсь фанатом этого фреймворка, и не берусь его защищать, но мне кажется что с задачами, для которых он создан, он справляется весьма успешно.
Я надеюсь вы осветите эти вопросы? Просто сейчас сам занимаюсь написанием своей прошивки для коптера. Ради того чтобы понять как оно работает. Пока-что застрял на стабилизации полета с использованием 4-х датчиков (акселерометр + гироскоп + магнетометр + барометр). Надеюсь у меня хватит терпения и времени разобраться в этом)
Такое начало статьи… Я уже думал вы своими руками соберете бесколлекторный двигатель, регулятор хода, плату стабилизации полета и напишете свою прошивку для коптера. А тут… Обычная статья про коптер каких много.
Интересно, как устроены двигатели, с помощью которых смогли доставить марсоход на такое расстояние? Это обычные двигатели, с помощью которых выводят спутники на орбиту, или там что-то принципиально другое? Все-таки полет длился более 7 месяцев и все это время двигатели должны были работать или достаточно разогнать ракету и она будет двигаться по инерции? В общем хотелось бы узнать от разбирающихся…
Показательная статья как делать не надо.
Код мало того что не "хорошо оптимизирован", он вообще написан ужасно с точки зрения производительности. Одно и тоже вычисляется в цикле несколько раз и т.д. и т.п.
Не нужно использовать циклы для работы с матрицами. Все современные процессоры давно поддерживают Advanced Vector Extensions, которые позволяют существенно ускорить работу с матрицами.
Если уж в статье упоминается про NumPy, то именно её и надо было использовать для вычислений. Под капотом она использует высокооптимизированный код, написанный на C, и, насколько я знаю, используется тот самый AVX. Все можно было свести к паре строчек кода и работало бы оно максимум раз в 10-15 медленее чем на видеокарте.
Ну и как написали выше, есть более быстрые алгоритмы.
-
Меня вообще удивляет как они так быстро порыли 3 километра. В Омске за 26 лет прорыли 7.5 км.
Хочу вас расстроить, но любой опытный коптеростроитель соберет такой коптер за один день при условии наличия всех комплектующих и использования готового полетного контроллера. И да, у меня есть свой коптер. Другое дело если делать свой полетный контроллер, но зачем изобретать велосипед.
Тогда понятно в чем дело. Потенциал для разгона огромен.
Вы, случайно, не ext-all-debug-w-comments.js используете? Иначе я не могу могу понять откуда у Вас такой объем данных. Глянул на свой достаточно большой проект на ExtJS, в котором кроме него еще используется OpenLayers + HighCharts. Всего 2 мегабайта получилось.
Либо у Вас совсем плохо с английским, либо Вы очень плохо искали: docs.sencha.com/ext-js/4-1/#!/guide/getting_started. Достаточно большой объем информации, которого вполне достаточно чтобы понять что к чему. Плюс куча готовых примеров.
Попробуйте написать какой-нибудь простенький компонент из ExtJS на чистом JavaScript, да так, чтобы оно во всех браузерах работало. Вот тут я думаю будет повод биться об стену.
Ну во первых ваше приложение никому и ничего не должно. Вы можете написать его точно так же как и в третьей версии. Вот только когда оно разрастется будет очень грустно. Про десяток файлов, думаю вы тоже преувеличили: app.html, app.js, контроллер и представление.
В ExtJS есть связи 1 к 1 и 1 ко многим. С записью там тоже все порядке. Нужно только правильно связать модели и указать для них прокси.
Помню на первом курсе института писали GUI приложение на Assembler'е под Windows. Вот там было «Но как он описывается, господи.» А для ExtJS есть Sencha Architect, в котором можно очень быстро накидать любую формочку и т.д. При условии, что Вы умеете работать с менеджерами расположения.
Возможно Вам нужно дробить вьюшки на более мелкие компоненты? Когда я делаю какую-то формочку или какой-то грид, то я просто создаю новый компонент, который наследую от Ext.grid.Panel или Ext.form.Panel и т.д. и ложу в отдельный файл. Да и к тому же если в приложении нужно одну и ту же фомочку заюзать в несколких местах, достаточно добавить
requires: ['MyApplication.view.MyForm']и в нужном месте вставить
{ xtype: 'myform' }Пожалуй единственный абзац, с которым можно согласиться и то не полостью. Ошибки есть. Не всегда быстро удается выявить причину. Но вот с правкой особых проблем нет. Всегда можно написать какой-нибудь override для стандартного компонента. Вот с обновлением на новую версию все гораздо печальнее.
Если что-то где-то сломалось, значит все-таки что-то где-то изменилось.
В целом мне кажется, что статья очень субъективная. Я не являюсь фанатом этого фреймворка, и не берусь его защищать, но мне кажется что с задачами, для которых он создан, он справляется весьма успешно.
www.ebay.com/itm/Arduino-Ultrasonic-module-HC-SR04-distance-measuring-transducer-sensor-NEW-/270946503533?pt=LH_DefaultDomain_0&hash=item3f15ab8b6d