Для запроса и ответа создания страницы в Confluence можно использовать одну и туже структуру. Только в запросе полей меньше заполнять. А из ответа можно получить полезные вещи: код страницы и ссылку на страницу, чтобы потом можно было в задаче линк сделать.
А смысл в том что новые пошивки на STM32 летают очень отлично! И есть разные прошивки заточенные под разные стили полетов и с каждой версией они летать лучше и лучше! А чтобы настроить старые пошивки для полета — это придется сильно помучиться. И главное где купить это старье! У меня они остались, но я даже не хочу их доставать. Проект iNavFlight достойно летает по GPS, а BetaFlight отлично летает в Акро режиме — что для мини квадрика является лучшим выбором!
И про телеметрию: сейчас с телеметрией никаких проблем. Приемники FrSky передают всю телеметрию: напряжение, ток, потребленная энергия, наклоны, угля, скорость и много много другой информации прямо на пульт. Можно выводить и на OSD которая встроена на полетный контроллер и с датчиком тока. Сейчас уже пошли дальше и датчик тока установлен в каждом из 4-х регуляторов и всю эту информацию можно вывести на OSD. И даже на дальнолетах с передатчиком/приемником TBS Crossfire телеметрию можно получать и записывать на SD карту пульта с последующим анализом в программе FrSky Companion, передается на больших расстояниях до 10 километров.
Статья отстала на 5 лет минимум! Зачем писать в 2019 году о таком старье!
Я пытался в 2013-2014 году собрать такой, не полетел — упал. Сейчас все летает! Но уже другие комплектующие и другой софт!
Я говорю не про автомат. А про ручную калибровку. Например входим в режим калибровки: 1 сервопривод отклоняем в одну сторону и кнопками + и — устанавливаем отклонение на контрольную метку, потом 1 привод отклоняем в другую сторону и кнопками совмещаем вторую метку. Можно еще выставлять среднюю метку (края и середина, но обычно сервоприводы линейны в обе стороны). Таким образом запоминаем мин и макс значения импульс когда сервоприводы откланяются на заданный угол согласно меток, ну а дальше вычисляем коэффициент и смещение центра. И так все остальные приводы. Да, долго — но зато универсально.
Как видно, шаг импульса для каждого привода отличаются, это было неожиданным для меня открытием.
Кто имеет дело с сервоприводами — об этом знают и везде есть понятие «калибровка» сервоприводов. Указывают крайние точки на которые отклоняется выход сервомашинки и запоминают значения подаваемых импульсов, ну а дальше на основе этих данных масштабируют нужный угол в значения длины импульсов для каждой сервомашинки. Я бы добавил возможность калибровки каждого сервопривода и тогда все будет довольно точно. Вдруг далее захотите заменить сервомашинки на другие и опять таблицу будете делать :)
Ну если мне ловить микросекунды, то да, наверное не правильный метод. Но если я запускаю цикл в 10 тысяч итераций, то этот метод нормально отображает неправильность поведения JVM при работе со строками. Мне не нужна точность, мне нужен показатель, что так делать нельзя.
В нормальном профилировании кода, все равно видно что где ты накосячил. А для показа, так делать нельзя, классический тупой подход подходит.
Просто в статье приводится пример что работает через StringBuffer, а в JDK 11 через какую то другую хрень, то я лично не увидел, что в JDK 11 это сработает быстрее.
Но вот классический пример с конкатенацией в цикле и с использованием StringBuilder наглядно показывает, что в JDK8 что в JDK11 лучше использовать StringBuilder в цикле, чем конкатенацию через "+" либо String.concat().
И ничего не поменялось в JDK11, и это видно из статьи. Да на микросекунду стало быстрей!
Что в 8 что в 11 работают одинаково медленно и жрут очень много памяти. То что немного убыстрили в 11 — это есть и в основном связано что в JDK9 сделали хранение строк либо в байтах (если ASCII строка) либо в символах (для строк в других кодировках). Если проводить тест с ASCII символами, то памяти меньше расходуется, если с русскими — то так же как и в JDK8
У Вас в работе с файлами полный сумбур! Так никто никогда не делает, полная путаница!
Для того чтобы сжать Хаффманом нужно сделать всего 2 прохода:
1. проход — сбор статистики по байтам! не строкам!
2. строим таблицу Хаффмана
3. проходим снова файл от начала до конца и кодируем согласно построенной таблицы Хоффмана.
У Вас же какие-то хелперы, читаете входной файл строкам! сразу все в память! Зачем?! Вы кодируете, а если это несколько Гигабайт или Терабайт? И куча других вопросов по работе с обычными БИНАРНЫМИ (не текстовыми) файлами!
Короче это не код, а помойка! Нет стройности в реализации алгоритма.
В алгоритме Хоффмана есть 2 изюминки: генерация кодов Хоффмана (но это описано 10000+ раз) и работа с битами. Я даже не могу найти в Вашем коде работу с битами! Код должен быть понятен при разборе алгоритма, у Вас же сумбур :(
С теорией у вас все в порядке, но вот что-то реализация больно сложная :(
Вот делал на паскале Huffman, переписывал со своих исходников на Си. На Java можно как то поизящней сделать было.
Ведь алгоритм Haffman это же классика жанра. Он используется в формате JPEG после того как произойдет квантизация изображения.
И на сколько помню, хранить коды Хоффмана в выходном файле не обязательно. главное отсортированную таблицу сохранить, а код Хоффмана строиться однозначно при кодировании и декодировании. Нужно только знать кол-во кодированных символов и их порядок по мере убывания частоты встречи символа в файле.
Потому что доверия к H2 нет! Это СУБД живет в памяти. В различных исключительных ситуациях данные из памяти теряются не сохраняясь на диск. Для продашена это не допустимо! У меня несколько раз такое было на тестовых экземплярах JIRA. Хорошо что это были тестовые инстансы. А нормальные СУБД такого не допускают.
В документации есть правильное решение по смене пароля администратора. Для этого в строку запуска JIRA нужно добавить ключик запуска в однопользовательском режиме. Запускаете, меняете пароль, останавливаете, убираете ключ и запустеете снова.
И как правильно выше написали Вам: в продакшене НЕЛЬЗЯ использовать базу H2! Неужели трудно поставить PostgreSQL или на крайний случай MySQL. В любом дистрибутиве Linux они есть.
Да. Такого изврата я еще не видел.
Все администраторы СУБД Oracle знают: если у тебя больше чем 2 инстанса СУБД, то развертывай Oracle Enterprise Manager или как он по новому называется Oracle Cloud Manager и управляй всеми продуктами Oracle включая СУБД и сервера приложений. Возможностей управления будет гораздо больше.
И про телеметрию: сейчас с телеметрией никаких проблем. Приемники FrSky передают всю телеметрию: напряжение, ток, потребленная энергия, наклоны, угля, скорость и много много другой информации прямо на пульт. Можно выводить и на OSD которая встроена на полетный контроллер и с датчиком тока. Сейчас уже пошли дальше и датчик тока установлен в каждом из 4-х регуляторов и всю эту информацию можно вывести на OSD. И даже на дальнолетах с передатчиком/приемником TBS Crossfire телеметрию можно получать и записывать на SD карту пульта с последующим анализом в программе FrSky Companion, передается на больших расстояниях до 10 километров.
Я пытался в 2013-2014 году собрать такой, не полетел — упал. Сейчас все летает! Но уже другие комплектующие и другой софт!
Кто имеет дело с сервоприводами — об этом знают и везде есть понятие «калибровка» сервоприводов. Указывают крайние точки на которые отклоняется выход сервомашинки и запоминают значения подаваемых импульсов, ну а дальше на основе этих данных масштабируют нужный угол в значения длины импульсов для каждой сервомашинки. Я бы добавил возможность калибровки каждого сервопривода и тогда все будет довольно точно. Вдруг далее захотите заменить сервомашинки на другие и опять таблицу будете делать :)
В нормальном профилировании кода, все равно видно что где ты накосячил. А для показа, так делать нельзя, классический тупой подход подходит.
Просто в статье приводится пример что работает через StringBuffer, а в JDK 11 через какую то другую хрень, то я лично не увидел, что в JDK 11 это сработает быстрее.
Но вот классический пример с конкатенацией в цикле и с использованием StringBuilder наглядно показывает, что в JDK8 что в JDK11 лучше использовать StringBuilder в цикле, чем конкатенацию через "+" либо String.concat().
И ничего не поменялось в JDK11, и это видно из статьи. Да на микросекунду стало быстрей!
В чем подвох? Неправильно работают внутренние процедуры/функции Java?
Что в 8 что в 11 работают одинаково медленно и жрут очень много памяти. То что немного убыстрили в 11 — это есть и в основном связано что в JDK9 сделали хранение строк либо в байтах (если ASCII строка) либо в символах (для строк в других кодировках). Если проводить тест с ASCII символами, то памяти меньше расходуется, если с русскими — то так же как и в JDK8
Будьте внимательны, раз уж про ошибки пишите :)
Для того чтобы сжать Хаффманом нужно сделать всего 2 прохода:
1. проход — сбор статистики по байтам! не строкам!
2. строим таблицу Хаффмана
3. проходим снова файл от начала до конца и кодируем согласно построенной таблицы Хоффмана.
У Вас же какие-то хелперы, читаете входной файл строкам! сразу все в память! Зачем?! Вы кодируете, а если это несколько Гигабайт или Терабайт? И куча других вопросов по работе с обычными БИНАРНЫМИ (не текстовыми) файлами!
Короче это не код, а помойка! Нет стройности в реализации алгоритма.
В алгоритме Хоффмана есть 2 изюминки: генерация кодов Хоффмана (но это описано 10000+ раз) и работа с битами. Я даже не могу найти в Вашем коде работу с битами! Код должен быть понятен при разборе алгоритма, у Вас же сумбур :(
Вот делал на паскале Huffman, переписывал со своих исходников на Си. На Java можно как то поизящней сделать было.
Ведь алгоритм Haffman это же классика жанра. Он используется в формате JPEG после того как произойдет квантизация изображения.
И на сколько помню, хранить коды Хоффмана в выходном файле не обязательно. главное отсортированную таблицу сохранить, а код Хоффмана строиться однозначно при кодировании и декодировании. Нужно только знать кол-во кодированных символов и их порядок по мере убывания частоты встречи символа в файле.
И как правильно выше написали Вам: в продакшене НЕЛЬЗЯ использовать базу H2! Неужели трудно поставить PostgreSQL или на крайний случай MySQL. В любом дистрибутиве Linux они есть.
Все администраторы СУБД Oracle знают: если у тебя больше чем 2 инстанса СУБД, то развертывай Oracle Enterprise Manager или как он по новому называется Oracle Cloud Manager и управляй всеми продуктами Oracle включая СУБД и сервера приложений. Возможностей управления будет гораздо больше.