Получается, что с точки зрения программиста (которому всё равно нельзя лазить на Production серверы) Nano Server не отличается от полновесного Windows Server — в обоих есть полноценный IIS.
А у админов теперь выбор — выучить новые cmdlet-ы и радоваться легковесным виртуальным машинам, или и дальше пользоваться Windows Server, платя, тем самым, «налог на незнание PowerShell».
Учитывая тенденцию нарезать бизнес-логику маленькими независимыми кусочками микросервисов, перспектива хостить на одном Hyper-V несколько десятков лёгких VM с Nano Server весьма заманчива.
То-есть область применения можно сформулировать следующим образом:
Если нужна кросс-платформенность, то надо брать Core. Главная цель — докер, который нам люб за то, что когда программист говорит «готово», то результатом является контейнер, который однозначно описывает систему во всех видах установки, от DEV до Production. Тем самым на корню устраняются проблемы вида «а у меня на компьютере всё работает». Ценой является отказ от бесплатных плюшек IIS вроде gzip-упаковки или Windows-аутентификации.
Если контейнеры нам пока не светят, например по организационным причинам, то полезность Core в нынешнем его состоянии не очевидна. Да, сегодня разработчики выдают при релизе 20 Мб DLL-ек, которые отдельная Infrastructure-команда устанавливает на заботливо оберегаемом ими Windows Server 2012, а завтра программисты будут выдавать лишь 2 Мб, а остальные 18 Мб сервер сам скачает из NuGet, но правил игры это не меняет. Сервер остаётся «pet, not cattle».
Замена тяжеловесного сервера на Nano порадует сисадминов, которым мучительно больно смотреть на расходуемые зря гигабайты, но мало что изменит для программистов.
Как раз OWIN мы уж 2 года используем со старым-добрым .NET 4.5-4.6, вместе с классическим IIS.
Началось всё с тестирования микросервисов на WEB API 2, приятно когда в две строчки можно поднять в памяти весь сервис и проверять правильность на уровне HTTP Request/Response, в том числе и правильную обработку HTTP-Headers и кодов возврата. А потом как-то незаметно переползло и в обычные веб-приложения. OWIN там не даёт особых преимуществ, но просто приятно убрать всё лишнее из global.asax, в котором отовсюду торчат уши HttpHandler (каковым и являлся ASP.NET в 2002 году).
Не могли бы вы рассказать поподробнее для каких сценариев предназначается Nano Server?
В ссылке на официальную документацию в начале статьи говорится об использовании в качестве хоста для Hyper-V, однако в примерах наоборот, сам Nano Server это виртуальная машина.
В чём по вашему мнению преимущества .NET Core + Nano перед классическим ASP.NET MVC (OWIN) на полновесной ОС, тем более что вы всё равно используете IIS? Какие реальные проблемы решает связка c Nano?
Некоторые недостатки у Core есть, например пока отсутствует System.Drawing, которой мы используем для масштабирования JPEG-ов. Что оправдывает цену перехода на новую технологию? Может Deployment? Но, как я понимаю, даже облегчённая версия Windows слишком велика чтоб сделать весь образ артефактом который поставляют разработчики — копирование образа займёт слишком много времен.
Одним словом, чем по вашему мнению интересен Nano Server? Грубо говоря, чем он лучше полновесной Windows с одной стороны и Docker-а с другой?
/* Сухой маркетинговый язык страниц MSDN уже читал, хочется знать мнение реально работающих с этой технологией */
Яд нужно хранить и транспортировать в строго регламентированных условиях, специально обученным персоналом. После применения нужно надолго огородить место и гаранитировать что приманка случайно не попадёт в руки какого-нибудь ребёнка. Даже если вероятность несчастного случая мизерна, не забываем что речь идёт о стране адвокатов и многомилионных исков по любому поводу.
Полная стоимость применения яда и гарантированного устранения последствий намного выше цены собственно химикалий, а после CO2-атаки достаточно просто проветрить.
Врач начинает осмотр с измерения температуры и давления. Да, есть сотни разных болезней и других причин для повышенной температуры, и это крайне неточная метрика, но она проста в измерении и позволяет быстро определить кому из пациентов нужно уделить больше внимания. Больному с жаром назначают дополнительные, более точные, анализы.
Grafana хороша чтоб с одного взгляда на необычную загрузку процессора, памяти или долгое время отклика определить, что пора вызывать программистов. А вот они для вылавливания багов полезут в хранящиеся в Elasticsearch логи, потому как «средняя температура по больнице» недостаточно точный инструмент.
Кибана в роли Dashboard это действительно «для хипстеров». Она хороша как интерактивный инструмент, а для висящего под потолком телевизора подходит плохо.
У ELK-стека другой предназначение, он хорош для логов, которые содержат текстовые сообщения, структурированные или не очень. Так что это не альтернатива, а дополнение к описанным выше технологиям.
Метрики это числа, их можно естественным образом агрегировать и сжимать по времени. Данные за сегодня храним с разрешением в одну секунду, метрики за прошлый месяц усредняем поминутно, а для сравнения нынешнего года с предыдущим достаточно знать старые метрики с разрешением в час. Данные никогда полностью не удаляются, просто становятся менее подробными по мере устаревания.
Elasticsearch такого не может, да и бессмысленно это, усреднять текстовые данные. Зато хорошо помогает в поиске и устранении ошибок. Ограниченное время хранения (дни, недели) — не помеха, всё равно крайне редко интересует stack-trace исключения годичной давности. Баги обычно нужно фиксить здесь и сейчас. Декорирование записей тэгами также очень удобно, например у нас микросервисы вызывают друг-друга и каждый пишет в логи общий для всей цепочки correlation-id. Когда сервис в глубине системы рушится, в Кибане можно в пару кликов вывести всю цепочку вызовов приведшую к проблеме.
Понятно, что Kibana имеет простенькие средства агрегирования и примтивную математику по цифровым полям, так что при большом желании можно использовать её и для показа метрик, но остаются проблемы с историческими данными, плюс на средства визуализации невозможно смотреть без слёз. Например есть бессмысленный pie-chart, но нет горизонтального bar-chart. Хорошо хоть у Elasticsearch есть простой и понятный REST-API, так что легко приделать собственный интерфейс. Мы писали собственные плагины к AtlasBoard, которые тянут данные из ElasticSearch и показывают JavaScript-ом в браузере, благо графических JS-библиотек есть немерено, на любой вкус и цвет.
По моему мнению, Nagios+Grafana хорошо подходят для мониторинга железа, и «больших технологий» общих для всех, например «мы хостим веб-сайт». ELK хорош, если важна специфика работы конкретного приложения и требуются ответы на вопросы типа «пользователи жалуются, что проверка правильности почтового адреса часто рушится, если в названии города есть буква 'ё', проверь пожалуйста, так ли это».
Светодиодный светофор (а их и так всё больше) может передавать импульсами в килогерцовом диапазоне метку светофора, своё текущее состояние, отметку времени и план переключений,
Из-за инерции человеческого зрения для людей он выглядит ничуть не хуже обычного светофора,
Модуляция позволяет легко отличать светофор от других предметов и бликов
Машине достаточно на пару секунд издалека увидеть любой из сигналов светофора, и она уже может просчитать его программу на часы вперёд. Фуры не помеха.
Алгоритмы очень просты и разработаны десятилетия назад для пультов ДУ, светофор удорожается на стоимость «ардуинки», что копейки по сравнению со стоимостью светофора и его обслуживания.
Система полезна и для обычных автомобилей — авто сможет показывать счётчик времени до переключения сигналов, предупреждать о красном свете, заводить мотор по переключению с красного на жёлтый.
Система автономна, не требует централизированного управления или наличия актуальной базы данных в автомобиле. В отличие от радио сразу понятно какая метка принадлежит какому светофору, что полезно на сложных перекрёстках. Можно применять во временных светофорах, маячках ограждающих место дорожных работ.
Если быстродействия основной камеры автомобиля не достаточно, то можно поставить отдельную. При 90 градусах обзора разрешения 256x128 достаточно чтоб различить висящие в 4-х метрах светофоры (условная ширина полосы) с полукилометра.
Думаю единственная причина почему такое ещё не внедряется это то, что деньги за робомобиль получит гугль, а стандарт разрабатывают и светофоры ставят совсем другие организации, для которых это дополнительная (пусть и несложная) работа. Будем надеятся, гугль пролоббирует нужных политиков и те дадут пинка ответственным за исполнение.
Я вообще не понимаю желания ВС США лепить странное оружие ПВО.
Точнее говоря это весьма умные люди в Пентагоне по тем или иным причинам решили рассказать миру, что США лепит странное оружие. Думаю в реальности происходит примерно так:
Аналитики МО США
Так, посмотрим какое оружие могло решить ход войны в прошлом:
XIX век — Броненосцы, канонерские лодки, унитарный патрон, казнозарядное стрелковое оружие
1-я мировая война — Дредноуты, пулемёты, химическое оружие
2-я мировая — Танки, авиация
60-е годы — Ядерное оружие
конец XX века — самонаводящиеся ракеты всевозможных размеров и типов
М-да, каждая следующая война выигрывается принципиально новым оружием, нам срочно нужно что-то новое!
Учёные
Во-первых спасибо за 100500 миллионов бюджета на R&D.
На эти деньги мы тут опробовали 100 разных идей:
90 оказалось бесперспективным шлаком
7 имеют потенциал если мы сможем их допилить
3 идеи это действительно оружие XXI века, мы побежали отрабатывать технологию массового производства!
PR-отдел
Так, про те 3 успешных идеи — молчок, нечего информировать потенциального противника.
Из оставшихся 97-ми выбираем 10 наиболее круто выглядящих с точки зрения налогоплательщиков
Youtube
Налетай, торопись! Только у нас! Эксклюзивные видео про
Самобеглых роботов из Boston Dynamics!
Чудо-беспилотники!
Рельсотроны!
Лазерные пушки!
Зрители этого шоу по всему миру
Да от лазера нуль пользы, при наших-то туманах!
Да они запарятся менять батарейки тем роботам!
Вот же пилят деньги на очевидно бесперспективных проектах!
Lego WeDo 2.0 (да наверное и первая версия тоже) это отличный (хотя и недешёвый) продукт, достойный отдельного обзора.
Если вкратце, то можно сказать так:
Годами покупая килограммами б/у Lego Technic на eBay и имея дома 3D-принтер на котором уже напечатано немало деталей, я тем не менее занёс деньги за WeDo 2.0 и очень доволен. Смысл набора в том, что его можно дать ребёнку младшего школьного возраста (в моём случае девочки 7 и 8 лет) и ребёнок сам может разобраться с заданием, выполнить его и даже сделать презентацию своего проекта. Некоторые задания просто очаровательны для девочек — например сделать карусель для зверят. В наборе есть блоки с нарисованными глазками, шарниры для ушей и т.д. Опять же можно дать роботу команду поморгать розовым (или другим) цветом.
Для меня главное, что дети программируют с планшета сами, без помощи родителей. Старшая мастерит трактор и пишет программу, младшая собирает лягушат которые на этом тракторе катаются. Когда робот, выполнив задание, заговорил (в звуковом программном блоке есть запись с микрофона) — обе скакали вне себя от радости в обнимку с изделием.
Программа уроков даёт базовые принципы механики, например есть задание где вначале по инструкции строится таскающий санки трактор, потом ребёнок должен определить сколько груза (кубиков) он может увезти. После, изменяя размеры ведущего и ведомого шкивов, нужно поменять передаточное число от мотора к колёсам и определить зависимость между скоростью и тягой робота.
Бородатым сорокалетним дядькам влёгкую выкладывающим 500 евро за звезду смерти будет не интересно, это да.
Первый WeDo видел на выставке, управляющий модуль по USB подключается к компьютеру и берёт от него питание для мотора и сенсоров. Нет проблемы с батарейками, кроме стандартной среды программирования есть Scratch. Lego официально не снижала цены, но сейчас, с выходом версии 2.0, логичны скидки. Есть кое-какой вторичный рынок б/у деталей.
WeDo 2.0 купил детям на каникулы. Управляется по Bluetooth LE, софт пока не настолько развит, но обещают открыть интерфейсы. Робот мобильней из-за питания от батарей, можно докупить аккумулятор. Среда программирования заточена под планшет (для меня это плюс).
Хорошая коробка со схемой какую деталь в какой отсек класть, легко сортировать детали и проверить всё ли на месте. Кто пылесосил в детской комнате, меня поймёт.
Наборы ориентированы на школы, хотя продаются и частникам. Отсюда конские цены на аксессуары — когда я вижу, что Lego просит 50 евро за 3х-вольтовый аккумулятор и ещё 24 евро за зарядное устройство (просто 10V DC), то из горла вырываются неприличные слова, а руки тянутся к паяльнику сделать всё в 10 раз дешевле. А для учителя это наверное плюс — не надо возиться с севшими батарейками и при малейшем риске пробоя гальванической развязки в БП фирма наверняка бесплатно отзовёт и заменит родные блоки питания.
Не стоит рассматривать WeDo как источник деталей Lego Techniс — тут eBay вне конкуренции. Набор даёт азы программирования тем, кому ещё слишком сложен Mindstorms. Плюс ориентация на школы, станции юных техников и прочие кружки. В некотором роде это нишевый продукт, но ниша детей 6-10 лет интересующихся техникой очень велика. Моим очень нравится, особенно то что они могут САМИ придумать и запрограммировать робота и показать умиляющимся родителям.
В статье надо очень внимательно читать чтоб не запутаться где какой набор. Вторая, четвертая и шестая картинки это Lego WeDo 2.0. Остальные — старое WeDo (для него характерны красный и желтый цвета).
В ЧаВо пишут, что бесплатная раздача Lego WeDo 2.0 Curriculum Pack (полная версия, с методическими материалами для учителей) это промо-акция, которая закончится 30-го июня. Так что я на всякий случай скачал полный пакет на разных языках.
У вас вперемешку фотографии старого WeDo и только что вышедшего WeDo 2.0, которые электрически и программно не совместимы между собой. Это может ввести в заблуждение.
Код в классическом WeDo исполняется на компьютере, а строительные блоки подключаются по USB. Можно программировать в Scratch.
В только что вышедшем WeDo 2.0 автономный робот имеет собственную батарею или аккумулятор и получает команды по Bluetooth LE. Программирование предполагается с планшета, причём не самого старого (например iPad 3 и выше). Win и Mac тоже поддерживаются. Scratch пока не портировали, но обещают. Ещё обещают выложить в публичный доступ Bluetooth API.
Есть информация, что полную версию софта для WeDo 2.0 можно скачать бесплатно только до 30-го июня, потом полный комплект с материалами для учителей будут отдавать за 298 евро. Можно скачать про запас, для этого не требуется какой-либо код или серийный номер.
PS: Купил детям (девочки 7 и 8 лет) три недели назад WeDo 2.0 — очень довольны. Хорошо играется вдвоём. Надо бы написать статью на geektimes.
Решил попробовать, и гугль привёл меня на страницу NI, где базовую версию LabVIEW предлагают за 1000 долларов. Всё так плохо, или я просто не заметил какую-нибудь более дешёвую версию для некоммерческого использования?
Наверное в этом и кроется причина «проблемы» — память компьютера по своей природе одномерный массив, а в ней сплошь и рядом надо хранить многомерные структуры, будь то классическая таблица или компонента R пикселя с координатами X и Y в кадре Z.
С проблемой вычисления индекса начинающий программист сталкивается в своей карьере рано и часто, так что к тому времени когда он дорастает до собственной реализации Heap, у него уже есть стойкое мнение что индексация с 0 проще и естественней, по крайней мере для часто встречающихся задач.
В JavaScript индексировать можно чем угодно, не обязательно числами, однако недавно мне опять пригодилась индексация с 0 при манипуляции с пикселями на canvas. Хорошо это или плохо, но N-мерные массивы постоянно встречаются в нашей жизни.
Ну кто мешает проделать подобный эксперимент сначала на крысах?
Я ни разу не медик, но с инженерной точки зрения логично предполагать, что кроме прорывных технологий в этой операции есть огромное количество рутинной работы как погружать пациента в кому, как выводить из неё, какие параметры тела мониторить и какими приборами, какие лекарства вводить при выходе параметров за допустимые пределы, как сшивать связки, сосуды, и т.д. Рутина, но критически важно для успеха операции. И вот тут приходит на помощь накопленный десятилетиями опыт сложных операций на людях. Грубо говоря можно нанять команду гениальных ассистентов который уже двадцать лет успешно проводят операции людям. А «toolchain» для мышей не настолько проработан, потому как цели экспериментов на животных — другие.
Успешная операция крысе не гарантирует успех человеку — организмы существенно разные. Более того, анализ неудачи с крысой может привести к выводу вроде «а вот тут у крысы сосуд был мааленький и мы не справились, так как в перывй раз такое делаем, а у человека он большой и у нас есть в команде специалист который уж десять лет такое делает каждый месяц» — и что, снова тратить утекающее время на планирование следующего альфа-релиза опять на крысе? И получить в конце заточенную на крыс технологию?
Быть альфа-тестером такой технологии очень старшно, но возможно доступные для проекта врачи действительно умеют чинить людей лучше чем животных.
А нашего SCRUM-мастера я бы с удовольствием сменял обратно на чтеца.
При нормальных условиях должно больше 30 кубометров быть. Разве что если сжать до 800 атмосфер, но почему именно до этого давления?
Получается, что с точки зрения программиста (которому всё равно нельзя лазить на Production серверы) Nano Server не отличается от полновесного Windows Server — в обоих есть полноценный IIS.
А у админов теперь выбор — выучить новые cmdlet-ы и радоваться легковесным виртуальным машинам, или и дальше пользоваться Windows Server, платя, тем самым, «налог на незнание PowerShell».
Учитывая тенденцию нарезать бизнес-логику маленькими независимыми кусочками микросервисов, перспектива хостить на одном Hyper-V несколько десятков лёгких VM с Nano Server весьма заманчива.
Если нужна кросс-платформенность, то надо брать Core. Главная цель — докер, который нам люб за то, что когда программист говорит «готово», то результатом является контейнер, который однозначно описывает систему во всех видах установки, от DEV до Production. Тем самым на корню устраняются проблемы вида «а у меня на компьютере всё работает». Ценой является отказ от бесплатных плюшек IIS вроде gzip-упаковки или Windows-аутентификации.
Если контейнеры нам пока не светят, например по организационным причинам, то полезность Core в нынешнем его состоянии не очевидна. Да, сегодня разработчики выдают при релизе 20 Мб DLL-ек, которые отдельная Infrastructure-команда устанавливает на заботливо оберегаемом ими Windows Server 2012, а завтра программисты будут выдавать лишь 2 Мб, а остальные 18 Мб сервер сам скачает из NuGet, но правил игры это не меняет. Сервер остаётся «pet, not cattle».
Замена тяжеловесного сервера на Nano порадует сисадминов, которым мучительно больно смотреть на расходуемые зря гигабайты, но мало что изменит для программистов.
Или я где-то ошибаюсь?
Началось всё с тестирования микросервисов на WEB API 2, приятно когда в две строчки можно поднять в памяти весь сервис и проверять правильность на уровне HTTP Request/Response, в том числе и правильную обработку HTTP-Headers и кодов возврата. А потом как-то незаметно переползло и в обычные веб-приложения. OWIN там не даёт особых преимуществ, но просто приятно убрать всё лишнее из global.asax, в котором отовсюду торчат уши HttpHandler (каковым и являлся ASP.NET в 2002 году).
В ссылке на официальную документацию в начале статьи говорится об использовании в качестве хоста для Hyper-V, однако в примерах наоборот, сам Nano Server это виртуальная машина.
В чём по вашему мнению преимущества .NET Core + Nano перед классическим ASP.NET MVC (OWIN) на полновесной ОС, тем более что вы всё равно используете IIS? Какие реальные проблемы решает связка c Nano?
Некоторые недостатки у Core есть, например пока отсутствует System.Drawing, которой мы используем для масштабирования JPEG-ов. Что оправдывает цену перехода на новую технологию? Может Deployment? Но, как я понимаю, даже облегчённая версия Windows слишком велика чтоб сделать весь образ артефактом который поставляют разработчики — копирование образа займёт слишком много времен.
Одним словом, чем по вашему мнению интересен Nano Server? Грубо говоря, чем он лучше полновесной Windows с одной стороны и Docker-а с другой?
/* Сухой маркетинговый язык страниц MSDN уже читал, хочется знать мнение реально работающих с этой технологией */
Полная стоимость применения яда и гарантированного устранения последствий намного выше цены собственно химикалий, а после CO2-атаки достаточно просто проветрить.
Grafana хороша чтоб с одного взгляда на необычную загрузку процессора, памяти или долгое время отклика определить, что пора вызывать программистов. А вот они для вылавливания багов полезут в хранящиеся в Elasticsearch логи, потому как «средняя температура по больнице» недостаточно точный инструмент.
Кибана в роли Dashboard это действительно «для хипстеров». Она хороша как интерактивный инструмент, а для висящего под потолком телевизора подходит плохо.
Метрики это числа, их можно естественным образом агрегировать и сжимать по времени. Данные за сегодня храним с разрешением в одну секунду, метрики за прошлый месяц усредняем поминутно, а для сравнения нынешнего года с предыдущим достаточно знать старые метрики с разрешением в час. Данные никогда полностью не удаляются, просто становятся менее подробными по мере устаревания.
Elasticsearch такого не может, да и бессмысленно это, усреднять текстовые данные. Зато хорошо помогает в поиске и устранении ошибок. Ограниченное время хранения (дни, недели) — не помеха, всё равно крайне редко интересует stack-trace исключения годичной давности. Баги обычно нужно фиксить здесь и сейчас. Декорирование записей тэгами также очень удобно, например у нас микросервисы вызывают друг-друга и каждый пишет в логи общий для всей цепочки correlation-id. Когда сервис в глубине системы рушится, в Кибане можно в пару кликов вывести всю цепочку вызовов приведшую к проблеме.
Понятно, что Kibana имеет простенькие средства агрегирования и примтивную математику по цифровым полям, так что при большом желании можно использовать её и для показа метрик, но остаются проблемы с историческими данными, плюс на средства визуализации невозможно смотреть без слёз. Например есть бессмысленный pie-chart, но нет горизонтального bar-chart. Хорошо хоть у Elasticsearch есть простой и понятный REST-API, так что легко приделать собственный интерфейс. Мы писали собственные плагины к AtlasBoard, которые тянут данные из ElasticSearch и показывают JavaScript-ом в браузере, благо графических JS-библиотек есть немерено, на любой вкус и цвет.
По моему мнению, Nagios+Grafana хорошо подходят для мониторинга железа, и «больших технологий» общих для всех, например «мы хостим веб-сайт». ELK хорош, если важна специфика работы конкретного приложения и требуются ответы на вопросы типа «пользователи жалуются, что проверка правильности почтового адреса часто рушится, если в названии города есть буква 'ё', проверь пожалуйста, так ли это».
Думаю единственная причина почему такое ещё не внедряется это то, что деньги за робомобиль получит гугль, а стандарт разрабатывают и светофоры ставят совсем другие организации, для которых это дополнительная (пусть и несложная) работа. Будем надеятся, гугль пролоббирует нужных политиков и те дадут пинка ответственным за исполнение.
Точнее говоря это весьма умные люди в Пентагоне по тем или иным причинам решили рассказать миру, что США лепит странное оружие. Думаю в реальности происходит примерно так:
Аналитики МО США
Так, посмотрим какое оружие могло решить ход войны в прошлом:
М-да, каждая следующая война выигрывается принципиально новым оружием, нам срочно нужно что-то новое!
Учёные
Во-первых спасибо за 100500 миллионов бюджета на R&D.
На эти деньги мы тут опробовали 100 разных идей:
PR-отдел
Youtube
Налетай, торопись! Только у нас! Эксклюзивные видео про
Зрители этого шоу по всему миру
Если вкратце, то можно сказать так:
Годами покупая килограммами б/у Lego Technic на eBay и имея дома 3D-принтер на котором уже напечатано немало деталей, я тем не менее занёс деньги за WeDo 2.0 и очень доволен. Смысл набора в том, что его можно дать ребёнку младшего школьного возраста (в моём случае девочки 7 и 8 лет) и ребёнок сам может разобраться с заданием, выполнить его и даже сделать презентацию своего проекта. Некоторые задания просто очаровательны для девочек — например сделать карусель для зверят. В наборе есть блоки с нарисованными глазками, шарниры для ушей и т.д. Опять же можно дать роботу команду поморгать розовым (или другим) цветом.
Для меня главное, что дети программируют с планшета сами, без помощи родителей. Старшая мастерит трактор и пишет программу, младшая собирает лягушат которые на этом тракторе катаются. Когда робот, выполнив задание, заговорил (в звуковом программном блоке есть запись с микрофона) — обе скакали вне себя от радости в обнимку с изделием.
Программа уроков даёт базовые принципы механики, например есть задание где вначале по инструкции строится таскающий санки трактор, потом ребёнок должен определить сколько груза (кубиков) он может увезти. После, изменяя размеры ведущего и ведомого шкивов, нужно поменять передаточное число от мотора к колёсам и определить зависимость между скоростью и тягой робота.
Бородатым сорокалетним дядькам влёгкую выкладывающим 500 евро за звезду смерти будет не интересно, это да.
Первый WeDo видел на выставке, управляющий модуль по USB подключается к компьютеру и берёт от него питание для мотора и сенсоров. Нет проблемы с батарейками, кроме стандартной среды программирования есть Scratch. Lego официально не снижала цены, но сейчас, с выходом версии 2.0, логичны скидки. Есть кое-какой вторичный рынок б/у деталей.
WeDo 2.0 купил детям на каникулы. Управляется по Bluetooth LE, софт пока не настолько развит, но обещают открыть интерфейсы. Робот мобильней из-за питания от батарей, можно докупить аккумулятор. Среда программирования заточена под планшет (для меня это плюс).
Хорошая коробка со схемой какую деталь в какой отсек класть, легко сортировать детали и проверить всё ли на месте. Кто пылесосил в детской комнате, меня поймёт.
Наборы ориентированы на школы, хотя продаются и частникам. Отсюда конские цены на аксессуары — когда я вижу, что Lego просит 50 евро за 3х-вольтовый аккумулятор и ещё 24 евро за зарядное устройство (просто 10V DC), то из горла вырываются неприличные слова, а руки тянутся к паяльнику сделать всё в 10 раз дешевле. А для учителя это наверное плюс — не надо возиться с севшими батарейками и при малейшем риске пробоя гальванической развязки в БП фирма наверняка бесплатно отзовёт и заменит родные блоки питания.
Не стоит рассматривать WeDo как источник деталей Lego Techniс — тут eBay вне конкуренции. Набор даёт азы программирования тем, кому ещё слишком сложен Mindstorms. Плюс ориентация на школы, станции юных техников и прочие кружки. В некотором роде это нишевый продукт, но ниша детей 6-10 лет интересующихся техникой очень велика. Моим очень нравится, особенно то что они могут САМИ придумать и запрограммировать робота и показать умиляющимся родителям.
Как-то так.
Код в классическом WeDo исполняется на компьютере, а строительные блоки подключаются по USB. Можно программировать в Scratch.
В только что вышедшем WeDo 2.0 автономный робот имеет собственную батарею или аккумулятор и получает команды по Bluetooth LE. Программирование предполагается с планшета, причём не самого старого (например iPad 3 и выше). Win и Mac тоже поддерживаются. Scratch пока не портировали, но обещают. Ещё обещают выложить в публичный доступ Bluetooth API.
Есть информация, что полную версию софта для WeDo 2.0 можно скачать бесплатно только до 30-го июня, потом полный комплект с материалами для учителей будут отдавать за 298 евро. Можно скачать про запас, для этого не требуется какой-либо код или серийный номер.
PS: Купил детям (девочки 7 и 8 лет) три недели назад WeDo 2.0 — очень довольны. Хорошо играется вдвоём. Надо бы написать статью на geektimes.
С проблемой вычисления индекса начинающий программист сталкивается в своей карьере рано и часто, так что к тому времени когда он дорастает до собственной реализации Heap, у него уже есть стойкое мнение что индексация с 0 проще и естественней, по крайней мере для часто встречающихся задач.
В JavaScript индексировать можно чем угодно, не обязательно числами, однако недавно мне опять пригодилась индексация с 0 при манипуляции с пикселями на canvas. Хорошо это или плохо, но N-мерные массивы постоянно встречаются в нашей жизни.
Я ни разу не медик, но с инженерной точки зрения логично предполагать, что кроме прорывных технологий в этой операции есть огромное количество рутинной работы как погружать пациента в кому, как выводить из неё, какие параметры тела мониторить и какими приборами, какие лекарства вводить при выходе параметров за допустимые пределы, как сшивать связки, сосуды, и т.д. Рутина, но критически важно для успеха операции. И вот тут приходит на помощь накопленный десятилетиями опыт сложных операций на людях. Грубо говоря можно нанять команду гениальных ассистентов который уже двадцать лет успешно проводят операции людям. А «toolchain» для мышей не настолько проработан, потому как цели экспериментов на животных — другие.
Успешная операция крысе не гарантирует успех человеку — организмы существенно разные. Более того, анализ неудачи с крысой может привести к выводу вроде «а вот тут у крысы сосуд был мааленький и мы не справились, так как в перывй раз такое делаем, а у человека он большой и у нас есть в команде специалист который уж десять лет такое делает каждый месяц» — и что, снова тратить утекающее время на планирование следующего альфа-релиза опять на крысе? И получить в конце заточенную на крыс технологию?
Быть альфа-тестером такой технологии очень старшно, но возможно доступные для проекта врачи действительно умеют чинить людей лучше чем животных.