Найдены возможные дубликаты

+3

Сколько можно-то баянить?

раскрыть ветку 1
+2
Иллюстрация к комментарию
+2

Было же:

https://pikabu.ru/story/cats_logic_6358918?f=1#comments

а самый рейтинговый коммент = этот пост.

раскрыть ветку 4
0

Блииин... Позор.
@moderator, свой пост стереть у меня не получается, прошу занести в протокол в "баяны". Спасибо.

раскрыть ветку 3
+1

Ну это же как скриншот комментария. Поста с таким смыслом и фото не было же :)

0
Комментарий удален. Причина: данный аккаунт был удалён
раскрыть ветку 1
+3

Ну так разделительные стенки же не построили, кто ТЗ писал?

Похожие посты
2130

2 года разработки - AIWM Hexapod

Два года разработки с 0, вот прям с чистого чертежа в КОМПАС 3Д. Всю электронику, прошивку, программу управления, механику, математику и дизайн - всё сам и всё с нуля. Наконец-то я сделал это - проект достиг версии 1.00. Не буду голословным, результат работы показан на видео. Надеюсь всем понравится :)

Вот тут можно узнать о ходе разработки подробнее. Там есть ссылки на различные этапы разработки.

https://habr.com/ru/post/493304/

34

Blueprints и C++ в Unreal Engine: плюсы и минусы

Epic Games последовательно развивает систему визуального программирования Blueprints в Unreal Engine. Она продвигается как полноценная рабочая среда, в которой любой новичок может освоиться и собрать свою игру. Но действительно ли «блюпринты» ни в чём не уступают классическому программированию?


Александр Балакшин, программист AAA-игр, внёсший значительный вклад в разработку сезонных обновлений для Tom Clancy’s Rainbow Six Siege в роли старшего инженера-разработчика и лида геймплейной команды, разбирает плюсы и минусы Blueprints и объясняет её отличия от «чистого» C++.


Автор: Александр Балакшин

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Источник


Блюпринты выигрывают у C++ на начальных этапах разработки, особенно если код игры пишется с нуля. Они не требуют установки дополнительной среды, к тому же предлагают быстрые итерации. А блочный синтаксис блюпринтов понятен не только программистам, но и тем, кто знаком с аналогичными системами в программах для создания контента — например, художникам.


Но если рассматривать разработку игры в целом, в долгосрочной перспективе, то классический подход к программированию показывает свои преимущества. Даже сами Epic Games заостряют внимание на том, что блюпринты — это не код, а данные, поэтому и относиться к ним нужно соответственно. Например, некоторая общая логика всё равно должна выноситься в код.

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Источник


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


Наконец, блюпринты бьют по производительности, так как компилируются в байт-код, который работает на встроенной в движок виртуальной машине. Да, их можно нативизировать, — то есть преобразовать Blueprint-логику в файлы C++, но даже разработчики из Epic рекомендуют этим не злоупотреблять.


Да и с точки зрения GOMS-анализа нажатие на клавишу клавиатуры оказывается быстрее, чем перемещение мышки. Это ни в коем случае не отменяет удобство визуального редактора, но, по моему опыту, с автодополнениями и прочими синтаксическими функциями современных IDE писать код удобнее и быстрее, чем создавать граф в блюпринтах. Хотя полезные сочетания клавиш и шорткаты в Unreal Engine тоже облегчают жизнь.

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Источник


Я считаю, что если программисту нужно работать с Tick-функциями, или он использует какую-то сложную математику и пространственные запросы (например, LineTrace), всё это лучше вынести в С++. Отчасти из-за всех перечисленных особенностей Epic Games раздумывают над созданием отдельного скриптового языка для реализации игровой логики в Unreal Engine.


Тем не менее, блюпринты — достаточно мощный инструмент, который в Unreal Engine 4 используется не только для построения игровой логики, но и для работы с анимацией и системой эффектов Niagara. Поэтому каждая студия должна сама найти подходящий баланс между Blueprints и С++. Например, технические дизайнеры Riot Games использовали блюпринты в Valorant только для создания способностей игроков.

Blueprints и C++ в Unreal Engine: плюсы и минусы Xyz, Программирование, Unreal Engine 4, Gamedev, Разработка, Разработчики игр, Длиннопост

Valorant


Сами Epic Games рекомендуют использовать блюпринты, когда в проекте очень много ссылок на контент, а его логика работает в первую очередь на визуальную составляющую. Также они пригодятся в создании прототипов, прямолинейной или редко используемой логики, которая не является частью основной архитектуры. Всё, что не получит преимуществ в С++ с точки зрения производительности, масштабируемости и стабильности, тоже может быть создано в Blueprints.


Ну а с С++ лучше работать, если функционал используется более чем в одном месте и включает в себя сложные элементы — например, сохранение игр или сетевой код. Если проект в дальнейшем будет расширяться, то его тоже лучше создавать с помощью классического программирования — оно помогает тщательно поддерживать логику и стабильность кода.


Словом, с любыми важными переменными, перечислениями и типами данных C++ работает лучше. Но и работа в Blueprints не отменяет классический подход, а только органично дополняет его в необходимых случаях. Так что разработчикам от визуального программирования никуда не деться.

Показать полностью 3
1245

Когда потомки увидят твой говнокод

Когда потомки увидят твой говнокод Картинки, Юмор, Программирование, Разработка, Github, IT юмор

Перевод:
"Загрязнение Арктики - это серьезная проблема"
Я, после того как мой говнокод поместили в арктическое хранилище

Компания GitHub рассказала в своем блоге, что 8 июля 2020 года архив открытых исходных кодов сервиса был успешно размещен в арктическом хранилище Arctic World Archive на острове Шпицберген.

Чтобы заархивировать и перевести на физических носителях весь GitHub понадобилось более пяти месяцев кропотливой работы. 2 февраля 2020 года специалисты компании сделали копию всего открытого исходного кода, хранившегося на сервисе — это вклад работы более 37 миллионов пользователей, который включает около 100 миллионов активных публичных репозиториев.

Ссылка на новость - https://habr.com/ru/news/t/511402/

31

Тесты ПУЭ на Xamarin

Не так давно я опубликовал пару постов о приложениях для подготовки к тестированию по электробезопасности. Это простые одностраничные приложения в которых крутятся вопросы по электробезопасности. На странице показывается вопрос и несколько вариантов ответа. Пользователь жмёт в выбранный им вариант. Правильный ответ показывается сразу после выбора варианта ответа. Приложение написано на Xamarin, поэтому среди прочих тегов присутствовали Xamarin и CSharp. Но, как справедливо заметили в комментариях, о Xamarin не было ничего. Исправляюсь.

Ссылки на посты:

Запилил тесты ПУЭ

Выкатил вопросы на 5 группу электробезопасности

Решение на XamarinForms содержит несколько проектов. Главный проект и проекты для каждой выбранной на этапе создания решения платформы.

Здесь была выбрана только одна платформа, поэтому решения два.

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Каждый вопрос с вариантами ответов хранится в классе QuestCase.

Переменная errors - счётчик до выхода вопроса из списка чаще показываемых вопросов. Когда происходит неправильный ответ, errors становится 5. С каждым правильным ответом errors уменьшается на 1. Когда errors становится 0, вопрос исключается из списка чаще показываемых.

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Интерфейс IFileWorker нужен для работы с файлом вопросов/ответов.

Этот интерфейс описан в главном проекте

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

а реализован в проекте для Android в классе FileWorker.

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

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Текст каждого ответа размещается в MyLabel наследованном от Label.

MyLabel знает какой ответ в нем - верный или неверный - свойство isAnswer,

MyLabel запоминает клик по нему - свойство isClicked.

Я использовал BindableProperty для реализации этих свойств.

Тесты ПУЭ на Xamarin Xamarin, Csharp, Программирование, Приложение на Android, Разработка, Длиннопост

Это первая часть поста. Планирую ещё как минимум две.

Показать полностью 5
465

Проект «Качок»

Поступил от одной фирмы заказ. Нужно было разработать мозги для электрической помпы, которую они проектировали. Предназначалась эта штука для проверки датчиков давления в полевых условиях. Собственно, помпа уже была. Ручная. Но, оказалось, что, для того, чтобы накачать 40 атмосфер вручную, нужно быть качком. Качки среди тетенек-метрологов — редкость. Следовательно, ручной труд нужно было срочно механизировать!


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

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

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


По идее, схему сначала как-то прототипируют, пишут софт, а уже потом разводят плату. Но, можно сделать наоборот. В данном случае, схемотехника была примерно понятна. Есть готовый драйвер коллекторного двигателя. Есть контроллер, функционал которого, в любом случае, задается софтом. А это позволяет подключать его ноги практически произвольно. Есть цепи питания и всякой периферии. Проще, сразу развести всё на плате, чем делать двойную работу, собирая на проводках похабную макетку.


Плату буду делать в EagleCAD.


Платка была мелкая, в ограничение демоверсии влезала легко. Первым делом, решил нарисовать цепь питания. Контроллер потребляет мало. Значит, хватит обычного линейного стабилизатора. Делаем ему обвязку из конденсаторов на входе и выходе. Не забываем зашунтировать электролиты керамикой, а то у них огромная индуктивность, и наносекундные импульсы они почти не фильтруют.Так… А чем включать? Актуатор жрёт довольно неслабый ток. А заказчик дал нам гламурную кнопочку, чтоб было красиво. Что делать? Будем усиливать. В разрыв цепи ставится Р-канальный мосфет, который открывается кнопкой. Современные транзисторы могут схавать дикие токи при очень мелких габаритах. Заодно, получаем халявную защиту от переполюсовки.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Чтобы совсем не запутаться, разводим часть платы. Переходим в трассировщик, и ужасаемся. Первое ощущение — ступор и паника. На экране девственно пустая плата. В углу, кучкой, навалены детали, а между ними ктулхическое переплетение соединений. Спутанные наушники видели? А теперь, представьте, что их полный рюкзак.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

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


Перехожу обратно к схеме. Впихиваю контроллер. И сразу разъем для программирования. Надо, чтобы чип прошивался прямо на плате. Шить их перед запайкой было бы ни разу не технологично. Рисуем разъемы под кнопки и светодиод индикации. Добавляем делитель напряжения, чтобы измерять, что у нас там по питанию. И, обязательно, гнусную пищалку!

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Снова разводим дорожки. Выясняется, что разъем для программатора впихивается ужасно неудобно. Сейчас бы двустороннюю разводку! Но, прототип решили делать односторонним. Все равно, потом допиливать. Наконец, с помощью такой то матери удается все красиво скомпоновать.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

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


Здравый смысл за то, чтобы взять его как есть. Тем более это будет выставочный образец, да и если и серия, то небольшая. Десятки штук. Так что модуль будет вполне оптимален.

Разумеется, модуля в библиотеке EagleCAD нет. Придется рисовать.


Задаем условное обозначение на схеме. Перерисовываем плату, стараясь не ошибиться с габаритами. Игл радует тем ,что координаты начал и концов можно прям цифрами вносить в свойства линий. И не надо ничего подгадывать и считать клеточки. Затем вбиваем соответствие ног на схеме и на плате. Готово!


Впихиваем модуль на плату. Важно правильно развести силовые цепи. Если пустить землю одной линией, то модуль будет создавать помехи контроллеру. Дело в том, что дорожки отнюдь не сверхпроводящие, и при большом токе через земляную линию между её участками может получится неслабый потенциал. Чтобы этого не было, ведем силовую землю прям от источника питания.


Еще несколько штрихов. Разглядываю плату. Правлю мелкие косяки. Кажись, можно воплощать в железе.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

жЫрно печатаю маску с дорожками на бумаге. Через неё мы будем засвечивать фоторезист!

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Если посмотреть бумагу на просвет, видно, что тонер закрашивает её недостаточно плотно. Это плохо. Скорее всего, через такую маску засветится что не надо, и будет брак. На этот случай есть специальная жижа, которая вызывает набухание тонера и его уплотнение. Зовется она Density Toner и купить ее можно в фирмах продающи расходники для типографий. Рублей 400 за баллон стоит, хватает очень надолго. Еще можно шаблон подержать в парах ацетона, от них тонер тоже набухает знатно.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Фоторезист выглядит как тонкая пленка. Её накатывают на плату, засвечивают через маску, и смывают. Там, где на неё воздействовал ультрафиолет, она стабилизируется и так просто уже не смывается. В результате, у нас получается рисунок дорожек.


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

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Фоторезист засвечен и смыт проявителем. Остается протравить плату в хлорном железе.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Полчаса ожидания, и плата готова. Быстро запаиваю все детали. Результат мне нравится. Физически это уже готовое изделие, но без прошивки — труп.

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

Шел второй час кодинга. Устремив взор в белое безмолвие монитора я пытался разобраться с регистрами незнакомого мне ранее контроллера. В какой-то момент мне захотелось бросить всё, и написать программу на Ардуино… Я обернулся. Ди Хальт смотрел на меня, и с укоризной во взгляде правил лезвие своего кукри, как бы намекая, что не стоит его разочаровывать.


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


У контроллера нет никакой многозадачности. По кругу выполняется одна единственная программа, в которой и происходит всё интересное. Чтобы многозадачности, все таки, добиться, есть особые приемы. В первую очередь, прерывания.


Прерывания — это особые события, на которые контроллер отвлекается и быстро выполняет куски кода, возвращаясь потом к основной программе. Допустим, прилетел байт в UART. Надо скопировать его в какой-нибудь буфер. Ждать нельзя, а то прилетит следующий, вытолкает из регистра тот, что был, и мы его потеряем. А вот если вынести код, пихающий байты в буфер, в прерывание, то в момент прихода байта контроллер будет его быстренько сохранять, почти не тормозя выполнение основной программы.


Так вот. Я благодарен Ди Хальту, за то, что он сразу заставил меня писать на чистом Си. Начинающие ардуинщики обычно не умеют в прерывания. Так и случилось. В той проге, что написали заказчики, крутился основной цикл. В нем была куча задержек. Они нужны, так как, контроллер тикает миллионы раз в секунду, а переходные процессы в кнопках и датчиках происходят намного медленнее, и на полной скорости он будет ловить кучу ошибок.


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


Пока программа прокручивала цикл с задержками, контроллер безответственно профукивал бросок тока. Уменьшить задержки? Тоже плохо.


Вообще, ардуино не запрещает делать все на прерываниях. Проблем тут две.


Первая — обычно, те, кто учится прогать на ардуино, не копают глубоко. Они просто не знают, что вообще бывают прерывания, регистры, и все такое. Бабуино — это такой особый путь.


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


(Ну ну, я тут расхвастался зря. Я очень начинающий разработчик, и нифига не умею. Проект то простой. В то время, как есть те, кто делает на ардуино вещи гораздо более крутые. Но, это как раз люди, знающие архитектуру контроллера и копающие глубоко. Ну, или грамотное использование библиотек, написанных такими людьми.)


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


По току на движке можно понять, что происходит. Чем сильнее нагружаешь двигатель, тем больше он жрет. Заклинило, уперся в стенку — ток будет максимальным. Значит, ориентируясь по току, легко можно сделать автоматику как у дверей лифта, которые, если что-то не дает закрыться, отходят обратно.


АЦП контроллера тикает с определенной частотой. Как только он померял, что на него приходит, он выдает прерывание. Вот в это прерывание я и засунул кусок кода, отвечающий за измерение тока. Туда же засунул измерение напряжения питания. Сварганив простенький конечный автомат. Пригодится.


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

Теперь нужно было разобраться с кнопками. У нас целых три таймера. Их можно заставить выполнять что-то в прерывании, в то время, как основной цикл занят своими делами.


Заказчик хотел две сенсорные кнопки. Одна должна включать привод, пока на нее давишь. Вторая включать и выключать.


С первой все совсем просто. Кнопка нажата — есть флаг разрешения работать. Основной цикл врубает движок. Нет — вырубает.


Со второй все чуть сложнее. Простейшее решение, сделать так, чтобы нажатие кнопки инвертировало какой-то флаг. Тычешь один раз — он сменяется с «выкл» на «вкл». Еще раз — наоборот.


Работать это будет. Но, криво. С ложными срабатываниями. Чтобы всё было идеально четко, нужно реализовать конечный автомат. В общем, логику как у авторучки с кнопкой. Нажимаешь один раз, алгоритм поднимает флаг, и переключается в следующее состояние, в котором ждет отпускания кнопки. Нажимаешь второй — флаг сбрасывается, и программа снова ждет отпускания. При этом, нажатие кнопки срабатывает четко, и её не трясет как от болезни Паркинсона.


Кстати, о тряске. У механических кнопок контакт замыкается не сразу. Какие-то миллисекунды он дребезжит. Контроллер быстрый, и успевает принять это за кучу нажатий подряд. На этот случай можно ввести итератор, который будет переключать конечный автомат с следующее состояние только если несколько циклов подряд состояние кнопки не будет меняться.

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


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


Загружаем код в контроллер. Подаем питание. РАБОТАЕТ!!!

Проект «Качок» Разработка, Контроллер, Компрессор, Длиннопост, Программирование

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


Настало время допиливания. Первым делом надо было как то нагрузить актуатор, чтобы понять насколько адекватно у нас идет измерение тока. Ведь от тока зависел и момент. Ага, легко сказать. У него усилие в несколько сот килограмм. И я, даже навалившись на него всем весом, не смог бы создать сколь-нибудь ощутимой нагрузки. Ди посмотрел на это, схватил нож и куда то убежал. Вернулся через пять минут с обрезком толстого резиного шланга, сантиметров на 10. Я даже думать не хочу у кого он его отрезал. Натянули шланг на шток актуатора, на манер крайней плоти. Осталось только воткнуть отвертку в отверстие на конце штока, чтобы шлангу не куда было деваться и попробовать его сжать. Сопротивление кусок резины оказал достойное, удалось даже заклинить актуатор, выведя его на максимальную нагрузку.


Нагрузка есть, первым делом, я решил откалибровать датчик тока. Ноги UARTа очень удачно оказались на разъеме, к которому должен цепляться светодиод. Ничто не мешало врубить его в режиме отладки, и подключиться к компу.


Оказалось, что сигнал довольно зашумлен. График слегка колбасило.


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


Шумы исчезли, осталась только плавная линия, рисующая график того, как мы нагрузили двигло.


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


Допилил еще кучу мелочей. Результат мне уже нравился. В какой-то момент, стало ясно, что он соответствует техзаданию, а в чем-то его даже превосходит.


Настало время суровых испытаний.


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


Оно заработало.


И тут выяснилось, что есть одна проблема. Помпа работает как с воздухом, так и с жидкостью. Воздух сжимается. Качать его нужно долго. Жидкость же накачивается до нужного давления буквально мгновенно.


Так вот. Движок давит со всей дури. И пока сработает защита по току (у нас же кольцевой буфер с интеграцией, и заполняется он не сразу), он успевает накачать слишком много.

Уменьшить буфер? Система начинает реагировать на пусковой ток, как на превышение нагрузки.

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


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


Мне представилась пирамида из костылей. Ага. Нужно построить зиккурат.


И тут…


Это похоже на луч света, внезапно озаривший пасмурное небо. Инсайт! Я дописал одну… Всего одну строчку кода! И двигатель стал плавно разгоняться ШИМом, и развивать строго определенное усилие.


При этом, в программе никакой плавной регуляции не было. Никаких таймеров с ШИМ выходом. Никаких циклов, медленно добавляющих ток двигателю. Ничего.


Просто, в прерывание АЦП я добавил строку, которая, если ток становился больше определенного, отключала его до следующей итерации. И этого оказалось достаточно. АЦП тикает с довольно высокой частотой. Значит, он, совершенно естественным образом будет обрезать большой пусковой ток, автоматически создавая ШИМ с нужной скважностью. А индуктивность двигателя его сгладит. Если же движок упрется в препятствие, его усилие, так же, будет ограниченно заданным током.


А что с реверсом по превышению тока? А он никуда не делся. Пока ШИМ ограничивает пиковый ток, кольцевой буфер заполняется его значениями. И, как только, среднее арифметическое станет больше заданной величины, сработает реверс.


Решение оказалось настолько простым и изящным, что я не мог поверить. А что, так можно было?!


Оказалось, да.


Устройство уехало на выставку.


Функциональный прототип готов. Впереди допиливание, ресурсные испытания, ловля оставшихся багов, и, если повезет, предсерийный образец.


Источник

Показать полностью 11
40

Что находится между идеей и кодом? Обзор 14 диаграмм UML

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Аве Кодер! Тебе пришла крутая идея продукта, но ты не хочешь увязнуть в коде и потерять целостную картинку из-за мелких деталей? Ты вот-вот присядешь за то, что крякнул корпоративный сервер и тебе нужно набить что-то крутое и айтишное?


UML, как мы знаем, является стандартизированным языком моделирования, состоящим из интегрированного набора диаграмм, разработанных, чтобы помочь разработчикам систем и программного обеспечения в определении, визуализации, конструировании и документировании артефактов программных систем, а также, к примеру, для бизнес-моделирования.


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


UML использует в основном графические обозначения, чтобы выразить дизайн программных проектов. Использование UML помогает проектным группам общаться, изучать потенциальные проекты и проверять архитектурный дизайн программного обеспечения.


Для тех, кому лень читать и кто предпочитает смотреть и слушать: https://youtu.be/0I9aIP5gKCg


Основные цели дизайна UML:

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

Обеспечить механизмы расширяемости и специализации для расширения основных понятий.

Быть независимым от конкретных языков программирования и процессов разработки.

Обеспечить формальную основу для понимания языка моделирования.

Поощрять рост рынка объектно-ориентированных инструментов.

Поддержка высокоуровневых концепций разработки, таких как совместная работа, структуры, шаблоны и компоненты.

Интегрировать лучшие практики.


Диаграммы UML подразделяют на два типа - это структурные диаграммы и диаграммы поведения.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

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


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


Теперь пару слов о каждой из них


Диаграмма классов

https://youtu.be/sVVJp5a41o4


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


Три наиболее важных типа отношений в диаграммах классов (на самом деле их больше), это:

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

-- Наследование, которое имеет непосредственное соответствие наследованию в Объектно-Ориентированном дизайне.

-- Агрегация, которая представляет из себя форму композиции объектов в объектно-ориентированном дизайне.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма компонентов

https://youtu.be/OiVyha3sf_I


На языке унифицированного моделирования диаграмма компонентов показывает, как компоненты соединяются вместе для формирования более крупных компонентов или программных систем.


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

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма развертывания

https://youtu.be/Yz8phtJoP7I


Диаграмма развертывания помогает моделировать физический аспект объектно-ориентированной программной системы. Это структурная схема, которая показывает архитектуру системы, как развертывание (дистрибуции) программных артефактов.

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


Диаграмма моделирует конфигурацию времени выполнения в статическом представлении и визуализирует распределение артефактов в приложении.

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма объектов

https://youtu.be/tVW5oHNfAvc


Статическая диаграмма объектов является экземпляром диаграммы класса; она показывает снимок подробного состояния системы в определенный момент времени. Разница в том, что диаграмма классов представляет собой абстрактную модель, состоящую из классов и их отношений.

Тем не менее, диаграмма объекта представляет собой экземпляр в конкретный момент, который имеет конкретный характер.Использование диаграмм объектов довольно ограничено, а именно - чтобы показать примеры структуры данных.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма пакетов

https://youtu.be/237BWanM4Ak


Диаграмма пакетов - это структурная схема UML, которая показывает пакеты и зависимости между ними.

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма составной структуры

https://youtu.be/nsuJcMNaKeE


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


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма профилей

https://youtu.be/qBws7AfvDL8


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма прецедентов

https://youtu.be/BdAcxboG5No


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

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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма деятельности

https://youtu.be/Z8PHBsNXAgc


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

Они описывают поток управления целевой системой, такой как исследование сложных бизнес-правил и операций, а также описание прецедентов и бизнес-процессов.

В UML диаграммы деятельности предназначены для моделирования как вычислительных, так и организационных процессов.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма состояний

https://youtu.be/ojCcUvGfpi8


Диаграмма состояний - это тип диаграммы, используемый в UML для описания поведения систем, который основан на концепции диаграмм состояний Дэвида Харела. Диаграммы состояний отображают разрешенные состояния и переходы, а также события, которые влияют на эти переходы. Она помогает визуализировать весь жизненный цикл объектов и, таким образом, помогает лучше понять системы, основанные на состоянии.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма последовательности

https://youtu.be/ycg3njrkk1c


Диаграмма последовательности моделирует взаимодействие объектов на основе временной последовательности. Она показывает, как одни объекты взаимодействуют с другими в конкретном прецеденте.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма Коммуникации

https://youtu.be/KVLJj9xOq0E


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Диаграмма обзора взаимодействия

https://youtu.be/E0OJG8ojEAg


Диаграмма обзора взаимодействий фокусируется на обзоре потока управления взаимодействиями. Это вариант Диаграммы деятельности, где узлами являются взаимодействия или события взаимодействия. Диаграмма обзора взаимодействий описывает взаимодействия, в которых сообщения и линии жизни скрыты. Мы можем связать «реальные» диаграммы и добиться высокой степени навигации между диаграммами внутри диаграммы обзора взаимодействия.

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Временная диаграмма

https://youtu.be/NKTyDQUkLoM


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма
Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

Зачем в UML столько диаграмм?


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

Что находится между идеей и кодом? Обзор 14 диаграмм UML IT, Длиннопост, Софт, Программирование, Программа, Программист, Разработка, Диаграмма

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

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

Напротив, технический писатель интересуется поведением системы в целом и должен понимать, как функционирует продукт.

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



Аве!

Показать полностью 17
546

Почему user experience важнее user interface

Наткнулся на пост http://pikabu.ru/story/slishkom_byistro_5015396 и начал вспоминать сколько раз я за свою жизнь портил хороший код в угоду пользователескому опыту: заблокировать GUI-поток на полсекунды, хотя авторизация пролетает за 10 мс, чтобы всем стало понятно, что приложение работает - это еще цветочки.


Был у нас в практике кейс в одной компании.

Была таблица с данными, которые обновляются автоматически и очень оперативно - раньше через AJAX / long polling, затем через SignalR, уж старались разработчики на благо пользователей. Однако, после выката в продакшн выяснилось, что в силу того, что большая часть клиентов - это взрослые тетёчки, эдакие "операторы ЭВМ", уж сильные сомнения у них вызывало то, что данные "сами обновятся" - они нервничали каждый раз, когда сидели и ждали обновления статуса. Пришлось прикручивать кнопку "Обновить", которая меняла курсор на "wait" (тот, что песочные часы) на секунду и больше ничего не делала. Все жалобы прекратились, в битве юзер против интерфейса юзер снова главный.


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

211

Работаю над интерфейсом в режиме полетов в космосе. Названия объектов, состояние, радар

Сейчас работаю над интерфейсом в космосе и радаром (мини-картой). Отображение оборудования/корабельных систем еще не запилил. Пока что реализован радар и отображение "на дисплее" информации об объектах - названии, скорости, целостности структуры и щитов.

Планируется, что система корабля, отвечающая за вывод информации об объектах, может быть отключена или выведена из строя. Поэтому сразу же реализую возможность отключения  отображения такой информации.

Работаю над интерфейсом в режиме полетов в космосе. Названия объектов, состояние, радар Хобби, Программирование, Gamedev, C++, Звездные ангелы, Интерфейс, Длиннопост

Отключаем отображение интерфейса, (якобы) отображаемое системами корабля, как будто система неисправна (пока "поломать" систему можно только консольной командой).
В результате чего перестает отображаться то, "что не видно глазами", а радар теряет сигнал и начинает мерцать (объекты не отображаются и сетка мигает)

Работаю над интерфейсом в режиме полетов в космосе. Названия объектов, состояние, радар Хобби, Программирование, Gamedev, C++, Звездные ангелы, Интерфейс, Длиннопост
Работаю над интерфейсом в режиме полетов в космосе. Названия объектов, состояние, радар Хобби, Программирование, Gamedev, C++, Звездные ангелы, Интерфейс, Длиннопост

Как-то так. Не очень быстро (из-за нехватки времени), но работа над проектом движется.

Показать полностью 2
Похожие посты закончились. Возможно, вас заинтересуют другие посты по тегам: