В первой части разобрались с тем, зачем все это нужно и как я до этого докатился, во второй поговорили о софте. Настала пора остановиться на самом любимом хабравчанами разделе DIY — на железе. Итак, берем текстолит, хлорное железо, паяльник… Хотя нет, стоп, открываем редактор плат. Про паяльник, куда его засовывать, а куда лучше не надо другие лучше меня расскажут. А я расскажу какие платы и датчики трудятся на благо моего умного дома.

Проект интеллектуального датчика Neurio, который за две недели до окончания кампании на Кикстартере уже превысил план на 40 000 долларов, основан на необычном подходе к управлению умным домом. В основе Neurio лежит очень точный и подробный анализ энергопотребления. Умный счётчик похож на обычный электронный счётчик электроэнергии, но фиксирует гораздо больше параметров, и делает это точнее и чаще, чем обычный. Эти данные отправляются в облако и там анализируются алгоритмами искусственного интеллекта, которые достаточно уверенно распознают отдельных потребителей электричества по характерному для них «почерку».



Это возможно благодаря тому, что датчик Neurio измеряет в двух независимых двухсторонних каналах не только активную мощность, но и реактивную мощность, коэффициент мощности, напряжение, ток, и частоту. Данные обновляются один раз в секунду и передаются в домашнюю сеть по WiFi. На случай потери связи есть внутренняя память, которой хватает на год непрерывной записи.

«Усложнённость (Simplexity) — процесс, которым природа достигает простых результатов сложными путями.» — Bruce Schiff

1. Введение

Представьте себе следующую задачу: у нас есть таблица из n целочисленных ключей A₁, A₂, …, A_n, и целочисленное значение X. Нам нужно найти индекс числа X в этой таблице, но при этом мы особо никуда не торопимся. На самом деле, мы бы хотели делать это как можно дольше.

Для этой задачи мы могли бы остановиться на самом тривиальном алгоритме, а именно, перебирать все A_n по порядку и сравнивать их с X. Но, может так случиться, что X = A₁, и алгоритм остановится на самом первом шаге. Таким образом, мы видим, что наивный алгоритм в наилучшем случае имеет временную сложность O(1). Возникает вопрос — можем ли мы улучшить (то есть, ухудшить) этот результат?

Разумеется, мы можем сильно замедлить этот алгоритм, добавив в него пустых циклов перед первой проверкой равенства X и A₁. Но, к сожалению, этот способ нам не годится, потому что любой дурак заметит, что алгоритм просто-напросто впустую тратит время. Таким образом, нам нужно найти такой алгоритм, который бы всё-таки продвигался к цели, не смотря на отсутствие энтузиазма, или вовсе желания до неё в конечном итоге дойти.

Инфраструктура .Net содержит встроенные средства генерирования кода (On-the-Fly Code Generation). Это позволяет .Net-программе в момент своего исполнения самостоятельно (без участия программиста) скомпилировать текст, написанный на каком-либо языке программирования и исполнить получившийся код. Логично было бы ожидать, что для осуществления этих действий в стандартной .Net-библиотеке предусмотрен простейший метод соответствующего класса. Но к сожалению это не так. Microsoft, проделав огромный путь по встраиванию в среду .Net средств генерирования кода, не сделала самый последний шаг навстречу простейшим потребностям программистов. Значит, придётся сделать этот шаг самостоятельно.

Самое простое средство предлагаемое Microsoft для решения описанной задачи — это класс CSharpCodeProvider, который входит в стандартную библиотеку .Net. Использование этого класса — не очень сложная задача, но тем не менее было бы полезно иметь инструмент, превращающий использование сгенерированного на лету кода в задачу тривиальную.

Привет, Хабр!

Наверное, самый частый вопрос у менеджеров в IT — «Где взять программистов?». Для эйчаров вообще каждое новое открытие вакансии разработчика — это суровый вызов, независимо от региона или технологической платформы. Давайте разберемся, что происходит и как исправить ситуацию.

Не мог пройти мимо топика "Вопросы на собеседование middle/senior iOS Developer" и статьи "Собеседование разработчика". Хочу предложить альтернативный или дополнительный подход к собеседованию разработчиков.

Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»

Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.

К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.

Что ты предлагаешь, чувак?

Давайте рассмотрим на примере android разработчика (адаптировать можно для любой области, но вы же понимаете, что без конкретики эту статью просто раскритиковали бы, так что поговорим об android).

Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!

Почему это хороший вариант? Вы сможете достаточно точно оценить уровень разработчика в проектировании и реализации ПО, его знание платформы и другие важные вам ньюансы, а так же просто приятно провести время (в случае с компетентным кандидатом, да и ему будет интереснее чем на типичном собеседовании). + Вы сможете понять, насколько человек общителен, как вольется в вашу команду, сможет ли он объяснять свои решения другим?

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

Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).

Техническое собеседование – практически неотъемлемый атрибут трудоустройства любого разработчика, а для старших разработчиков – проведение их (собеседований) ещё и чуть ли не повседневная обязанность. Но как за короткий срок (в идеале 20-30 минут) составить у себя более менее приемлемое представление о реальном опыте соискателя?

«Мы создали каркас версии 1.0 — у нас есть огромный план и куча всевозможных идей, что-то входит в него, что-то нет» — Тарн Адамс и его брат Зак уже 11 лет разрабатывают процедурно-генерируемую фэнтези-игру Dwarf Fortress, если же учитывать работу над DragSlay и Slaves to Armok, сильно повлиявшими на игру в начале разработки, то получатся все 13 лет. Хотя вы можете бесплатно скачать игру прямо сейчас, версия 1.0 появится еще очень и очень нескоро. Тарн Адамс недавно сказал, что 1.0 можно ждать примерно через 20 лет, хотя скорее всего она появится еще позже «потому что я всегда недооцениваю время, необходимое для завершения работы».

Но какими бы ни были временные рамки, у братьев Адамс есть четкая цель. Они понимают, что уже не раз застревали на самых разных этапах разработки, так что их способ движения вперед заключается в том, чтобы разложить перед собой все идеи и выбрать, куда двигаться дальше в ближайшем будущем. «Мы стараемся оставаться в рамках плана» — говорит Адамс — «когда мы выполним его, получится версия 1.0. После этого можно будет добавить множество разных вещей, но нам будет более 50 лет — есть масса жизненных решений, которые надо принимать в таком возрасте, так что вряд ли мы будем придерживаться этого плана еще пять лет».

Если вам это имя ни о чём не говорит, то вы, скорей всего, не знакомы с компанией Larian, которая делает замечательные RPG. Я сам поклонник многих их игр, к тому же порой переписываюсь с людьми из их дружелюбной команды (больше на их официальном форуме, правда). Сейчас парни работают над Divinity: Original Sin, и Свен, в свете этого видимо, довольно интересную статью написал в своём блоге о том, что же на самом деле важно в RPG. Поклонников этого жанра прошу под кат.

Введение

Numenta NuPIC — открытая реализация алгоритмов, моделирующих процессы запоминания информации человеком, происходящие в неокортексе. Исходные коды NuPIC на github

В двух словах, назначение NuPIC можно описать как «фиговина, выявляющая, запоминающая и прогнозирующая пространственные и временные закономерности в данных». Именно этим большую часть времени занимается человеческий мозг — запоминает, обобщает и прогнозирует. Очень хорошее описание этих процессов можно найти в книге Джеффа Хокинса «On Intelligence» (есть русский перевод книги под названием «Об интеллекте»).

На сайте Numenta есть подробный документ, детально описывающий алгоритмы и принципы работы, а также несколько видео.

Люди, как известно, делятся на два типа: тех, кто читают инструкцию перед тем, как включать электроприборы, и тех, кто сначала включает, а в случае каких-то косяков начинает читать, что же он сделал не так.

Я абсолютно точно принадлежу ко второй группе. Поэтому именно так я начал создавать свой первый тренинг. На тот момент я уже 3 года работал в Intel, читал несколько внутри-корпоративных тренингов, как вдруг ощутил непреодолимое желание сделать свой тренинг.

Ведь всем известно, что корпоративные тренинги учат как жить в корпорации. Тебе вставляют в ухо шланг, через который начинают закачивать vision, mission & corporate values.

Поэтому, решил я, я сделаю свой тренинг, где расскажу всю правду-матку. И сделал. А что там делать? Берешь свой опыт, рисуешь красивые слайды, придумываешь упражнения — и вперед!

И это было ужасно. Нет, людям-то как раз нравилось, но мне сейчас это кажется ужасным. Потому что, как выяснилось через некоторое время, для успешного тренинга нужны не только собственный опыт, хорошее чувство юмора, умение выступать и общаться с людьми. Нужна еще методика. Без понимания которой люди выносят 10% той пользы, которой они могли бы получить от вашего тренинга, если бы вы вначале прочли инструкцию по тому, как обучать взрослых людей.

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

В прошлой статье [1] мы говорили о матрице осознанности и компетентности и том, как взрослые люди обучаются навыкам. Давайте теперь поговорим о модели обучения, которая дает ответ на вопрос, а как учить взрослых людей. О цикле Колба.

Поняв эту модель, вы сможете:

• Четко понимать, почему одни тренинги и семинары оказываются полезными, а другие заходят плохо
• Правильно обучать других людей — как в группах, так и индивидуально
• С умным видом рассуждать на тему обучения взрослых людей, уверенно используя термин “цикл Колба”

История проекта уходит корнями в далекий 2006 год.
Тогда в питерский НИИ обратился активный член общества слепых с предложением создания устройства помощи слепым и слабовидящим.
Один из основателей нынешнего Oriense тогда заведовал отделом, который занимался в том числе зрением роботов и разрабатывал свою стереокамеру. На ней устройство и решили базировать: носимый компьютер обрабатывает информацию от двух камер и двух УЗ-сонаров и выдает подсказки в наушники с помощью голосового синтезатора.

UPD: игра вышла.

Привет!

Тут такая история. Я заметил, что в какой-то момент стал отмечать для себя важные вещи для развития ребёнка. Например, у меня в детстве был сначала модульный конструктор с мотором, колёсами, батарейками и так далее, а потом – модульный же радиоконструктор. Эти два предмета очень сильно повлияли на то, чем я потом интересовался в будущем.

Ещё пример – в детстве надо обязательно сходить в политехнический и археологический музеи Москвы. Или, например, запомнились такие штуки: первая хорошая НФ, подаренная в 8 лет; дед, научивший меня чертёжному почерку за 15 минут; шахматы каждые выходные; огромная коробка Лего и так далее. И таких событий – тысячи.

У меня просьба. Давайте накидаем важные и интересные вещи, которые можно и нужно сделать с ребёнком до примерно 10 лет. Наверняка ведь у вас есть такие «чекпоинты», которые запомнились.

Новые материалы, алгоритмы движения и поведения, инженерные решения и, самое главное, некоторые успехи в создании искусственного интеллекта вселяют робкую надежду на появление первых полноценных андроидов хотя бы при нашей жизни. Но что будет потом? Каковы будут последствия обитания среди нас действительно умных машин? Учёные, писатели и режиссёры на самые разные лады описывают всевозможные сценарии будущего сосуществования людей и андроидов. Диапазон варьируется от апокалиптического порабощения людей до идиллических картин в духе «Приключения Электроника»: «…Вкалывают роботы, / А не человек». С точки зрения коммерческого успеха, большинство фантастических фильмов и книг о роботах обыгрывают гротескные ситуации: войны, угнетение, борьбу то нас с ними, то их с нами. Иными словами, будущее людей и роботов обычно так или иначе окрашено в мрачные тона. Особенно в последние годы сценаристам приглянулась тема безысходного, тягостного будущего. Тем интереснее становятся менее популярные, и потому интересные умеренные точки зрения и сценарии.

В течение последних месяцев, на хабре появлялись различные статьи с описание Wi-Fi Mesh сетей, которые строились на ПО cjdns.

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

Таким образом появился сервис о котором и хотелось бы рассказать, он поможет желающим организоваться и построить Mesh сеть.

Продолжаем нашу серию статей по мотивам опросов: на этот раз мы решили измерить расхождение между тем, как представляют рабочий день программиста студенты-технари, и тем, как все происходит на самом деле. Студенты МГТУ им. Баумана, которые учатся в Технопарке, снова согласились ответить на наши вопросы.

Для этого мы провели небольшое исследование, в ходе которого ожидаемо выяснилось, что не все представления о «сферическом рабочем дне в вакууме» совпадают с реальностью. Студенты готовы программировать по 790 часов в год при условии, что половину рабочего времени будут проводить в социальных сетях.

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

Вопрос программистам: Представьте себе свой типичный рабочий день. Какой процент времени в среднем занимает каждая из перечисленных активностей?

• Обдумываю задачу, ищу пути решения
• Изучаю информацию, читаю маны
• Пишу код
• Тестирую, ищу баги
• Участвую во встречах, планерках, брейнштормах, провожу собеседования
• Читаю Хабрахабр, Роем и другое полезное в интернете
• Читаю / пишу письма, ставлю / читаю таски в трекере
• Сижу в социальных сетях
• Общаюсь с коллегами по не рабочим вопросам
• Ем, пью, сплю

Далее для сравнения мы собрали ответы студентов Технопарка.

Давайте попробуем повлиять на Роскосмос продвинув интересный проект молодых российских ученых: космического аппарата для изучения астероидов. Надо всего лишь поставить подпись (ссылка тут и в конце поста. Через Facebook в два клика).

Всем добрый день!

Бывало ли у вас такое, что вы долго думали над какой-то рабочей (или личной ситуацией), а потом вдруг раз! и все как будто раскладывалось по полочкам? У нас такое бывало неоднократно.

Вместо пролога. Более того, это в некотором смысле наша профессия — раскладывать по полочкам сложные ситуации. Потому что последние 7 лет мы с коллегами занимаемся обучением IT-специалистов и руководителей навыкам управления людьми и тому, что называется soft skills.

За время работы у нас накопилось какое-то количество инструментов, которыми мы решаем разные управленческие кейсы. И этими инструментами мы и задумали поделиться.

Во-первых, потому что инструменты полезные. Во-вторых, хочется собрать их все в одном месте, чтобы потом отсылать туда всех желающих. В-третьих, мы четко понимаем, что ограничены собственным контекстом, и будем очень благодарны, если вы будете нас дополнять. В четвертых, мы не очень верим в рекламу. Мы верим в простые вещи — что если мы делаем что-то полезное для людей, то люди будут нас рекомендовать. Почему бы тогда не написать несколько полезных статей?

Все инструменты, о которых мы будем писать, очень простые. Либо это матрицы 2 на 2, либо 4 вопроса, либо что-то в таком же духе. Поскольку мы много работаем с менеджерами, то обнаружили, что матрицы 3 на 3 некоторым менеджерам уже сложновато воспринимать (хей, мы сами были менеджерами, знаем о чем говорим :)), а 2 на 2 — в самый раз, отлично заходят.

Какие-то инструменты придумали мы, какие-то позаимствовали у других умных людей, какие-то не знаем, откуда появились в нашей голове. Но они все полезные, да.

Являются ли эти инструменты серебряными пулями? Ясен пясен, нет. Но они совершенно точно помогают прояснить ситуацию, навести дистинкции и понять, в какую сторону думать. А решения все равно придется придумывать вам. До тех пор, пока не появится, наконец, справочник юных сурков по менеджменту.

Итак, довольно лишних слов, давайте перейдем к первому инструменту (всего мы планируем разобрать около 15 разных полезных концептов):

Учёные уже несколько лет экспериментируют с новой технологией передачи данных через светодиоды в лампах дневного света. В паре с фотоприёмником лампа превращается нормальный модем. По аналогии с Wi-Fi такой вид связи называется Li-Fi. Если светодиоды мерцают с высокой частотой разными цветами, то можно добиться довольно высокой скорости передачи данных. Например, немцы еще два года назад зафиксировали скорость 800 Мбит/с на расстоянии 1,8 метра в лабораторных условиях. Впрочем, до практической реализации дело у них пока не дошло.

А вот инженеры из Фуданьского университета в Шанхае недавно провели эксперимент с Li-Fi, где четыре персональных компьютера выходили в интернет через одну 1-ваттную светодиодную лампочку.

В 2009 году я рассказывал, как мы строим наш маленький семейный бизнес с оборотом 1500 долларов в месяц. Прошло четыре года. Бизнес вырос до оборота 500 000 долларов в год, и мы его потеряли. Самое время рассказать о допущенных ошибках.

Что же произошло?

Публикация на хабре позволила нам познакомиться с разными людьми, наш бизнес многим понравился. Так в 2010 году мы продали 50% компании частным инвесторам. После успешной трехлетней совместной жизни в сентябре 2013 года наши партнеры отжали бизнес. Мы остались ни с чем.

Как говорил Франклин, “Опыт — это чудесное умение распознавать ошибку, которую ты допускаешь снова”. Возможно, для кого-то все, написанное ниже, знакомо и понятно. Для нас это было впервые и, оглядываясь назад, я вижу множество ошибок, которые привели к такой ситуации. Буду рад ими поделиться с вами.