Разработчик-диабетик собрал искусственную поджелудочную железу, работающую на 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.
OpenAPS предельно проста благодаря большому собранию Bash, Python и JavaScript. В этот момент Зебеди столкнулся со стектрейсом ниже (список строк кода, которые были вызваны до возникновения в приложении сбоя).
Разработчик установил xDrip на замену Tomato. Первая — с открытым исходным кодом, что, замечает Зебеди, видно по простому дизайну.
Зебеди написал в Gitter, и через час ему помогли решить проблему: не хватало параметра dateString.
После код заработал.
Использование
Ниже — интерфейс Nightgraph. Зебеди пометил цифрами четыре основных элемента:
- Статус системы.
- Динамика уровня сахара в крови.
- Прогноз OpenAPS.
- Введение инсулина помпой.
OpenAPS каждые пять минут корректирует базальные профили, или дозировки подачи инсулина («Как OpenAPS принимает решения»). Основные параметры, которые вычисляет система:
- Разница между текущим уровнем сахара в крови и средним за последние пять минут.
- Среднее изменение уровня сахара за 15 и 45 минут.
- Количество инсулина в организме: это важно, поскольку он расходуется неинтуитивно, оставаясь в теле какое-то время, а не исчезая вместе с переработанной глюкозой.
- Чувствительность к инсулину.
Кроме того, OpenAPS замечает, когда Зебеди заболевает. За сутки до первых симптомов уровень сахара в крови у него значительно повышается.
OpenAPS, отмечает разработчик, — не панацея. Ему по-прежнему нужно принимать инсулин перед едой, да и с алкоголем система тоже не поможет. Тем не менее с OpenAPS ему гораздо удобнее и спокойнее.
На языке в котором '5' - '2' = 3, а '5' + '2' = '52' я бы как-то забоялся поджелудочную гонять 😂
Вы, возможно, не поверите, но подобное поведение довольно логично и предсказуемо, если представлять себе как устроен javascript. Если вам подобная логика не нравится - вы можете писать строго типизированный код на typescript, например, где операция '5' - '2' приведет к ошибке еще на стадии компиляции.
Или C, но это не сделает из JavaScript нормальный язык.
ваша 5-ая точка сейчас, возможно, рванёт на Марс, но JavaScript более ООП язык нежели эти самые Java, C# и их батя С++. Алан Кей и Smalltalk в помощь. поэтому нормальность крайне субъективна, особенно, если просто не разбираешься в предметной области
Не знал, что степень нормальности определяется оопностью языка. А как быть процедурным языкам? Чем Си хуже JavaScript?
Алан Кей и Smalltalk в помощь.Вообщем-то Smalltalk class-based, а JavaScript prototype-based, но заход неплохой.
поэтому нормальность крайне субъективна, особенно, если просто не разбираешься в предметной областиЭто единственное что вы правильно подметили :)
этот комментарий никак не камень в ваш огород :) и он именно ценен как цельный, поэтому я не разбивал его на части или абзацы.
Не знал, что степень нормальности определяется оопностью языка. А как быть процедурным языкам? Чем Си хуже JavaScript?я попытался именно сконцентрировать внимание на то, что многие могут заплевать лицо собеседника во время холивара, яро доказывая, что ООПшнее Java или C#, даже не рассматривая то, что оба языка идеологически парадигму ООП реализуют частично. что именно в языке с динамической типизацией реализовать ОО парадигму полностью в разы проще, а то и вообще возможно.
Вообщем-то Smalltalk class-based, а JavaScript prototype-based, но заход неплохой.на работу вы ходите в одной одежде, дома в другой, но всё равно это является одеждой, class-based и prototype-based - частным случаи ОО парадигмы.
Это единственное что вы правильно подметили :)я надеюсь, вы меня поняли и заметили, что не единственное :)
когда-то, лет эдак 5 назад, когда я ещё писал на C#, а потом на Java, мне было интересно, чего все так *банулись с этим ООП и решил хорошенько разобраться с этим веером парадигм и методологий, а сопоставив для себя более лёгкие ассоциации в голове, до сих пор, если кто на собеседованиях втирает мне про крутость ООП в каких-то только определённых языках, то стараюсь включить мозг товарищу напротив подводя его под логические умозаключения. просто, это как-то глупо выглядит, как будто сравнивать 42-ой и 43-ий размеры обуви.
p.s.: 42-ой офигенный размер, всем советую :)
Да всем пофиг на ООП. И типизация никак не связана с реализацией. Почитайте про статический полиморфизм в C++.
на работу вы ходите в одной одежде, дома в другой, но всё равно это является одеждой, class-based и prototype-based - частным случаи ОО парадигмы.Если приводить аналогии с одеждой, то как раз class-based могут быть домашней и рабочей одеждой, а в prototype-based одежда может быть только наследницей предка. Вот и получается домашняя пижама с карманами для молотка. Так в принципе и выглядят все проекты на JavaScript. Частный - не частный, из говна(ООП) может только получиться еще большее говно(прототипный ООП).
когда-то, лет эдак 5 назад, когда я ещё писал на C#, а потом на Java, мне было интересно, чего все так *банулись с этим ООП и решил хорошенько разобраться с этим веером парадигм и методологийВидимо не разобрались. ООП используют только потому, что для большинства задач ничего другого не придумали.
если кто на собеседованиях втирает мне про крутость ООП в каких-то только определённых языках, то стараюсь включить мозг товарищу напротив подводя его под логические умозаключения. просто, это как-то глупо выглядит, как будто сравнивать 42-ой и 43-ий размеры обуви.У меня для вас плохие новости. В нормальных компаниях уже давно не спрашивают про языки. Язык это инструмент, который можно освоить за день(Python, Golang, JavaScript) или за несколько месяцев(C++). Опять же, т.к. пока не придумали ничего лучше, то решили спрашивать на собеседованиях алгоритмические задачи. И часто эти алгоритмические задачи разрешают писать вообще псевдокодом.
ОО парадигма подразумевает, что всё есть объект, даже if и else конструкции.
да пофиг, используют или не используют ООП, назови это хоть палкой. многие думают, что знают досконально, и не подвергают эти якобы знания сомнению. а на самом деле получается, что им вбили в головы, то и транслируют потом везде и всюду.
апосля возникают такие срачи с поливанием говна. возможно, это всё шутеечки, но я это нахожу крайне глупым.
почитайте хотя бы википедию что-ли, уж честное слово стыдно за ваши знания. а лучше почитайте Алана Кэйя, это тот чувак который ООП и придумал.
ООП этого не подразумевает. То о чем вы говорите относится уже к дизайну самого языка, который может использовать функции/переменные как first class citizen. C не ООП, но позволяет использовать указатель и как функцию. Становится он от этого ООП?
я не пытаюсь вас переубедить, и так уже наша беседа зашла слишком далеко так как мы всё же общаемся на разных "волнах", просто попробуйте взглянуть с другой стороны хотя бы на определение - https://en.wikipedia.org/wiki/Object-oriented_programming, - возможно, вы меня поймёте :) пусть каждый и останется со своим мнением
Да, я совершенно не понимаю как ООП может сделать из языка, который складывает строковые литералы с цифрами нормальный язык.
если вам на самом деле интересно разобраться, то я могу попытаться объяснить.
в JavaScript есть несколько так называемых "примитивных" типов, к ним как раз и относятся строки и числа, примитивные они по тому, что могут хранить только одно значение (если это строка, то только строка, если число, то только число), но они тоже являются объектами только иммутабельными. у строк и даже чисел можно вызывать методы без дополнительных обёрток как в некоторых других языках. это всё делает под "капотом" интерпретатор.
так вот, когда мы складываем строку и число, это, внезапно, не что иное как перегрузка операторов (полиморфизм, все дела). только вот JavaScript интерпретатор поверил в свои силы и предоставляет неявные правила приведения типов.
плохо это или хорошо, это просто особенность языка, которую нужно знать. у PHP, Lua и даже Groovy есть похожие или такие же особенности, может языков с такой особенностью больше. становятся ли они все из-за этого "ненормальными"? что вообще подразумевается под "нормальностью"? лично мне JS крайне нравится, но с ним надо держать ухо востро, так как слишком много позволяет, но я ему это прощаю за его гибкость.
Примитивными называются те типы, которые язык умеет из коробки. Tuple, List, Hash/TreeTable вполне могут быть примитивныеми типами в некоторых реализациях Lisp, Python и том же JS, при этом они хранят больше одного значения.
у строк и даже чисел можно вызывать методы без дополнительных обёрток как в некоторых других языках. это всё делает под "капотом" интерпретатор.Это называется приведение типов, а не дополнительные методы. Как это реализовано уже зависит от компилятора/интерпретатора и конечно же для некоторых типов оно может быть explicit, для некоторых implicit. Ну и мутабельность это вообще из другой оперы.
так вот, когда мы складываем строку и число, это, внезапно, не что иное как перегрузка операторов (полиморфизм, все дела). только вот JavaScript интерпретатор поверил в свои силы и предоставляет неявные правила приведения типов.Это как раз проверка типов и наличие адекватного стандарта, где должно быть прописано, что char + int это нормально, т.к. по сути это одно и тоже. А вот char[], т.е. строка + int - уже совсем другой случай в котором невозможно прописать правила, т.к. неизвестно что к чему приводить.
плохо это или хорошо, это просто особенность языка, которую нужно знать. у PHP, Lua и даже Groovy есть похожие или такие же особенности, может языков с такой особенностью больше. становятся ли они все из-за этого "ненормальными"? что вообще подразумевается под "нормальностью"? лично мне JS крайне нравится, но с ним надо держать ухо востро, так как слишком много позволяет, но я ему это прощаю за его гибкость.Поэтому и facebook отказался от PHP, сделав Hack. Два других используются как DSL.
я вам о мягком, вы мне о горячем, я вам о круглом, вы мне о красном. вы даже не пытаетесь вчитываться. читаю ваши ответы и просто постоянный фейспалм ловлю от того, что вы меня не слышите абсолютно. я вижу, что вы компетентны, так как понимаете о чём пишете, но, возможно, из-за так называемой сверхкомпетентности, а может из-за недальновидности, я не знаю, вы даже не пытаетесь критически обдумывать мои ответы, а просто агритесь. даже в прошлом комментарии я писал исключительно про JS, даже акцентировал на это внимание. увы, наша с вами полемика так и не перешла в дискуссию, посему, считаю дальнейшее обсуждение (даже хер знает можно ли это вообще обсуждением то назвать) бессмысленным.
https://www.youtube.com/watch?v=xE8tL8NdHaY это дикий баян, но все же. Есть ли какие-то причины иметь столько возможностей отстрелить себе ногу?
https://glot.io/snippets/fh3nmzqe1h
если я работаю с каким-то языком, то я стараюсь по возможности узнать об особенностях компилятора/интерпретатора, так как в каждом какие-то да найдутся, не существует идеального языка. мне лично в каждом что-то не нравится, но если он решает какую-то предметную задачу, то какая проблема?! если вам это смущает, обходите мимо, зачем ныть?! веб без JS на текущий момент времени невозможен, так что, либо приходится адаптироваться, либо нахер с пляжа. я выбрал 1-ый вариант и неплохо себя чувствую. если у вас полыхает 5-ая точка, не пользуйтесь им, зарабатывайте на хлеб с маслом тем, что вам нравится. всё остальное я уже пояснил выше.
Мы опять же о том, что язык плохо спроектирован. Это не его особенности. Особенности - это, например, Монады. А то что вы приводите - косяк проектирования. Можно конечно с этим жить, но язык от этого лучше не станет.
груви тоже плохо спроектирован? может кложура или даже скала?