Я бы сказал даже еще проще — забить тревогу (разбудить) в случае снижения уровня сахара ниже критического. Особенно это касается ночных гипогликемий, когда человек сам не отдаёт отчёта о своём состоянии.
Не всё так однозначно, если учесть сколько всего ФС пихает в память и ARC/ZIL. Тестировал при помощи утилиты ioping на VM-ках и цифры на ZFS всегда были на порядок выше. Например если на ufs/ext3/ext4 ~2k, то на ZFS ~70-80k. Шпинделя были одни и те же.
C методикой тестирования действительно надо бы определиться что бы не сравнивать разрозненные величины. Для меня это так и осталось открытым вопросом.
Пока не сдался последний разработчик, есть шанс, что плохой финал во всяком случае отодвигается на неопределённо долгий срок. Тут можно подойти с философской точки зрения и подумать о том, что наверняка лет через 10-20, даже при наличии постоянного интереса к продукту, его невозможно будет оставить на той базе и в том виде, что он есть сейчас. Всё равно переписывать :)
Почему-то все 3 способа, приведённые автором в переломном моменте, подразумевают несчастный финал, особенно если пройти по ссылкам далее. Вывод тоже неутешительный.
У нас в компании с одним веб-проектом была похожая ситуация, когда код, полученный от аутсорсеров после сдачи бизнесу фактически нельзя было ни развивать ни нормально править на месте.
Первая реакция местных программистов была именно такая — «выкинуть и всё переписать с нуля», но объём проекта и сроки, данные на исправление от такого шага оградили. Наверное произошло то, что кто-то назвал «масштабным рефакторингом», хотя в нашем случае мы просто «выкинули всё ненужное и непонятное». Сократили в результате код на 25% одновременно улучшив лог и управление исключениями. Всё, что касается бэкенда получилось на мой взгляд неплохо — тесты уже прошли, релиз через 2 дня. Вот с фронтендом ситуация намного хуже. Боюсь, что там придётся таки идти на шаг «переписать всё с нуля» — уж больно динамичен характер мира фреймворков для веба, особенно когда стандартные компоненты типа Vue, VueMaterial смачно сдабриваются сторонними и кастомными компонентами.
Да, ваше внутреннее чувство вас не подводит — это действительно вундервафля. Ванильный спринг более предсказуем, понятен и лучше документирован. Последние версии JHipstera нам уже не поддались из-за ошибок YARNA при апгрейде. В ходе «даунгрейда» столкнулись с множеством связей во внешних модулях. Например при наличии актуатора и модуля LDAP автоматически включался мониторинг, который делал 5 AD логинов в секунду с pod-а. Отловили только tcpdump-ом. И в Hibernate он свои щупальца запускает, в общем везде, где нужна «оптимизация» с его точки зрения.
Нужно наверное быть разработчиком JHipster что бы использовать его без сайд-эффектов.
У нас был проект, написанный для Кубернетес-а аутсорсерами со всеми зависимостями — API Gateway, Jhipster registry, Hazelcast, etc. Вычищать JHipster пришлось почти месяц. Редуцировали как раз до модели Spring Boot + Vue + REST.
быстрее, то быстрее, но это такой случай, который в дальнейшем может сыграть злую шутку и придётся откатываться на вариант, предложеный автором, который действительно довольно распространёт. Лучше сразу самостоятельно определить компоненты и роли, чем давать внешнему генератору «сделать всё за тебя»
Александр, вашей любознательности и упорству нужно поставить памятник! Вы и сами видите, что большинство пользователей удивлены до крайности возможностью «собрать ядерный реактор на кухне».
После прочтения статьи осталось несколько вопросов. Буду признателен, если сможете на них ответить:
1. Зачем было реверсить сам рН-чип — неужели его контроллер + программа сложнее? Не было бы проще отреверсить «обвес», а чип просто пользовать «как есть»?
2. Если восстановление рН-чипа вполне реальная и недорогая операция, то неужели производитель этого не знает? Всё таки сумма устройства настолько высока, что проблема восстановления работоспособности такого дорогого компонента просто необходимость номер 1. Это не картридж в принтере перезаправить. Может быть вы что-то упустили?
война с бухгалтерией — это тема отдельного поста! А не пробовали взвесить финансово переезд в облако? Для небольших фирм самое то. Железо поддерживать/амортизировать не нужно. Стоимость небольшой машины — копейки. 1RU + канал в ЦОД-е стоят поди как 3-4 средних сервера у Амазона, нет? Есть и у такого подхода, конечно, минусы, но одиночный сервер в ЦОДе выглядит как половинчатое решение.
если задача стоит настолько серьёзно, то да — «правильное финансирование» это правильный термин. Я бы сказал, что метеорит — это крайний случай и для большинства компаний пожалуй не подойдёт. Но купить 2-й сервер и поставить его в том же DC стоит как правило не настолько дорого, что бы концентрироваться на решении проблем с памятью одиночного устройства. Я к тому, что резервировать сервер целиком всё равно нужно.
Не умаляя важности выбора памяти для серверов, хочу заметить, что автор излишне сгущает краски вокруг отказа одиночного сервера. При правильной архитектуре отказа в обслуживании (того же е-commerce) не происходит, потому что ре-балансировка кластера происходит практически мгновенно. Никто же не удивляется, когда у сервера диск в RAID-e летит или БП сгорает. Давно уже научились работать с такого рода проблемами и сервер целиком тут не исключение. Правильное резервирование снимает проблему «заменить память за 2-3 ч. в любое время суток».
Автор мог бы рассказать, в качестве вводной информации для непосвящённых, о разных диабетах (1-й и 2-й тип) и о разных подходах леченения этой непростой болезни (инсулин / таблетки). Дальше по тексту — очень хороший материал. Я давно не встречал такой подборки в одном месте.
Как человек, знакомый с проблемой не по наслышке, скажу — неинвазивные глюкометры очень нужны. В первую очередь (а может и единственное для чего они нужны) это подозрение на гипогликемию. Высокий сахар в крови опасен, когда он действует долгое время, а внезапная «гипа» может не только в кому вогнать, но и вообще привести к смерти. Мониторинг 3-4-100 раз в сутки, сами понимаете, не гарантирует того, что гипогликемия будет обнаружена. Порой она развивается очень стремительно.
Сложность неинвазивного метода определения — собственно сам метод. Точнее его отсутствие. Ни температура, ни влажность кожи, ни пульс, ни проводимость кожи не являются достаточно надёжными источниками входной информации. Даже для одного человека эти параметры сильно варьируются, а что бы сделать прибор, который подходил бы всем — это практически нереально.
У меня есть пара идей как это можно было бы сделать, но подтвердить я их, к сожалению, не могу.
Один из методов, который мог бы сработать, это постоянное наблюдение за пациентом персонального прибора — монитора, который бы создавал локальную базу симптомов и регистрировал наличие гипогликемии от инвазивного аппарата вручную. Потом, со временем, когда статистика накопится, он мог бы подавать сигнал при получении похожих симптомов. Своего рода обучаемая экспертная система в рамках индивидуума.
C методикой тестирования действительно надо бы определиться что бы не сравнивать разрозненные величины. Для меня это так и осталось открытым вопросом.
У нас в компании с одним веб-проектом была похожая ситуация, когда код, полученный от аутсорсеров после сдачи бизнесу фактически нельзя было ни развивать ни нормально править на месте.
Первая реакция местных программистов была именно такая — «выкинуть и всё переписать с нуля», но объём проекта и сроки, данные на исправление от такого шага оградили. Наверное произошло то, что кто-то назвал «масштабным рефакторингом», хотя в нашем случае мы просто «выкинули всё ненужное и непонятное». Сократили в результате код на 25% одновременно улучшив лог и управление исключениями. Всё, что касается бэкенда получилось на мой взгляд неплохо — тесты уже прошли, релиз через 2 дня. Вот с фронтендом ситуация намного хуже. Боюсь, что там придётся таки идти на шаг «переписать всё с нуля» — уж больно динамичен характер мира фреймворков для веба, особенно когда стандартные компоненты типа Vue, VueMaterial смачно сдабриваются сторонними и кастомными компонентами.
Нужно наверное быть разработчиком JHipster что бы использовать его без сайд-эффектов.
После прочтения статьи осталось несколько вопросов. Буду признателен, если сможете на них ответить:
1. Зачем было реверсить сам рН-чип — неужели его контроллер + программа сложнее? Не было бы проще отреверсить «обвес», а чип просто пользовать «как есть»?
2. Если восстановление рН-чипа вполне реальная и недорогая операция, то неужели производитель этого не знает? Всё таки сумма устройства настолько высока, что проблема восстановления работоспособности такого дорогого компонента просто необходимость номер 1. Это не картридж в принтере перезаправить. Может быть вы что-то упустили?
Как человек, знакомый с проблемой не по наслышке, скажу — неинвазивные глюкометры очень нужны. В первую очередь (а может и единственное для чего они нужны) это подозрение на гипогликемию. Высокий сахар в крови опасен, когда он действует долгое время, а внезапная «гипа» может не только в кому вогнать, но и вообще привести к смерти. Мониторинг 3-4-100 раз в сутки, сами понимаете, не гарантирует того, что гипогликемия будет обнаружена. Порой она развивается очень стремительно.
Сложность неинвазивного метода определения — собственно сам метод. Точнее его отсутствие. Ни температура, ни влажность кожи, ни пульс, ни проводимость кожи не являются достаточно надёжными источниками входной информации. Даже для одного человека эти параметры сильно варьируются, а что бы сделать прибор, который подходил бы всем — это практически нереально.
У меня есть пара идей как это можно было бы сделать, но подтвердить я их, к сожалению, не могу.
Один из методов, который мог бы сработать, это постоянное наблюдение за пациентом персонального прибора — монитора, который бы создавал локальную базу симптомов и регистрировал наличие гипогликемии от инвазивного аппарата вручную. Потом, со временем, когда статистика накопится, он мог бы подавать сигнал при получении похожих симптомов. Своего рода обучаемая экспертная система в рамках индивидуума.