Разработчик-диабетик собрал искусственную поджелудочную железу, работающую на JavaScript​ Статьи редакции

Лиаму Зебеди понадобились инсулиновая помпа, пара контроллеров и несколько программ с открытым исходным кодом.

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

  • Диабетики принимают инсулин для усвоения углеводов, по наитию определяя дозировки. В разной пище — разное количество углеводов со своим гликемическим индексом (скоростью усвоения). Законы разрешают производителям закладывать в информацию о пищевой ценности отклонения до 10% от того или иного значения.
  • Плохой сон нарушает метаболизм, при пробуждении инсулина требуется больше — как и при стрессе или болезни.
  • Организм менее восприимчив к инсулину, когда уровень сахара в крови больше положенного.

Диабетики, контролируя приём инсулина, занимаются математической оптимизацией, считает Зебеди. Его искусственная поджелудочная железа занимается тем же самым, только процесс на 80% автоматизирован.

Оборудование

  • Глюкометр FreeStyle Libre CGM.
  • Трансмиттер Miaomiao — передаёт данные с Libre (работает на NFC) на телефон по Bluetooth.
  • Nightscout — программа с открытым исходным кодом для хранения и визуализации данных для диабетиков первого типа (инсулин практически не вырабатывается организмом). Хостинг — Heroku.
  • Приложение xDrip, которое принимает данные по Bluetooth и отправляет их в Nightscout.
  • Инсулиновая помпа Medtronic — для инъекций инсулина.
  • Intel Edison + Explorer HAT — плата с поддержкой Wi-Fi и радиокоманд частотой 900 МГц.
  • Аккумулятор на 4400 мА.
  • OpenAPS — «операционная система» искусственной поджелудочной. Выгружает данные из Nightscout, прогнозирует и подстраивает доставку инсулина помпой, подгружает данные в Nightscout для непрерывного отслеживания. Исходный код открыт.

Цены

  • Помпа у разработчика уже была, стоит она, как правило, около €3100.
  • FreeStyle Libre CGM — €70 за считыватель (разовая трата) и €140 в месяц на сенсоры.
  • Трансмиттер Miaomiao — €200.
  • Хостинг Heroku для Nightscout — бесплатно.
  • xDrip — Зебеди пришлось купить годовую лицензию разработчика за €93, чтобы установить программу на телефон: Apple запрещает его загрузку в App Store.
  • Intel Edison обошёлся в €57. Мини-компьютер не продаётся уже два года, поэтому пришлось как следует поискать на Amazon и eBay.
  • Explorer HAT — плату изготовила компания Enhanced Radio в США за €68.
  • Аккумулятор Adafruit за €50 ёмкостью в два раза больше нужной — просто на всякий случай.
  • OpenAPS — бесплатно, открытый исходный код.

Итого, исключая помпу: €608.

Ежемесячные траты, исключая инсулин: €140.

Сборка

На сборку Зебеди потратил около девяти часов:

  • Час на чтение документации по OpenAPS, она очень большая.
  • Два часа на загрузку Jubilinux и настройку Edison.
  • Два с половиной часа на загрузку пакетов и библиотек с помощью APT и NPM. Поскольку OpenAPS — обычный набор простейших Bash-скриптов, всё пришлось загружать заново.
  • Час на покупку лицензии разработчика Apple и установку xDrip.
  • Час на настройку хостинга для Nightscout, с аутентификацией и особыми плагинами для OpenAPS.
  • Два часа на устранение багов. Система почему-то не считывала показатели из Nightscout. Не сумев устранить неполадки, Зебеди обратился за помощью в Gitter. Оказалось, проблема была в приложении Tomato, которым он пользовался для отслеживания уровня сахара в крови. Поэтому разработчик переключился на xDrip.
​Все нужные детали
​Трансмиттер Miaomiao
​Инсулиновые помпы (Зебеди использовал нижнюю)
​Модуль Intel Edison
​Подключение к модулю Edison через USB Serial. Зебеди использовал путь /dev/tty.usbserial-xyz 115200
​Установка Jubilinux
​Настройка протоколов SSH
​Лог OpenAPS

OpenAPS предельно проста благодаря большому собранию Bash, Python и JavaScript. В этот момент Зебеди столкнулся со стектрейсом ниже (список строк кода, которые были вызваны до возникновения в приложении сбоя).

myopenaps/monitor/glucose.json: Unexpected end of JSON input

Разработчик установил xDrip на замену Tomato. Первая — с открытым исходным кодом, что, замечает Зебеди, видно по простому дизайну.

​Интерфейс xDrip

Зебеди написал в Gitter, и через час ему помогли решить проблему: не хватало параметра dateString.

​Сообщение Зебеди

После код заработал.

Использование

Ниже — интерфейс Nightgraph. Зебеди пометил цифрами четыре основных элемента:

  1. Статус системы.
  2. Динамика уровня сахара в крови.
  3. Прогноз OpenAPS.
  4. Введение инсулина помпой.

OpenAPS каждые пять минут корректирует базальные профили, или дозировки подачи инсулина («Как OpenAPS принимает решения»). Основные параметры, которые вычисляет система:

  • Разница между текущим уровнем сахара в крови и средним за последние пять минут.
  • Среднее изменение уровня сахара за 15 и 45 минут.
  • Количество инсулина в организме: это важно, поскольку он расходуется неинтуитивно, оставаясь в теле какое-то время, а не исчезая вместе с переработанной глюкозой.
  • Чувствительность к инсулину.
Средний уровень сахара в крови — производная от предыдущих средних показателей, а количество инсулина в организме представляет собой экспоненциальную кривую Документация OpenAPS

Кроме того, OpenAPS замечает, когда Зебеди заболевает. За сутки до первых симптомов уровень сахара в крови у него значительно повышается.

OpenAPS, отмечает разработчик, — не панацея. Ему по-прежнему нужно принимать инсулин перед едой, да и с алкоголем система тоже не поможет. Тем не менее с OpenAPS ему гораздо удобнее и спокойнее.

​Собранное устройство
​Слева — трансмиттер Miaomiao, справа — датчик глюкометра
​Инсулиновая помпа
0
51 комментарий
Написать комментарий...
Звенислав Николаевич

На языке в котором '5' - '2' = 3, а '5' + '2' = '52' я бы как-то забоялся поджелудочную гонять 😂

Ответить
Развернуть ветку
Алексей Заузин

Вы, возможно, не поверите, но подобное поведение довольно логично и предсказуемо, если представлять себе как устроен javascript. Если вам подобная логика не нравится - вы можете писать строго типизированный код на typescript, например, где операция '5' - '2' приведет к ошибке еще на стадии компиляции.

Ответить
Развернуть ветку
Гала Перидоловна

Или C, но это не сделает из JavaScript нормальный язык. 

Ответить
Развернуть ветку
Andrei Shostik

ваша 5-ая точка сейчас, возможно, рванёт на Марс, но JavaScript более ООП язык нежели эти самые Java, C# и их батя С++. Алан Кей и Smalltalk в помощь. поэтому нормальность крайне субъективна, особенно, если просто не разбираешься в предметной области

Ответить
Развернуть ветку
Гала Перидоловна
ваша 5-ая точка сейчас, возможно, рванёт на Марс, но JavaScript более ООП язык нежели эти самые Java, C# и их батя С++.

Не знал, что степень нормальности определяется оопностью языка. А как быть процедурным языкам? Чем Си хуже JavaScript?

Алан Кей и Smalltalk в помощь.

Вообщем-то Smalltalk class-based, а JavaScript prototype-based, но заход неплохой.

поэтому нормальность крайне субъективна, особенно, если просто не разбираешься в предметной области

Это единственное что вы правильно подметили :)

Ответить
Развернуть ветку
Andrei Shostik

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

Не знал, что степень нормальности определяется оопностью языка. А как быть процедурным языкам? Чем Си хуже JavaScript?

я попытался именно сконцентрировать внимание на то, что многие могут заплевать лицо собеседника во время холивара, яро доказывая, что ООПшнее Java или C#, даже не рассматривая то, что оба языка идеологически парадигму ООП реализуют частично. что именно в языке с динамической типизацией реализовать ОО парадигму полностью в разы проще, а то и вообще возможно.

Вообщем-то Smalltalk class-based, а JavaScript prototype-based, но заход неплохой.

на работу вы ходите в одной одежде, дома в другой, но всё равно это является одеждой, class-based и prototype-based - частным случаи ОО парадигмы. 

Это единственное что вы правильно подметили :)

я надеюсь, вы меня поняли и заметили, что не единственное :)

когда-то, лет эдак 5 назад, когда я ещё писал на C#, а потом на Java, мне было интересно, чего все так *банулись с этим ООП и решил хорошенько разобраться с этим веером парадигм и методологий, а  сопоставив для себя более лёгкие ассоциации в голове, до сих пор, если кто на собеседованиях втирает мне про крутость ООП в каких-то только определённых языках, то стараюсь включить мозг товарищу напротив подводя его под логические умозаключения. просто, это как-то глупо выглядит, как будто сравнивать 42-ой и 43-ий размеры обуви.

p.s.: 42-ой офигенный размер, всем советую :) 

Ответить
Развернуть ветку
Гала Перидоловна
я попытался именно сконцентрировать внимание на то, что многие могут заплевать лицо собеседника во время холивара, яро доказывая, что ООПшнее Java или C#, даже не рассматривая то, что оба языка идеологически парадигму ООП реализуют частично. что именно в языке с динамической типизацией реализовать ОО парадигму полностью в разы проще, а то и вообще возможно.

Да всем пофиг на ООП. И типизация никак не связана с реализацией. Почитайте про статический полиморфизм в C++.

на работу вы ходите в одной одежде, дома в другой, но всё равно это является одеждой, class-based и prototype-based - частным случаи ОО парадигмы.

Если приводить аналогии с одеждой, то как раз class-based могут быть домашней и рабочей одеждой, а в prototype-based одежда может быть только наследницей предка. Вот и получается домашняя пижама с карманами для молотка. Так в принципе и выглядят все проекты на JavaScript. Частный - не частный, из говна(ООП) может только получиться еще большее говно(прототипный ООП).

когда-то, лет эдак 5 назад, когда я ещё писал на C#, а потом на Java, мне было интересно, чего все так *банулись с этим ООП и решил хорошенько разобраться с этим веером парадигм и методологий

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

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

У меня для вас плохие новости. В нормальных компаниях уже давно не спрашивают про языки. Язык это инструмент, который можно освоить за день(Python, Golang, JavaScript) или за несколько месяцев(C++). Опять же, т.к. пока не придумали ничего лучше, то решили спрашивать на собеседованиях алгоритмические задачи. И часто эти алгоритмические задачи разрешают писать вообще псевдокодом.

Ответить
Развернуть ветку
Andrei Shostik

ОО парадигма подразумевает, что всё есть объект, даже if и else конструкции.

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

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

Ответить
Развернуть ветку
Гала Перидоловна

ООП этого не подразумевает. То о чем вы говорите относится уже к дизайну самого языка, который может использовать функции/переменные как first class citizen. C не ООП, но позволяет использовать указатель и как функцию. Становится он от этого ООП?

Ответить
Развернуть ветку
Andrei Shostik

я не пытаюсь вас переубедить, и так уже наша беседа зашла слишком далеко так как мы всё же общаемся на разных "волнах", просто попробуйте взглянуть с другой стороны хотя бы на определение - https://en.wikipedia.org/wiki/Object-oriented_programming, - возможно, вы меня поймёте :) пусть каждый и останется со своим мнением  

Ответить
Развернуть ветку
Гала Перидоловна

Да, я совершенно не понимаю как ООП может сделать из языка, который складывает строковые литералы с цифрами нормальный язык. 

Ответить
Развернуть ветку
Andrei Shostik

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

в JavaScript есть несколько так называемых "примитивных" типов, к ним как раз и относятся строки и числа, примитивные они по тому, что могут хранить только одно значение (если это строка, то только строка, если число, то только число), но они тоже являются объектами только иммутабельными. у строк и даже чисел можно вызывать методы без дополнительных обёрток как в некоторых других языках. это всё делает под "капотом" интерпретатор.

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

плохо это или хорошо, это просто особенность языка, которую нужно знать. у PHP, Lua и даже Groovy есть похожие или такие же особенности, может языков с такой особенностью больше. становятся ли они все из-за этого "ненормальными"? что вообще подразумевается под "нормальностью"? лично мне JS крайне нравится, но с ним надо держать ухо востро, так как слишком много позволяет, но я ему это прощаю за его гибкость.

Ответить
Развернуть ветку
Гала Перидоловна
в JavaScript есть несколько так называемых "примитивных" типов, к ним как раз и относятся строки и числа, примитивные они по тому, что могут хранить только одно значение (если это строка, то только строка, если число, то только число),

Примитивными называются те типы, которые язык умеет из коробки. Tuple, List, Hash/TreeTable вполне могут быть примитивныеми типами в некоторых реализациях Lisp, Python и том же JS, при этом они хранят больше одного значения.

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

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

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

Это как раз проверка типов и наличие адекватного стандарта, где должно быть прописано, что char + int это нормально, т.к. по сути это одно и тоже. А вот char[], т.е. строка + int - уже совсем другой случай в котором невозможно прописать правила, т.к. неизвестно что к чему приводить.

плохо это или хорошо, это просто особенность языка, которую нужно знать. у PHP, Lua и даже Groovy есть похожие или такие же особенности, может языков с такой особенностью больше. становятся ли они все из-за этого "ненормальными"? что вообще подразумевается под "нормальностью"? лично мне JS крайне нравится, но с ним надо держать ухо востро, так как слишком много позволяет, но я ему это прощаю за его гибкость.

Поэтому и facebook отказался от PHP, сделав Hack. Два других используются как DSL.

Ответить
Развернуть ветку
Andrei Shostik

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

Ответить
Развернуть ветку
Гала Перидоловна

https://www.youtube.com/watch?v=xE8tL8NdHaY это дикий баян, но все же. Есть ли какие-то причины иметь столько возможностей отстрелить себе ногу?

Ответить
Развернуть ветку
Andrei Shostik

https://glot.io/snippets/fh3nmzqe1h

если я работаю с каким-то языком, то я стараюсь по возможности узнать об особенностях компилятора/интерпретатора, так как в каждом какие-то да найдутся, не существует идеального языка. мне лично в каждом что-то не нравится, но если он решает какую-то предметную задачу, то какая проблема?! если вам это смущает, обходите мимо, зачем ныть?! веб без JS на текущий момент времени невозможен, так что, либо приходится адаптироваться, либо нахер с пляжа. я выбрал 1-ый вариант и неплохо себя чувствую. если у вас полыхает 5-ая точка, не пользуйтесь им, зарабатывайте на хлеб с маслом тем, что вам нравится. всё остальное я уже пояснил выше.

Ответить
Развернуть ветку
Гала Перидоловна

Мы опять же о том, что язык плохо спроектирован. Это не его особенности. Особенности - это, например, Монады. А то что вы приводите - косяк проектирования. Можно конечно с этим жить, но язык от этого лучше не станет. 

Ответить
Развернуть ветку
Andrei Shostik

груви тоже плохо спроектирован? может кложура или даже скала? 

Ответить
Развернуть ветку
48 комментариев
Раскрывать всегда