Я на этом low-level отдыхаю. Только я и код и никто третий не мешает. И задачи на самом деле не тривиальные.
И это лучше, чем попытки понять что клиент хочет, да еще через менеджера посредника. А особенно, если выясняеся, что клиент сам не понимает чего хочет. И ревизия чужого кода. простановка задач и т.д. и т.п. И типичное затыкание дыр в работе со скучным "возьми из БД и отдай json в HTTP(s)"
Считал их дорогими в обслуживании, и что они слишком фиксируют внутреннюю логику, в то время как проверять надо процесс целиком
И я его понимаю. Потому что на его месте. С теми же аргументами.
Все эти аргументы можно свести к одной фразе "Сроки выпуска дистрибутива". А все что этому мешает подлежит кастрированию. В том числе и оптимизация, которая займет несколько дней, но позволит вставить красиво 51 метод за 5 минут, вместо пол дня. Но.. вероятность, что появится 52-й метод неизвестна в принципе. Да и оптимизация наверняка что то сломает неожиданное (плавали.. знаем).
Цели все же не выпустить красивый код. А просто выпустить в сроки работающее и не фатально ломающееся на основных ветках логики ПО.
Хорошо быть просто разработчиком и писать в соотвествиие со своими "внутренними потребностями прекрасного".
Я бы может быть то же писал бы юнит тесты на каждую функцию/класс (не.. не писал бы. скучно и монотонно это), но тогда это чаще всего придется делать по ночам. Так что, если есть функциональные тесты для "чернового тестирования" перед передачей в тестирование, а потом в эксплуатацию - уже хорошо. Написание тестов отдельных классов и функций отнимают времени как бы не больше чем на код, который они тестируют. А наличие таких элементарных тестов вообще не гарантирует, что хотя бы "прямой функционал" без ошибок. А функциональный тест дает хотя бы какую то уверенность, что на бою у 90-98% клиентов (которые пойдут по основной ветки логики) проблем не возникнит и сервис не ляжет.
Если переиспользуется - отднозначно лучше без copy|paste кода. Т.е. выделить в отдельную.
Если функционально можно кусок кода выделить то то же желательно в отдельную завершенную функцию.
Я булькал по поводу практики резать линеный код ТОЛЬКО из соображений (слышал такой довод), что бы общая длинна была не более 30-50 строк. Без какого либо учета логики. Просто резать на части. Ну и НЕ выделять в функцию логику (п2.) состоящую из 1-2 строк кода. Причем примитивную. типа X*Y. Утрировано. Но похожие по смыслу примеры выделения видел.
нашел. заглянул в код.. того примера, что я описывал. Про 200 я загнул. 89 строк по факту вместе с анотациями @GETT) до последней "}"
У меня в экран IDE влазит 50 строк (обычный шрифт который я вижу без напряга с дистанции от 0.4 до 1 метра. неужели понять функцию длинной в 2 экрана это настолько большая проблема?! У меня как то логика функции и в 200 строк в голове умещается. Особенно если она разбита на логические блоки (коммент или хотя бы пустая строка). Хотя, 200 конечно перебор. Это я сгоряча (субъективно). больше чем один/1.5 экрана не использую.
Причем тут хобби... Это все в рамках основной работы.
bouncy castle - Когда возникают противоречивые требования "нельзя вставлять bouncy castle либы в дистрибутив" (типа не кошерно по некоторым треованиям понятно кого). Но будь добр поддержи "это и то" там где нет КриптоПро и прочих покупных (PKСS#7 стандарт, например, и пр.) и... ну не писать же с 0. Приходится "не явно" использовать.
jdbc. - а какого фига возгникает то или это непонтяное при переходе с Oracle (когда нужно на переходной период что бы там и там работало). Лезу в код Postgre jdbc и разбираюсь (исходники кода Postgre jdbc это мноooго лучше/красивее чем кривой код Oracle jdbc)
kafka client - который неожиданно менятся внутрений подход к организации TCP/IP соединения в новой версии либы и просто переход на новую либу приводит к тупняку и росту потребления ресурсов сервера kafka при пиковых нагрузках. Ни где про это не написано! Только по исходникам и понял что делать и в чем причина.
Spring Boot - запрос от эксплуатации "а дайте нам вот такие метрики (хочу и все)". Ан нет их в SpringBoot штатно. Приходится копаться в исходниках и находить куда влезть через рефлексию к найденым функциям и.. и.д. В недрах..
И это все только за последний год..
Примеры, pls, opensource (массового использования а не просто что то с Github) кода который Вам лично нравится и содержат (Вы же на этом настаиваете):
Тесты на все отдельные классы не в рамках общих функциоанльных тестов
Интерфейсные классы не для класических целей описать API для разных реализаций интерфейсов.
Без этого Ваши аргументы субьективно эмоциональные и не иллюстрированы.
Кстати, исходники SpringBoot мне как раз не очень нравятся. Чисто субъективно. Как раз пример того, что я не очень люблю. Когда функциоанл размазан по куче классов. Но и не крайний случай. В коридоре норм..нравится. Т.е. лучше чем мое субъективно "треш код"
Вы серьезно считаете что микросервис, который просто берет 5 параметров из БД (обычный select из одной/двух таблиц) и формирует Json в ответ на GET /blabla должен:
содержать обязательно слой пердставления данных (отдельный JPA класс в отдельном path)
Отдельно класс, который вытаскивает из БД.
Отдельный класс, который заворачивает в Json (НЕ json model. а отдельный блин класс)
json model класс.
А еще это выко нагруженный сервис. После убирание всего получися код в Resource классе, который просто дергает через jdbc коннект, полученный из пула, обычный select и (о стыд) собирает строку json через конкатенацию (даже не через String.format, который ооочень медленный).
Вот пусть другие пишут в таких случаях строго по учебнику. А в данном вариант важны были единицы ms и kb в хипе. GC JVM не дергается, судорожно пытася собрать мусор от всех этих классов которые "нужны" были для обработки запроса. И ко мне не прибегаю с криком почему так много жрет сервис при пиковой нагрузке. Это не типично конечно. Если что то сложное, то такое упрощение во вред пониманию кода. НО догматизм в любой области мне не нравится.
Сказать, что для кода из 100-200 строк разбитого на блоки комментариями и линейно выполняющего запрос в БД и формирование json без либ нужно 3 монитора..
Вот как то плавно приходим к тому, на что писать юнит тест... Давай уже оперировать примерами. Что для тебя является близким к эталону. На примере opensource либы.
Мне, например, ближе стили и подход bouncy castle (ну и больше всего в нем копался по ряду причин). И по использованию интерфейсов и по использувнию тестов. Функциональный тесты (org.junit.Test) не на классы и отдельный функции, а не функционал целиком. Типа загрузить ключ из файла/кода->подчитать криптограмму->проверить. Включая даже запуск сервера в рамках теста и TCP/IP соединения с ним. ни одного @Test на отдельный класс (как сферический конь в вакуме) там нет. Интерфейсы - это API через которое можно вызывать разные реализации. и не более.
назвавать эту либу "спагетти кодом" - ну как то язык не повернется.
А можно привести пример широкоиспользуемой либы с исходниками, написанными под твой подход?
Я полностью согласен с тем что вы сказали. Но вы аргументируете не со мной. А со своим представлением что я сказал.
см.
Сложно отделима от основной логики (= куча аргументов) и внятно придумать причину почему часть логики отделить нужно - невозможно. (ну кроме странного довода "так количество строк в этом файле будет поменьше")
Неа. Редко. И всегда видно контекст "это мы хотели потом пере использовать, но потом передумали". Довольно часто в исходниках библиотек приходится копаться и JDK то ж. Ну по моему опыту SpringBoot, Hibernate, Kafka client, jdbc Рostgre, bouncy castle - исходники из основных за проследний год.
конечно есть.. Если подумать и покопаться в истории всех фремворков то они все родились как чей то внутренний и потом стали "общественными". Просто внутренние не всегда дорастают до общественных. Чаще по причине НДЛ или "это наше ПО".
Кстати, слышал такую позицию на конференции одной. Причем достаточно агресивную от разработчика. Типа "мы" в это денги вложили. никакого opensource. Хотелось у разработчика спросить "а ты акционер что ли". А если нет, то нафига вообще с докладом вылез по продукту который ни OpenSoure делать не собираетесь ни продавать. Кому интересны ваши внутренние "шаги на пути к просветлению". Но не стал обострять..
Ключевой пункт, который я упоминал в аргументах "против", Вы не заметили или проигнорировали. "вызыватеся в одном месте" = "ОДИН РАЗ ИСПОЛЬЗУЕТСЯ". Точнее Вы все (оба) пункта причин/условий почему я против выделения чего то в функцию проигнорировали.
Ну нельзя же аргументировать только со своим понимание прочитанного. Не в обиду :)
Когда поддерживаешь какие либо продукты очень долго (> 5..10лет. Представляете.. и такое бывает), то вдруг узнаешь, что:
Фреймвоки умирают или трансформируется принципиально (GXT например). А коду то на пол ляма строк..
Предыдушая версия не поддерживается, СИБ требует переходит на новую (дырки обнаружены). А в новой вылезают неожиданные баги или приходилось заклаываться на внутренние особенности, а они уже другие.
Иногда оказывается что старое ПО, написанное без фреймворков поддерживать гораздо проще чем... Я не топлю за "не используем фремворки". Просто позиция "адвоката дьявола" :)
Единственная причина использовать интерфейсный класс (java) - это множественная имплементация. IMHO. Остальное дает только геморой и бессмысленное время, потраченное на нажатие на клавиатуре. В 90% случаев.
На что то сложно - да. А не на 2*2. У меня глаза болят от выделения совсем мелкого функционала (10 строк например) в функцию.
Когда она вызвается в одном месте.
Сложно отделима от основной логики (= куча аргументов) и внятно придумать причину почему часть логики отделить нужно - невозможно. (ну кроме странного довода "так количество строк в этом файле будет поменьше")
Тут вопрос не о "нужно не нужно" а о грани разумности в этом "нужно".
Лично я, когда мне такой кусок (сложный) нужно оттестировать, его отдельно тестирую и отлаживаю и copy/paste в нужно место. Когда это действительно нужно оттестировать. НО один раз и все.
Видел жесть в реализации джуна. Которому видимо сказали, что нужно все @Test обкладывать. Так он действительно ВСЕ обкладывал тестами. Каждую функцию класса (java) делал с возможность вызова отдельно и писал на нее тест. "Заставть дурака богу молится.." Код этих тестов был больше прикладного. А как изюминка.. в целом (как программа в комплексе) это все равно нифига не работало.
Бесить разгребать старый код (лет 15 ему). Когда из 3х(!) файлов C++ (.cpp,.hpp) получается 10 строк java (просто сформировать байтовый массив вида тип(1байт)+длина(2байта)+значение из 4-х аргументов). Догадываешься, что тот кто это писал начитался учебных материалов по полиморфизму, "правильной" организации иерахии объектов и.. И создал все это для формирования (один раз!) блока с фиксированым (!) набором. И глаза вытекают все это разбирать что бы понять а что и как хотел.
А уж боль с кучей абстракций, слоев данных, и все это разбросано по куче функцикций и файлов для ОДНОКРАТНОГО вызова - это вырви глаз типично. Потому что джун начитался гуру, которые советуют что длинна тела функции не должна быть более 20-30 строк, а в отдельном файле не должно быть более 100 строк и все нужно оформлять через абстракции и слои данных. И все это размером в 10Кбайт и 5 файлов схлопыветеся (переписывается) в 200 строк линейного обозримого кода в одной функции. Не знаю уж как обяснить что не нужно писать "функциональные вызовы" типа calcXmultipyY() { return X*Y; } вызываемые только один раз. Есть какая то разумная граница принципа выделения в отдельный вызов, а не просто "потому что". что бы про это "гуру" ни говорили.
Именно с мышой (датчиком типа ADNS2610) - иллюзия что точно. Мозг корректирует движение руки и курсора на экране. Попробуйте квадрат курсором обвести на экране и посмотрите куда вернется физическая мышь. Проц внутри мыши не заточне на это (точной корреляцией координат)
Я с ADNS2610 как то много экспериментировал. Кстати, у ADNS2610 есть возможность с камеры изображение получить (18x18 пикселей). Как раз для этих целей и пробовал. Малый размер в пикселях - не требуется больших вычислительный мощьностей. Очень дешево.
Вот только в документации не было сказано про скорость. В результате програмку под STM32F103 написал, отладил и.. Вот коммент из исходников (результаты тестов)
"шум" механической системы из раскрученного до очень высоких оборотов гироскопа и "шум" гироскопа внутри микросхемы (пьезоэлектрические вроде бы в основном) прост не сопоставимы. Я пробовал интегрировать сигнал XYZ с микросхемы. Была наивная мысль (типа я первый так сделаю) совместить металлоискатель (сингнал с него) с координатой. Что бы получить красивую двухмерную картинку. Не работает так.
ну если вдруг окажется, что 10 дней мало.. ну тогда добавлю и логику управления GPS и доработаю саму плату GPS. Если было нужно оптимизировать "по правильному", то ESP32 как основной модуль - это не правильно. Нужно ставить что то работающее на 1-5Мгц и жрущее мизер. Желательно в режиме сна с пробуждением от аналогово датчика движения. А остальные компоненты пробуждать по мере необходимости. И тонкая настройка GSM.
SIM800L в виде модуля с той минимальной обвязкой что есть - то же не айс. И вместо neo-6m нужно брать более дорогой вариант и оптимизировать и режим работы (отключая когда не нужно) и режимы настройки (там можно единицы mA выгадать)
В общем по честному, с серьезной экономией по току потребления - это другие компоненты и куча времени на отладку "в поле".
А к основному аккуму машины не подключал и даже не планирую.
Как то прилетел из отпуска в -40 в тропической одежде. А штатная сигналка с GPS (другая машинв) высосала весь штатный аккум в 0 за 20 дней. Вот весело было на морозе в легкой одежде плясать вокруг на стоянке аэропорта.. Так что, и производителеи сигнализаций экономят на компонетах и разработке. Вполне можно потребление было сократить до средних 1-5мA в дежурном режиме (грубо прикидывал). Но нет же.. всякие StarLine по 30-50mA тянут на 12V
А с эвакуаторами проще - просто ты не успеваешь добежать до увозимой машины
Были преценденты.
Машину увезли просто из за "какой то большой член МВД" должен был приехать и на всякий случай убрали машины, припаркованные без нарушений на штрафстоянку. Как же.. член же большой. Да еще из МВД.
Машина уехала на штраф стоянку. Но хотя бы понятно было на какую и что именно на нее. А не угнали. И понятно куда заносить квитацию о штрафе (какой район города).
Это же все молчком делается. Угон то ладно. А официальный "угон" без оповещения - это всегда нервы.
До нас глушилки GPS не дошли... Сибирь. Если что долетит, то сразу мегатонное. А так, все работает даже не под лобовым. Кординаты показывает точно.
Холодный старт до 3х минут, потребление питания - караул!
Ну у всех GPS приемников холодный старт длинный. 3 минуты это еще ничо. и 15..20 искать может. А питание... ну зато дешев. Дешевле 500 руб сложно найти готвый модуль. У меня валяется старый GPS модуль (не помню даже чего. 15 лет ему). так однако 100mA берет
И точно li-po падение напряжения при разряде не показывают ?
Если Вы про lifepo4, то он очень "плох" для анализа остатка зарядя по напряжению. С 3.6 до 3.2 падает за 1 день. Потом 7-8 дней 3.2. А если меньше 3.2 - то напряжение падает на глазах (за 1 день) и BMS на 2.5 выключает. Т.е. если 3.15 то значит остаток < 10..15% Смотрю по SMS от..
А если про li-po, то у него график разряда вроде бы вообще близок к линейному и остаток заряда по напряжению хорошо коррелируется. Но li-po 100% в not attended желеку ставить не стал бы. Это же просто опасно.
Сингалиция классическая это окрыть/закрыть машину (+прочеее). Из за своей штатности она только от шпаны. Да и не охота лезть встраивать.
у меня валяются ТРИ (!) GPS/GSM трекера. Два типа ST-901. В одном оказалось что нет акукмулятора внутри (не припаян) и хотя есть провод ACC, но он на него не реагирирует. В другом вроде бы все норма. Но SMS разбивает на две части и время в GMT+8 (китайское). И это не меняется настройками. 3-й какой то российский, но... SMS режим убогий (ничего толком не посылает) и заточне на гвоздями прибитый API к определенному сайту производитля. Т.е. опять же не то.
И валяются два иммобилайзера FALCON C10. Только один удалось запустить нормально. Какой то время обходился миксом FALCON C10+ST-901+датчик удара+генератор длинного импулься на NE555. В общем, то что сейчас можно купить - это какой то мусор собранный в подвале в Китае.
Все все что мне нужно:
Найти машину на парковке
Уведомление об ударе/погрузке на эвакуатор.
Вдруг я забыл документы/права в которых лежит токен.
Я на этом low-level отдыхаю. Только я и код и никто третий не мешает. И задачи на самом деле не тривиальные.
И это лучше, чем попытки понять что клиент хочет, да еще через менеджера посредника. А особенно, если выясняеся, что клиент сам не понимает чего хочет.
И ревизия чужого кода. простановка задач и т.д. и т.п.
И типичное затыкание дыр в работе со скучным "возьми из БД и отдай json в HTTP(s)"
И я его понимаю. Потому что на его месте. С теми же аргументами.
Все эти аргументы можно свести к одной фразе "Сроки выпуска дистрибутива".
А все что этому мешает подлежит кастрированию.
В том числе и оптимизация, которая займет несколько дней, но позволит вставить красиво 51 метод за 5 минут, вместо пол дня. Но.. вероятность, что появится 52-й метод неизвестна в принципе. Да и оптимизация наверняка что то сломает неожиданное (плавали.. знаем).
Цели все же не выпустить красивый код. А просто выпустить в сроки работающее и не фатально ломающееся на основных ветках логики ПО.
Хорошо быть просто разработчиком и писать в соотвествиие со своими "внутренними потребностями прекрасного".
Я бы может быть то же писал бы юнит тесты на каждую функцию/класс (не.. не писал бы. скучно и монотонно это), но тогда это чаще всего придется делать по ночам. Так что, если есть функциональные тесты для "чернового тестирования" перед передачей в тестирование, а потом в эксплуатацию - уже хорошо.
Написание тестов отдельных классов и функций отнимают времени как бы не больше чем на код, который они тестируют. А наличие таких элементарных тестов вообще не гарантирует, что хотя бы "прямой функционал" без ошибок.
А функциональный тест дает хотя бы какую то уверенность, что на бою у 90-98% клиентов (которые пойдут по основной ветки логики) проблем не возникнит и сервис не ляжет.
"и".
оба условия одновременно.
Если переиспользуется - отднозначно лучше без copy|paste кода. Т.е. выделить в отдельную.
Если функционально можно кусок кода выделить то то же желательно в отдельную завершенную функцию.
Я булькал по поводу практики резать линеный код ТОЛЬКО из соображений (слышал такой довод), что бы общая длинна была не более 30-50 строк. Без какого либо учета логики. Просто резать на части.
Ну и НЕ выделять в функцию логику (п2.) состоящую из 1-2 строк кода. Причем примитивную. типа X*Y. Утрировано. Но похожие по смыслу примеры выделения видел.
нашел. заглянул в код.. того примера, что я описывал. Про 200 я загнул.
89 строк по факту вместе с анотациями @GETT) до последней "}"
У меня в экран IDE влазит 50 строк (обычный шрифт который я вижу без напряга с дистанции от 0.4 до 1 метра.
неужели понять функцию длинной в 2 экрана это настолько большая проблема?!
У меня как то логика функции и в 200 строк в голове умещается. Особенно если она разбита на логические блоки (коммент или хотя бы пустая строка).
Хотя, 200 конечно перебор. Это я сгоряча (субъективно).
больше чем один/1.5 экрана не использую.
Причем тут хобби...
Это все в рамках основной работы.
bouncy castle - Когда возникают противоречивые требования "нельзя вставлять bouncy castle либы в дистрибутив" (типа не кошерно по некоторым треованиям понятно кого). Но будь добр поддержи "это и то" там где нет КриптоПро и прочих покупных (PKСS#7 стандарт, например, и пр.) и... ну не писать же с 0. Приходится "не явно" использовать.
jdbc. - а какого фига возгникает то или это непонтяное при переходе с Oracle (когда нужно на переходной период что бы там и там работало). Лезу в код Postgre jdbc и разбираюсь (исходники кода Postgre jdbc это мноooго лучше/красивее чем кривой код Oracle jdbc)
kafka client - который неожиданно менятся внутрений подход к организации TCP/IP соединения в новой версии либы и просто переход на новую либу приводит к тупняку и росту потребления ресурсов сервера kafka при пиковых нагрузках. Ни где про это не написано! Только по исходникам и понял что делать и в чем причина.
Spring Boot - запрос от эксплуатации "а дайте нам вот такие метрики (хочу и все)". Ан нет их в SpringBoot штатно. Приходится копаться в исходниках и находить куда влезть через рефлексию к найденым функциям и.. и.д. В недрах..
И это все только за последний год..
Примеры, pls, opensource (массового использования а не просто что то с Github) кода который Вам лично нравится и содержат (Вы же на этом настаиваете):
Тесты на все отдельные классы не в рамках общих функциоанльных тестов
Интерфейсные классы не для класических целей описать API для разных реализаций интерфейсов.
Без этого Ваши аргументы субьективно эмоциональные и не иллюстрированы.
Кстати, исходники SpringBoot мне как раз не очень нравятся. Чисто субъективно. Как раз пример того, что я не очень люблю. Когда функциоанл размазан по куче классов. Но и не крайний случай. В коридоре норм..нравится. Т.е. лучше чем мое субъективно "треш код"
Вы серьезно считаете что микросервис, который просто берет 5 параметров из БД (обычный select из одной/двух таблиц) и формирует Json в ответ на GET /blabla
должен:
содержать обязательно слой пердставления данных (отдельный JPA класс в отдельном path)
Отдельно класс, который вытаскивает из БД.
Отдельный класс, который заворачивает в Json (НЕ json model. а отдельный блин класс)
json model класс.
А еще это выко нагруженный сервис.
После убирание всего получися код в Resource классе, который просто дергает через jdbc коннект, полученный из пула, обычный select и (о стыд) собирает строку json через конкатенацию (даже не через String.format, который ооочень медленный).
Вот пусть другие пишут в таких случаях строго по учебнику. А в данном вариант важны были единицы ms и kb в хипе.
GC JVM не дергается, судорожно пытася собрать мусор от всех этих классов которые "нужны" были для обработки запроса. И ко мне не прибегаю с криком почему так много жрет сервис при пиковой нагрузке.
Это не типично конечно. Если что то сложное, то такое упрощение во вред пониманию кода.
НО догматизм в любой области мне не нравится.
Сказать, что для кода из 100-200 строк разбитого на блоки комментариями и линейно выполняющего запрос в БД и формирование json без либ нужно 3 монитора..
Вот как то плавно приходим к тому, на что писать юнит тест...
Давай уже оперировать примерами. Что для тебя является близким к эталону. На примере opensource либы.
Мне, например, ближе стили и подход bouncy castle (ну и больше всего в нем копался по ряду причин). И по использованию интерфейсов и по использувнию тестов.
Функциональный тесты (org.junit.Test) не на классы и отдельный функции, а не функционал целиком. Типа загрузить ключ из файла/кода->подчитать криптограмму->проверить. Включая даже запуск сервера в рамках теста и TCP/IP соединения с ним.
ни одного @Test на отдельный класс (как сферический конь в вакуме) там нет.
Интерфейсы - это API через которое можно вызывать разные реализации. и не более.
назвавать эту либу "спагетти кодом" - ну как то язык не повернется.
А можно привести пример широкоиспользуемой либы с исходниками, написанными под твой подход?
Я полностью согласен с тем что вы сказали.
Но вы аргументируете не со мной. А со своим представлением что я сказал.
см.
Это не попадает под приведенный Вами пример.
Неа. Редко.
И всегда видно контекст "это мы хотели потом пере использовать, но потом передумали".
Довольно часто в исходниках библиотек приходится копаться и JDK то ж.
Ну по моему опыту
SpringBoot, Hibernate, Kafka client, jdbc Рostgre, bouncy castle - исходники из основных за проследний год.
конечно есть..
Если подумать и покопаться в истории всех фремворков то они все родились как чей то внутренний и потом стали "общественными". Просто внутренние не всегда дорастают до общественных. Чаще по причине НДЛ или "это наше ПО".
Кстати, слышал такую позицию на конференции одной. Причем достаточно агресивную от разработчика. Типа "мы" в это денги вложили. никакого opensource.
Хотелось у разработчика спросить "а ты акционер что ли". А если нет, то нафига вообще с докладом вылез по продукту который ни OpenSoure делать не собираетесь ни продавать. Кому интересны ваши внутренние "шаги на пути к просветлению".
Но не стал обострять..
Ключевой пункт, который я упоминал в аргументах "против", Вы не заметили или проигнорировали.
"вызыватеся в одном месте" = "ОДИН РАЗ ИСПОЛЬЗУЕТСЯ".
Точнее Вы все (оба) пункта причин/условий почему я против выделения чего то в функцию проигнорировали.
Ну нельзя же аргументировать только со своим понимание прочитанного. Не в обиду :)
Когда поддерживаешь какие либо продукты очень долго (> 5..10лет. Представляете.. и такое бывает), то вдруг узнаешь, что:
Фреймвоки умирают или трансформируется принципиально (GXT например). А коду то на пол ляма строк..
Предыдушая версия не поддерживается, СИБ требует переходит на новую (дырки обнаружены). А в новой вылезают неожиданные баги или приходилось заклаываться на внутренние особенности, а они уже другие.
Иногда оказывается что старое ПО, написанное без фреймворков поддерживать гораздо проще чем...
Я не топлю за "не используем фремворки".
Просто позиция "адвоката дьявола" :)
Единственная причина использовать интерфейсный класс (java) - это множественная имплементация. IMHO.
Остальное дает только геморой и бессмысленное время, потраченное на нажатие на клавиатуре.
В 90% случаев.
На что то сложно - да. А не на 2*2.
У меня глаза болят от выделения совсем мелкого функционала (10 строк например) в функцию.
Когда она вызвается в одном месте.
Сложно отделима от основной логики (= куча аргументов) и внятно придумать причину почему часть логики отделить нужно - невозможно. (ну кроме странного довода "так количество строк в этом файле будет поменьше")
Тут вопрос не о "нужно не нужно" а о грани разумности в этом "нужно".
Лично я, когда мне такой кусок (сложный) нужно оттестировать, его отдельно тестирую и отлаживаю и copy/paste в нужно место. Когда это действительно нужно оттестировать. НО один раз и все.
Видел жесть в реализации джуна. Которому видимо сказали, что нужно все @Test обкладывать.
Так он действительно ВСЕ обкладывал тестами. Каждую функцию класса (java) делал с возможность вызова отдельно и писал на нее тест. "Заставть дурака богу молится.."
Код этих тестов был больше прикладного. А как изюминка.. в целом (как программа в комплексе) это все равно нифига не работало.
Бесить разгребать старый код (лет 15 ему). Когда из 3х(!) файлов C++ (.cpp,.hpp) получается 10 строк java (просто сформировать байтовый массив вида тип(1байт)+длина(2байта)+значение из 4-х аргументов).
Догадываешься, что тот кто это писал начитался учебных материалов по полиморфизму, "правильной" организации иерахии объектов и.. И создал все это для формирования (один раз!) блока с фиксированым (!) набором.
И глаза вытекают все это разбирать что бы понять а что и как хотел.
А уж боль с кучей абстракций, слоев данных, и все это разбросано по куче функцикций и файлов для ОДНОКРАТНОГО вызова - это вырви глаз типично. Потому что джун начитался гуру, которые советуют что длинна тела функции не должна быть более 20-30 строк, а в отдельном файле не должно быть более 100 строк и все нужно оформлять через абстракции и слои данных.
И все это размером в 10Кбайт и 5 файлов схлопыветеся (переписывается) в 200 строк линейного обозримого кода в одной функции. Не знаю уж как обяснить что не нужно писать "функциональные вызовы" типа calcXmultipyY() { return X*Y; } вызываемые только один раз. Есть какая то разумная граница принципа выделения в отдельный вызов, а не просто "потому что".
что бы про это "гуру" ни говорили.
просто поделился болью. не более.
Именно с мышой (датчиком типа ADNS2610) - иллюзия что точно. Мозг корректирует движение руки и курсора на экране.
Попробуйте квадрат курсором обвести на экране и посмотрите куда вернется физическая мышь.
Проц внутри мыши не заточне на это (точной корреляцией координат)
Я с ADNS2610 как то много экспериментировал. Кстати, у ADNS2610 есть возможность с камеры изображение получить (18x18 пикселей). Как раз для этих целей и пробовал. Малый размер в пикселях - не требуется больших вычислительный мощьностей. Очень дешево.
Вот только в документации не было сказано про скорость. В результате програмку под STM32F103 написал, отладил и..
Вот коммент из исходников (результаты тестов)
{code:cpp}
// Time per 18x18 image scan:
// 0.214s 1008..1012 lostCnt(ADNS2610_delay = 110us, CLK_halfDelay = 8)
// 0.214s 691..701 lostCnt (ADNS2610_delay = 100us, CLK_halfDelay = 20)
// 0.214s 517..520 lostCnt (ADNS2610_delay = 100us, CLK_halfDelay = 30)
// 0.214s 377..380 lostCnt (ADNS2610_delay = 150us, CLK_halfDelay = 30)
// 0.214s 52..54 lostCnt (ADNS2610_delay = 100us, CLK_halfDelay = 100)
// 0.214s 39..41 lostCnt (ADNS2610_delay = 120us, CLK_halfDelay = 100)
// 0.218s 0..1 lostCnt (ADNS2610_delay = 200us, CLK_halfDelay = 100)
// Time per 18x1 image scan: 0.012 sec
uint8_t *ADNS2610_getImage(uint32_t sz, int *lost) {
if(sz > sizeof(imageBuffer)) sz = sizeof(imageBuffer);
ANDS2610_setRegister(0x08, 0x2A);
uint32_t n = 0;
int lostCnt = 0;
for(int i = 0; i < 10000; i++) {
uint8_t b = ANDS2610_getRegister(0x08);
if((b & 0x40) == 0) {
lostCnt++;
continue;
}
imageBuffer[n++] = b & 0xBF;
if(n == sz) {
lost = lostCnt; return (uint8_t)(&imageBuffer[0]);
}
}
return NULL;
}
{code}
Оказалось слишком медлено выдача изображения.
"шум" механической системы из раскрученного до очень высоких оборотов гироскопа
и "шум" гироскопа внутри микросхемы (пьезоэлектрические вроде бы в основном) прост не сопоставимы.
Я пробовал интегрировать сигнал XYZ с микросхемы.
Была наивная мысль (типа я первый так сделаю) совместить металлоискатель (сингнал с него) с координатой. Что бы получить красивую двухмерную картинку.
Не работает так.
ну если вдруг окажется, что 10 дней мало.. ну тогда добавлю и логику управления GPS и доработаю саму плату GPS.
Если было нужно оптимизировать "по правильному", то ESP32 как основной модуль - это не правильно. Нужно ставить что то работающее на 1-5Мгц и жрущее мизер. Желательно в режиме сна с пробуждением от аналогово датчика движения. А остальные компоненты пробуждать по мере необходимости. И тонкая настройка GSM.
SIM800L в виде модуля с той минимальной обвязкой что есть - то же не айс.
И вместо neo-6m нужно брать более дорогой вариант и оптимизировать и режим работы (отключая когда не нужно) и режимы настройки (там можно единицы mA выгадать)
В общем по честному, с серьезной экономией по току потребления - это другие компоненты и куча времени на отладку "в поле".
А к основному аккуму машины не подключал и даже не планирую.
Как то прилетел из отпуска в -40 в тропической одежде. А штатная сигналка с GPS (другая машинв) высосала весь штатный аккум в 0 за 20 дней. Вот весело было на морозе в легкой одежде плясать вокруг на стоянке аэропорта..
Так что, и производителеи сигнализаций экономят на компонетах и разработке.
Вполне можно потребление было сократить до средних 1-5мA в дежурном режиме (грубо прикидывал). Но нет же.. всякие StarLine по 30-50mA тянут на 12V
Были преценденты.
Машину увезли просто из за "какой то большой член МВД" должен был приехать и на всякий случай убрали машины, припаркованные без нарушений на штрафстоянку. Как же.. член же большой. Да еще из МВД.
Машина уехала на штраф стоянку. Но хотя бы понятно было на какую и что именно на нее. А не угнали. И понятно куда заносить квитацию о штрафе (какой район города).
Это же все молчком делается.
Угон то ладно. А официальный "угон" без оповещения - это всегда нервы.
До нас глушилки GPS не дошли... Сибирь. Если что долетит, то сразу мегатонное.
А так, все работает даже не под лобовым. Кординаты показывает точно.
Ну у всех GPS приемников холодный старт длинный. 3 минуты это еще ничо. и 15..20 искать может.
А питание... ну зато дешев. Дешевле 500 руб сложно найти готвый модуль.
У меня валяется старый GPS модуль (не помню даже чего. 15 лет ему). так однако 100mA берет
Если Вы про lifepo4, то он очень "плох" для анализа остатка зарядя по напряжению.
С 3.6 до 3.2 падает за 1 день. Потом 7-8 дней 3.2. А если меньше 3.2 - то напряжение падает на глазах (за 1 день) и BMS на 2.5 выключает. Т.е. если 3.15 то значит остаток < 10..15%
Смотрю по SMS от..
А если про li-po, то у него график разряда вроде бы вообще близок к линейному и остаток заряда по напряжению хорошо коррелируется.
Но li-po 100% в not attended желеку ставить не стал бы. Это же просто опасно.
Сингалиция классическая это окрыть/закрыть машину (+прочеее). Из за своей штатности она только от шпаны. Да и не охота лезть встраивать.
у меня валяются ТРИ (!) GPS/GSM трекера. Два типа ST-901.
В одном оказалось что нет акукмулятора внутри (не припаян) и хотя есть провод ACC, но он на него не реагирирует. В другом вроде бы все норма. Но SMS разбивает на две части и время в GMT+8 (китайское). И это не меняется настройками.
3-й какой то российский, но... SMS режим убогий (ничего толком не посылает) и заточне на гвоздями прибитый API к определенному сайту производитля. Т.е. опять же не то.
И валяются два иммобилайзера FALCON C10. Только один удалось запустить нормально.
Какой то время обходился миксом FALCON C10+ST-901+датчик удара+генератор длинного импулься на NE555.
В общем, то что сейчас можно купить - это какой то мусор собранный в подвале в Китае.
Все все что мне нужно:
Найти машину на парковке
Уведомление об ударе/погрузке на эвакуатор.
Вдруг я забыл документы/права в которых лежит токен.
да собственно все.