Сейчас модули Mindstorms/WeDo соединяются звездой — в центре «кирпич» контроллера, а к нему подсоединяются сенсоры и моторы. В Technics же можно сделать дерево, когда к батарейке подключаешь выключатель или ИК-приёмник, а на его выход вешаешь несколько лампочек или моторов. Концы кабелей Technics имеют сквозные контакты и их можно соединять стопкой, навешивая на один выход параллельно несколько нагрузок.
Непонятно как такое можно сделать с WeDo-разъёмами.
WeDo взрослому будет не интересен — он расчитан на младших школьников.
Думаю зря ругают «примитивную» среду программирования, просто дети думают не так как тридцатилетние бородатые дядьки. Наблюдая за дочками (7 и 8 лет) заметил следуещее:
Если с нашей точки зрения программирование это про алгоритмы и циклы, то для детей на первом месте графические объекты на экране. Например, старшая дочка может часами заниматься в Scratch, но не составляя алгоритмы, а «программируя» сказку про Колобка. Програмные блоки для неё это просто инструмент чтоб по нажатю на колобка он побежал или запел песенку, а потом передал сообщение спрайту волка/медведя/лисы когда наступит их очередь выступать. Самый главный блок в IDE — тот что с микрофоном. Что может быть лучше, чем заставить робота говорить моим голосом!
Дети играют, а мы только подталкиваем в нужном направлении заданиями вроде «а давай-ка он теперь споёт эту песенку три раза». Так потихоньку изучаем все виды команд. Для детей XXI века программирование это не «computer science», а способ общения со всё более электронным окружающим миром.
В WeDo на первом месте забавный робот которого можно оживлять программой.
У Mindstorms можно в центр поставить программу, а ей уж нужны сенсоры и моторчики для взаимодействия с реальным миром. Особенно если заменить графическую IDE на что-то вроде RobotC.
По количеству частиц космические лучи на 92% состоят из протонов, на 6% — из ядер гелия, около 1% составляют более тяжелые элементы, и около 1% приходится на электроны.
Если Солнце сбрасывает в космос на 99% положительные частицы, то оно должно накопить адский отрицательный заряд, который не даст дальше разлетаться протонам и прочим ядрам атомов. Интересно, почему этого не происходит, куда девается лишний заряд?
У вас микрокалькулятор Б3-34 или MK-61
Нажав [F] [.] вы вытаскиваете принцессу из стека, затем берёте с полки свежий выпуск журнала Техника Молодёжи, и, запрыгнув в лунолёт Кон-Тики, отправляетесь в долгий путь к Земле.
За окном был тёплый августовский день 1985 г. Через 4 года Тим Бернерс-Ли изобретёт WWW.
А вот что было на самом деле:
У вас микрокалькулятор Б3-34 или MK-61
Нажав [F] [.] вы вытаскиваете принцессу из стека, затем берёте с полки изрядно потрёпанный журнал Техника Молодёжи, и, запрыгнув в лунолёт Кон-Тики отправляетесь в долгий путь к Земле.
За окном был пасмурный октябрьский день 2016 г. Разработчики Kerbal Space Program, в слезах, уволились из Squad, а голландцы спешно бросились изучать загадочный русский девайс.
У вас COBOL
Вы единственный человек на свете способный спасти принцессу, но сейчас заняты борьбой с millenium-багом. К счастью, принцесса уже была спасена в 1916 году.
С детства привык, что математика, при всей кажущейся абстрактности, решает реальные инженерные проблемы. Например производная пути по времени это скорость, вторая производная — ускорение, и вот уже дифуры имеют конкретную практическую пользу.
Понятно чем интересны простые числа — они ведут себя существенно по другому.
Понятно чем удобны числа с большим количеством делителей, например если у N делителей больше чем sqrt(N). Легко делить кучку предметов на равные группы.
А в чём смысл суммы делителей? А если скажем у числа сумма делителей на 3 единицы не дотягивает до N, то чем оно существенно хуже строго избыточного?
Во-первых, идея использовать немецкий для обозначения трудночитаемого кода.
Во-вторых, тут казалось бы есть проблема — эффект потеряется, если читатель знает немецкий и привык к языку. Но нет, творческий выбор глаголов и вырвиглазный порядок слов делают отрицательные примеры одинаково ужасными для всех.
Чтоб не оффтопить: в C# async и await еcть уже давно и try/catch работает, но stack trace исключений очень трудно читать — надо продираться сквозь дебри автосгенерированных вызовов служебных функций. В JS надеюсь будет лучше?
Вопросы очень уместны. В нашем случае это прототип чтоб понять какого рода программы можно написать для HoloLens. Если использование Arduino экономит два часа времени, то те лишние 9,9 $ разницы уже себя оправдали. При массовом производстве применять Arduino чтоб переслать 9 байт это как из пушки по воробьям, согласен.
На счёт аккумулятора — какую связку из акку и конролера зарядки посоветуйте? Я не электронищик, а программист, так что заказал то, что смог быстро найти в гугле. Потребление тока около 50 мA, желаемое время — полный рабочий день.
Реальный лаг там доли секунды и совсем не ощущается. Вот используемый для трансляции видео с HoloLens интрефейс Mixed Reality Capture торомозит, это верно. Если пытаться смотреть в десктопном браузере что же видит человек в очках, то видеопоток вобще может отставать на 3-5 секунд.
Получается, что с точки зрения программиста (которому всё равно нельзя лазить на 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 это действительно «для хипстеров». Она хороша как интерактивный инструмент, а для висящего под потолком телевизора подходит плохо.
Сейчас модули Mindstorms/WeDo соединяются звездой — в центре «кирпич» контроллера, а к нему подсоединяются сенсоры и моторы. В Technics же можно сделать дерево, когда к батарейке подключаешь выключатель или ИК-приёмник, а на его выход вешаешь несколько лампочек или моторов. Концы кабелей Technics имеют сквозные контакты и их можно соединять стопкой, навешивая на один выход параллельно несколько нагрузок.
Непонятно как такое можно сделать с WeDo-разъёмами.
Думаю зря ругают «примитивную» среду программирования, просто дети думают не так как тридцатилетние бородатые дядьки. Наблюдая за дочками (7 и 8 лет) заметил следуещее:
Если с нашей точки зрения программирование это про алгоритмы и циклы, то для детей на первом месте графические объекты на экране. Например, старшая дочка может часами заниматься в Scratch, но не составляя алгоритмы, а «программируя» сказку про Колобка. Програмные блоки для неё это просто инструмент чтоб по нажатю на колобка он побежал или запел песенку, а потом передал сообщение спрайту волка/медведя/лисы когда наступит их очередь выступать. Самый главный блок в IDE — тот что с микрофоном. Что может быть лучше, чем заставить робота говорить моим голосом!
Дети играют, а мы только подталкиваем в нужном направлении заданиями вроде «а давай-ка он теперь споёт эту песенку три раза». Так потихоньку изучаем все виды команд. Для детей XXI века программирование это не «computer science», а способ общения со всё более электронным окружающим миром.
Если Солнце сбрасывает в космос на 99% положительные частицы, то оно должно накопить адский отрицательный заряд, который не даст дальше разлетаться протонам и прочим ядрам атомов. Интересно, почему этого не происходит, куда девается лишний заряд?
Все ещё ждут пока скачаются 100500 зависимостей в node_modules.
А вот что было на самом деле:
С детства привык, что математика, при всей кажущейся абстрактности, решает реальные инженерные проблемы. Например производная пути по времени это скорость, вторая производная — ускорение, и вот уже дифуры имеют конкретную практическую пользу.
Понятно чем интересны простые числа — они ведут себя существенно по другому.
Понятно чем удобны числа с большим количеством делителей, например если у N делителей больше чем sqrt(N). Легко делить кучку предметов на равные группы.
А в чём смысл суммы делителей? А если скажем у числа сумма делителей на 3 единицы не дотягивает до N, то чем оно существенно хуже строго избыточного?
Во-первых, идея использовать немецкий для обозначения трудночитаемого кода.
Во-вторых, тут казалось бы есть проблема — эффект потеряется, если читатель знает немецкий и привык к языку. Но нет, творческий выбор глаголов и вырвиглазный порядок слов делают отрицательные примеры одинаково ужасными для всех.
Чтоб не оффтопить: в C# async и await еcть уже давно и try/catch работает, но stack trace исключений очень трудно читать — надо продираться сквозь дебри автосгенерированных вызовов служебных функций. В JS надеюсь будет лучше?
На второй схеме после потенциометра сигнал почему-то подаётся и на усилитель. Зачем?
Зелёная линия на графике в середине статьи это что угодно, но не «true logarithmic». Логарифмическая кривая не симетрична относительно диагонали.
Для «что нужно знать» не хватает главной ссылки на Easyelectronics. Трудно живётся англоязычным авторам.
На счёт аккумулятора — какую связку из акку и конролера зарядки посоветуйте? Я не электронищик, а программист, так что заказал то, что смог быстро найти в гугле. Потребление тока около 50 мA, желаемое время — полный рабочий день.
А нашего 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 это действительно «для хипстеров». Она хороша как интерактивный инструмент, а для висящего под потолком телевизора подходит плохо.