Да статья IMHO вообще -отстой-. точнее немного поверхностная. "отстой" - не правильное слово. Слишком много букв по поводу стандартных утилит PG и, например, ни слова про WAL (журнал PG) и методы реплицирования через него и более глубокие способы/подходы к репликации БД.
Но, впрочем, бурчать по поводу "статья отстой" можно почти многим статья в habre написанных ради "вот мой телеграм канал" и "блок компании".
Но кто то же столько + то наставил статье. Значит кому то это базовая информация по стандартным утилитам PG зашла.. Ну и автор все же птратил веремя на эксперименты и выложил результаты а не просто абстактное blabla
не знаю кто поставил минус.. Вопрос как вопрос. Другое дело что вопрос вообще не имеет отношения к бэкапам именно PG и имено как БД. Очень частный случай для каких то не больших тестов или "поиграться".
Это какое то служебное приложение, сделанное, судя по описанию, какием то инженером из Греции для своих производственных целей. https://play.google.com/store/apps/details?id=com.ibeacon.app Вообще взял первое попавшеся в google play, когда отлаживал сигналку и опрос BLE устройств вокруг. Чисто для тестов. Но так и оставил как "резерв", если батарейка в аппартном токене сдохнет, а нужно было что бы сигналка меня опознала.
Так что оно не самое "идеальное". Просто пример такого приложения.
Таких приложений и с иходниками много на Github и можно собрать самому под себя/свои требования. Ничего сложного в нем нет.
AirTag использует криптографию. Но, он сам генерит ключ (EC пару). Т.е. использование криптографии препятствует копированию/подделке уже активированного AirTag. Но ни как не созданю эмулятора "нового AirTag".
Cмотрел реализации ESP32 и python под Linux. По моему, там все просто. Да и сложно было разработчикам что то запихнуть сложное в BLE в advertise. Там и так они компромис искали куда засунуть публичный ключ, что бы его длинна уж совсем короткая не была и в пакет влезло (включая часть адреса).
Кстати, про ограничение изменения адресной части BLE в Android не знал и не проверял. (тут в коментах про это упомянули. наверное есть, раз пишут) Просто не было необходимости и не сталкивался.
Я себя сделал сигнализацию (https://habr.com/ru/articles/901352). В основном пользуюсь дешовым BLE токеном купленным на Озоне (не AirTag). Но, заодно, нашел приложение под android для эмуляции (My iBeacons) и пользуюсь им. Без ключей. Статический ответ на BLE SCAN (BDA).
Писать свое android приложение было лень. Поскольку есть готовые для установки (Включая с иходниками на Github). Да и метка аппаратная в кошельке валяется с правами.
Установил (не важно каким способом) на свой телефон трояна
Троян может что то делать. (в данном случае притворятся AirTag)
то это уже тянет на статью?
Специалисты по безопасности разработали универсальный способ
У меня уже эта фраза вызывает интоксикацию. Почему то в ушах звучит мем "Британские ученые" Когда банальное и широкоизвестное (может быть и в узких кругах) выдают за "разработали"...
У меня претензии не к содержимому статьи. А к тому что она банальна и не интересна.IMHO. Хотя, если для кого то открытие, что троян может сделать что угодно и что вообще есть AirTag (Samsung Galaxy SmartTag), ну тогда "ой".
Так это вообще то штатная функция AirTag. Для чего про это целую статью то. Если смысл стать "если вы поставите трояна на свой телефон, то будет айяй" так это то же не достойно статьи.
Если что, у меня на телефоне стоит эмулятор BLE метки. Я его как токен к сигнализации использую.
Поэтому набор тривиальной информации в статье у меня вызвал сомнения в ее полезности вообще.
Длинная и многословная статья. Суть котрой сводится к "есть/бывают программы, эмулирующие AirTag". Было бы что там эмулировать то.. Формат AirTag известен и не особо секретен. Спасибо кэп "Очевидность".
Статью почему то хабр не позволяет сохранить отредактированную. кнопка "сохранить" деактивирована. Лень разбираться почему.
А литиево-железо-фосфатные и Литий-титанатные аккумуляторы – самый безопасный тип литиевых аккумуляторов. Вы наверное с Li-pol перепутали (самые пожароопасные).
В основе устройства лежит микроконтроллер Espressif ESP32.
уже начиная с этой фразы возникают сомнения в фразе
даже тысяч часов
потребление ESP32 на 3.3V при отключеном RF около 35-40mA. Ну разве что, если спать будет большую часть времени. А так, подсчитать легко 10000/50 = 250 часов (10дней).
Продираясь про мегаподробное описание "как загрузить и установить в сервер приложение новое приложенеи через web UI администратора сервера приложений" увидил удивительный вывод, что это является уязвимостью. Вообще кроме Tomcat есть/было и другие сервера приложений и в них всегда из коробки есть страница для управления сервисами (хотя никто не мешает делать это из консоли)
По сути, Apache Tomcat по-прежнему остается предпочтительным выбором для развертывания Java-веб-приложений
Ну если ничего больше, кроме Tomcat не знаете, то да. А вообще сервера приложений вышли из моды (начали выходить плавно с 2010..2012). По ряду причин. В частности, удешевлением комп ресурсов, когда одно из преимуществ подхода "сервер приложений" = экономия на ОЗУ становится не так актуальным как проблемы поддержки/эксплуатации сервера приложенеи (падает сразу со всем приложениями и пр. подобное.. долго перечислять). Появились/развились фремвоки (SpringBoot) и либы для встраиваемых HTTP серверов. Ну и просто стало модно делать "микросервисы" (чаще всего понимая под этим HTTP+json) как отдельные OS процессы , а не war модули в сервере приложения.
написал и подумал.. А зачем писал. Статья ни о чем. Просто "вода" что бы было что опубликовать для ссылки на telegram канал. Подозреваю, что в канале такой же мусор. "Life-Hack - Хакер" ну ну... мамкин хакер. но не удалять же..
C++ в данном случае - этопереписывание строго ПО на java. Иногда проще переписать относительно простой модуль на кросс платформенное, чем возится с.. Java мне больше нравится чем C/C++. И на том и на том давно пишу. но очень не люблю тратить время на разбор неуловимых причин core dumbped С++ программ и возню с big|little endian, байтовыми/word выравниваниями/упаковками данных. А это есть было и будет, если в качетве серверных платформ испольхуется не тольк x86
у меня этот режим на рабочем компе (не я включал). Подключал новую клавиатуру - увидел. Пока не введешь пароль с экрана на подключенной клвиатуре - она блокирована. Может это не шатаная функция Windows. А что то специально для этого стоит.
надо будет разобраться и на домашнем ноуте включить.. Хотя я все одно все левое только в виртуалке смотрю. и незнакомые "флешки" в разъемы не пихаю.
интеграционые тесты (ну в моих реалиях) которые в коде @Testt) - это, как правило подготовленные по документации примеры "прямого пути". Т.е. пути, по которому пойдет платеж (мои реалии) для 99% клиентов. Интеграционые, потму что проверяется не функционал отдельных кусков. А все в целом (эмуляция как бою, включая работу с БД, kafka и пр.).
Понятно, что есть боковые ветки. Типичные (типа "ой денег на счете нет") то же обычно входят в интеграционный тест. Всякие не стандартные побочки ("ой БД легла", "ой память кончилась") обычно не входят. Ну и регрессия по старым тестам и стресс тесты на нагрузку. Но это уже перед выпуском дистрибутива, потому что долго по времени.
Как то до мышей (тесты на классы и куски кода) можно опускаться, но блин.. сроки. Так что.. редко. Если только что то сложное и легко тестируется отдельно от всего остального (типа крипто подпись проверит/создать по определенному требованию). Потому что время на выпуск ой...
Но практика показывает, что такой подход рабочий и коэф. готовности вполне укладывается под требования ЦБ.
А так, да.. гарантие отсутвие проблем в ПО - это обесточнный ЦОД с сломавшимся аварийным генератором. В остальных случаях поведение ПО предсказуемо с точностью 50 на 50 (либо работает - либо сбой). Как с динозавром на улице из анекдота.
Забив на какое-то место в начале, сделав как проще, и забивая на него в дальнейшем, когда из раза в раз приходится залезать в один и тот же код и вносить изменения, в конечном итоге можно получить что-то крайне сложно понимаемое и поддерживаеиое.
Проблемы копятся как снежный ком, и в итоге действительно становится даже оптимизации вводить тяжело и дорого
По моей статистике, в случаях, когда судьба продукта не ясна на старте, в 90% случая он либо умирает либо не требует особого развития (живет себе и живет корявым архитектурно). Конечно это не касается тех продуктов, судьба которых известна на старте. Типа СБП :)
Именно по моей статистике, вкладываться в архитектуру нового с расчетом, что оно взлетит это на 20% не угадать с "направление взлета" и выбранная архитектура ПО не подойдет под. И 70% - вложения окажутся не нужными (умрет или не будет развиваться)
Остается 10% на "угадал". Печальная статистика. Чаще всего приходится переделывать практически с 0 при росте нагрузки и/или измененрия/увеличения функционала. Или мирится с корявостями, если особой оптимизации под производительность не нужно и не понятны перспективы "что дальше то с этим будет" Потому что "не угадал" (ясновицем нужно быть что бы учеть будущие требования клиентов о которых они сами еще не знают).
Вот Ваш пример попадает под "не угадали". (ну или сделали на авось. контекста я не знаю).
А разве не практикуется включать режим проверки в Windows?
Когда при включение неизвестной (не подтвержденной) клавиатуры, на экране появляется требование вести случайный текст с экрана на подключаемой клавиатуре. По моему, 100% защита от таких вещей.
Не помню как это включается в Windows. но не суть. У меня на компе так.
У них там такая конкуренция, что даже интересно, к каким вундервафлям автопром придет на горизонте 10 лет.
Я поэтому и не стал покупать китайскую машину. Пройдет 3 года и линейка настолько сменится, что запчасти не найти в принципе. Разве что канибализмом с авторазборов умерших в авариях одногодок. И что тогда делать?
в каждом конкретном случае, где что удобней - там и нужно.
Да еще бы с терминологией определится. Каждый свое подразумевает по "ООП". не буде дискутировать по поводу "что такое ООП". Это как спорить "сколько ангелов на конце иглы поместится". Выродились все эти дискусси в схоластику. IMHO
Я на этом low-level отдыхаю. Только я и код и никто третий не мешает. И задачи на самом деле не тривиальные.
И это лучше, чем попытки понять что клиент хочет, да еще через менеджера посредника. А особенно, если выясняеся, что клиент сам не понимает чего хочет. И ревизия чужого кода. простановка задач и т.д. и т.п. И типичное затыкание дыр в работе со скучным "возьми из БД и отдай json в HTTP(s)"
Считал их дорогими в обслуживании, и что они слишком фиксируют внутреннюю логику, в то время как проверять надо процесс целиком
И я его понимаю. Потому что на его месте. С теми же аргументами.
Все эти аргументы можно свести к одной фразе "Сроки выпуска дистрибутива". А все что этому мешает подлежит кастрированию. В том числе и оптимизация, которая займет несколько дней, но позволит вставить красиво 51 метод за 5 минут, вместо пол дня. Но.. вероятность, что появится 52-й метод неизвестна в принципе. Да и оптимизация наверняка что то сломает неожиданное (плавали.. знаем).
Цели все же не выпустить красивый код. А просто выпустить в сроки работающее и не фатально ломающееся на основных ветках логики ПО.
Хорошо быть просто разработчиком и писать в соотвествиие со своими "внутренними потребностями прекрасного".
Я бы может быть то же писал бы юнит тесты на каждую функцию/класс (не.. не писал бы. скучно и монотонно это), но тогда это чаще всего придется делать по ночам. Так что, если есть функциональные тесты для "чернового тестирования" перед передачей в тестирование, а потом в эксплуатацию - уже хорошо. Написание тестов отдельных классов и функций отнимают времени как бы не больше чем на код, который они тестируют. А наличие таких элементарных тестов вообще не гарантирует, что хотя бы "прямой функционал" без ошибок. А функциональный тест дает хотя бы какую то уверенность, что на бою у 90-98% клиентов (которые пойдут по основной ветки логики) проблем не возникнит и сервис не ляжет.
Да статья IMHO вообще -отстой-. точнее немного поверхностная. "отстой" - не правильное слово.
Слишком много букв по поводу стандартных утилит PG и, например, ни слова про WAL (журнал PG) и методы реплицирования через него и более глубокие способы/подходы к репликации БД.
Но, впрочем, бурчать по поводу "статья отстой" можно почти многим статья в habre написанных ради "вот мой телеграм канал" и "блок компании".
Но кто то же столько + то наставил статье. Значит кому то это базовая информация по стандартным утилитам PG зашла..
Ну и автор все же птратил веремя на эксперименты и выложил результаты а не просто абстактное blabla
не знаю кто поставил минус.. Вопрос как вопрос. Другое дело что вопрос вообще не имеет отношения к бэкапам именно PG и имено как БД.
Очень частный случай для каких то не больших тестов или "поиграться".
Это какое то служебное приложение, сделанное, судя по описанию, какием то инженером из Греции для своих производственных целей. https://play.google.com/store/apps/details?id=com.ibeacon.app
Вообще взял первое попавшеся в google play, когда отлаживал сигналку и опрос BLE устройств вокруг. Чисто для тестов. Но так и оставил как "резерв", если батарейка в аппартном токене сдохнет, а нужно было что бы сигналка меня опознала.
Так что оно не самое "идеальное". Просто пример такого приложения.
Таких приложений и с иходниками много на Github и можно собрать самому под себя/свои требования. Ничего сложного в нем нет.
AirTag использует криптографию. Но, он сам генерит ключ (EC пару). Т.е. использование криптографии препятствует копированию/подделке уже активированного AirTag. Но ни как не созданю эмулятора "нового AirTag".
Cмотрел реализации ESP32 и python под Linux. По моему, там все просто. Да и сложно было разработчикам что то запихнуть сложное в BLE в advertise. Там и так они компромис искали куда засунуть публичный ключ, что бы его длинна уж совсем короткая не была и в пакет влезло (включая часть адреса).
(в проектах типа https://github.com/dchristl/macless-haystack?tab=readme-ov-file смотрел)
Кстати, про ограничение изменения адресной части BLE в Android не знал и не проверял. (тут в коментах про это упомянули. наверное есть, раз пишут)
Просто не было необходимости и не сталкивался.
Я себя сделал сигнализацию (https://habr.com/ru/articles/901352).
В основном пользуюсь дешовым BLE токеном купленным на Озоне (не AirTag). Но, заодно, нашел приложение под android для эмуляции (My iBeacons) и пользуюсь им.
Без ключей. Статический ответ на BLE SCAN (BDA).
Писать свое android приложение было лень. Поскольку есть готовые для установки (Включая с иходниками на Github). Да и метка аппаратная в кошельке валяется с правами.
Т.е. если собрать две банальности
Установил (не важно каким способом) на свой телефон трояна
Троян может что то делать. (в данном случае притворятся AirTag)
то это уже тянет на статью?
У меня уже эта фраза вызывает интоксикацию. Почему то в ушах звучит мем "Британские ученые"
Когда банальное и широкоизвестное (может быть и в узких кругах) выдают за "разработали"...
У меня претензии не к содержимому статьи. А к тому что она банальна и не интересна.IMHO.
Хотя, если для кого то открытие, что троян может сделать что угодно и что вообще есть AirTag (Samsung Galaxy SmartTag), ну тогда "ой".
Так это вообще то штатная функция AirTag. Для чего про это целую статью то.
Если смысл стать "если вы поставите трояна на свой телефон, то будет айяй" так это то же не достойно статьи.
Если что, у меня на телефоне стоит эмулятор BLE метки. Я его как токен к сигнализации использую.
Поэтому набор тривиальной информации в статье у меня вызвал сомнения в ее полезности вообще.
Длинная и многословная статья. Суть котрой сводится к "есть/бывают программы, эмулирующие AirTag".
Было бы что там эмулировать то.. Формат AirTag известен и не особо секретен.
Спасибо кэп "Очевидность".
А постоянные микросотрясения мозга не пугают? Это же накапливается.
Статью почему то хабр не позволяет сохранить отредактированную. кнопка "сохранить" деактивирована. Лень разбираться почему.
А литиево-железо-фосфатные и Литий-титанатные аккумуляторы – самый безопасный тип литиевых аккумуляторов.
Вы наверное с Li-pol перепутали (самые пожароопасные).
уже начиная с этой фразы возникают сомнения в фразе
потребление ESP32 на 3.3V при отключеном RF около 35-40mA. Ну разве что, если спать будет большую часть времени.
А так, подсчитать легко 10000/50 = 250 часов (10дней).
Продираясь про мегаподробное описание "как загрузить и установить в сервер приложение новое приложенеи через web UI администратора сервера приложений" увидил удивительный вывод, что это является уязвимостью. Вообще кроме Tomcat есть/было и другие сервера приложений и в них всегда из коробки есть страница для управления сервисами (хотя никто не мешает делать это из консоли)
Ну если ничего больше, кроме Tomcat не знаете, то да. А вообще сервера приложений вышли из моды (начали выходить плавно с 2010..2012). По ряду причин. В частности, удешевлением комп ресурсов, когда одно из преимуществ подхода "сервер приложений" = экономия на ОЗУ становится не так актуальным как проблемы поддержки/эксплуатации сервера приложенеи (падает сразу со всем приложениями и пр. подобное.. долго перечислять). Появились/развились фремвоки (SpringBoot) и либы для встраиваемых HTTP серверов. Ну и просто стало модно делать "микросервисы" (чаще всего понимая под этим HTTP+json) как отдельные OS процессы , а не war модули в сервере приложения.
написал и подумал.. А зачем писал. Статья ни о чем. Просто "вода" что бы было что опубликовать для ссылки на telegram канал. Подозреваю, что в канале такой же мусор. "Life-Hack - Хакер" ну ну... мамкин хакер.
но не удалять же..
C++ в данном случае - этопереписывание строго ПО на java. Иногда проще переписать относительно простой модуль на кросс платформенное, чем возится с..
Java мне больше нравится чем C/C++. И на том и на том давно пишу.
но очень не люблю тратить время на разбор неуловимых причин core dumbped С++ программ и возню с big|little endian, байтовыми/word выравниваниями/упаковками данных.
А это есть было и будет, если в качетве серверных платформ испольхуется не тольк x86
у меня этот режим на рабочем компе (не я включал).
Подключал новую клавиатуру - увидел.
Пока не введешь пароль с экрана на подключенной клвиатуре - она блокирована.
Может это не шатаная функция Windows. А что то специально для этого стоит.
надо будет разобраться и на домашнем ноуте включить.. Хотя я все одно все левое только в виртуалке смотрю. и незнакомые "флешки" в разъемы не пихаю.
интеграционые тесты (ну в моих реалиях) которые в коде @Testt) - это, как правило подготовленные по документации примеры "прямого пути". Т.е. пути, по которому пойдет платеж (мои реалии) для 99% клиентов. Интеграционые, потму что проверяется не функционал отдельных кусков. А все в целом (эмуляция как бою, включая работу с БД, kafka и пр.).
Понятно, что есть боковые ветки. Типичные (типа "ой денег на счете нет") то же обычно входят в интеграционный тест. Всякие не стандартные побочки ("ой БД легла", "ой память кончилась") обычно не входят.
Ну и регрессия по старым тестам и стресс тесты на нагрузку.
Но это уже перед выпуском дистрибутива, потому что долго по времени.
Как то до мышей (тесты на классы и куски кода) можно опускаться, но блин.. сроки. Так что.. редко. Если только что то сложное и легко тестируется отдельно от всего остального (типа крипто подпись проверит/создать по определенному требованию). Потому что время на выпуск ой...
Но практика показывает, что такой подход рабочий и коэф. готовности вполне укладывается под требования ЦБ.
А так, да.. гарантие отсутвие проблем в ПО - это обесточнный ЦОД с сломавшимся аварийным генератором. В остальных случаях поведение ПО предсказуемо с точностью 50 на 50 (либо работает - либо сбой). Как с динозавром на улице из анекдота.
По моей статистике, в случаях, когда судьба продукта не ясна на старте, в 90% случая он либо умирает либо не требует особого развития (живет себе и живет корявым архитектурно).
Конечно это не касается тех продуктов, судьба которых известна на старте. Типа СБП :)
Именно по моей статистике, вкладываться в архитектуру нового с расчетом, что оно взлетит это на 20% не угадать с "направление взлета" и выбранная архитектура ПО не подойдет под.
И 70% - вложения окажутся не нужными (умрет или не будет развиваться)
Остается 10% на "угадал". Печальная статистика. Чаще всего приходится переделывать практически с 0 при росте нагрузки и/или измененрия/увеличения функционала. Или мирится с корявостями, если особой оптимизации под производительность не нужно и не понятны перспективы "что дальше то с этим будет"
Потому что "не угадал" (ясновицем нужно быть что бы учеть будущие требования клиентов о которых они сами еще не знают).
Вот Ваш пример попадает под "не угадали". (ну или сделали на авось. контекста я не знаю).
нет "золотой пули"
Хм. А в перспективе 5 лет..
впрочем, тут можно только предполагать.
А разве не практикуется включать режим проверки в Windows?
Когда при включение неизвестной (не подтвержденной) клавиатуры, на экране появляется требование вести случайный текст с экрана на подключаемой клавиатуре.
По моему, 100% защита от таких вещей.
Не помню как это включается в Windows. но не суть. У меня на компе так.
Я поэтому и не стал покупать китайскую машину. Пройдет 3 года и линейка настолько сменится, что запчасти не найти в принципе. Разве что канибализмом с авторазборов умерших в авариях одногодок.
И что тогда делать?
в каждом конкретном случае, где что удобней - там и нужно.
Да еще бы с терминологией определится. Каждый свое подразумевает по "ООП".
не буде дискутировать по поводу "что такое ООП". Это как спорить "сколько ангелов на конце иглы поместится". Выродились все эти дискусси в схоластику. IMHO
Я на этом low-level отдыхаю. Только я и код и никто третий не мешает. И задачи на самом деле не тривиальные.
И это лучше, чем попытки понять что клиент хочет, да еще через менеджера посредника. А особенно, если выясняеся, что клиент сам не понимает чего хочет.
И ревизия чужого кода. простановка задач и т.д. и т.п.
И типичное затыкание дыр в работе со скучным "возьми из БД и отдай json в HTTP(s)"
И я его понимаю. Потому что на его месте. С теми же аргументами.
Все эти аргументы можно свести к одной фразе "Сроки выпуска дистрибутива".
А все что этому мешает подлежит кастрированию.
В том числе и оптимизация, которая займет несколько дней, но позволит вставить красиво 51 метод за 5 минут, вместо пол дня. Но.. вероятность, что появится 52-й метод неизвестна в принципе. Да и оптимизация наверняка что то сломает неожиданное (плавали.. знаем).
Цели все же не выпустить красивый код. А просто выпустить в сроки работающее и не фатально ломающееся на основных ветках логики ПО.
Хорошо быть просто разработчиком и писать в соотвествиие со своими "внутренними потребностями прекрасного".
Я бы может быть то же писал бы юнит тесты на каждую функцию/класс (не.. не писал бы. скучно и монотонно это), но тогда это чаще всего придется делать по ночам. Так что, если есть функциональные тесты для "чернового тестирования" перед передачей в тестирование, а потом в эксплуатацию - уже хорошо.
Написание тестов отдельных классов и функций отнимают времени как бы не больше чем на код, который они тестируют. А наличие таких элементарных тестов вообще не гарантирует, что хотя бы "прямой функционал" без ошибок.
А функциональный тест дает хотя бы какую то уверенность, что на бою у 90-98% клиентов (которые пойдут по основной ветки логики) проблем не возникнит и сервис не ляжет.