Мы продолжаем цикл квантовых статей. Сегодня углубимся в формулы и поймем, как можно манипулировать кубитами — элементарными вычислительными единицами. Кроме того, рассмотрим принципы цепей и алгоритмов. Подробнее под катом!

Искусственный интеллект сейчас является одной из самых обсуждаемых тем и главным двигателем цифровой трансформации бизнеса. Стратегия Microsoft в области ИИ включает в себя демократизацию ИИ для разработчиков, т.е. предоставление простых в использовании фреймворков и сервисов для решения интеллектуальных задач. В этой статье рассказывается, как .NET-разработчики могут использовать возможности ИИ в своих проектах: начиная от готовых когнитивных сервисов, работающих в облаке, заканчивая обучением нейросетей на .NET-языках и запуском сложных нейросетевых моделей на компактных устройствах типа Raspberry Pi.

Прототипом статьи послужил доклад Дмитрия Сошникова на конференции DotNext 2017 Moscow. Дмитрий — технологический евангелист компании Майкрософт, занимается популяризацией современных технологий разработки программного обеспечения среди начинающих разработчиков. Специализируется в области интернета вещей, в разработке универсальных приложений Windows, в области функционального программирования и на платформе .NET (F#, Roslyn). Лично провел несколько десятков хакатонов по всей России, помогал многим студенческим стартапам начать свои проекты в различных областях. Доцент, к.ф.-м.н., ведет занятия в МФТИ и МАИ, член Российской ассоциации искусственного интеллекта, летом — ведущий кафедры компьютерных технологий детского лагеря ЮНИО-Р.

Осторожно, трафик! В этом посте присутствует огромное количество картинок — слайдов и скриншотов с видео в формате 720p.

Возможно, вы узнали о выпуске пакета средств квантовой разработки Quantum Development Kit и подумали, что это звучит безумно круто… а потом вспомнили, что про квантовую механику почти ничего не знаете. Но ничего страшного. Через 30 минут вы будете знать о кубитах, суперпозиции и квантовой запутанности достаточно, чтобы написать свою первую программу и, что более важно, неплохо понимать, что она делает.

Искусственный интеллект и машинное обучение — две хайповые тенденции последних лет. Необходимые для AI&ML объемы вычислений обычно выполняются в ЦОДах на специальном высокопроизводительном и энергоэффективном оборудовании (например, серверах с TPU). Эволюция циклична, и маятник качнулся обратно, в сторону вычислений на периферийных устройствах, таких как ПК, планшеты и IoT. В частности, это приведет к повышению скорости реакции устройств на голосовые команды и повысит комфортность общения с персональными ассистентами.



WinML — это новый набор API-интерфейсов, который позволит разработчикам использовать все возможности любого устройства Windows 10 для вычислений предварительно обученных моделей машинного обучения и загруженных в приложение в формате Open Neural Network Exchange (ONNX).

Data Science – область очень перспективная. За прошлый год мы в ЕРАМ получили 210 резюме от людей, которые хотят заниматься Data Science. Из них на техническое интервью мы пригласили 43 человека, а предложили работу семи. Если спрос большой, почему так?

Мы поговорили с техническими интервьюерами и выяснили: проблема многих кандидатов в том, что они плохо представляют, чем занимаются аналитики данных. Поэтому их знания и навыки не всегда релевантны для работы. Кто-то считает, что опыта работы с Big Data достаточно, чтобы работать в Data Science, кто-то уверен, что хватит просмотра нескольких курсов по машинному обучению, некоторые думают, что хорошо разбираться в алгоритмах необязательно.

Дмитрий Никитко и Михаил Камалов – аналитики данных и технические интервьюеры из ЕРАМ – рассказали, чего ждут на собеседованиях от кандидатов, какие вопросы задают, что ценится в резюме и как подготовиться к собеседованию.

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

Да, под Node.js можно написать сервер, но для бэковой разработки, все же, .net бесспорный лидер. На js, на мой взгляд, очень сложно написать гибкий и легко поддерживаемый бэкенд, хотя возможно многие со мной и не согласятся.

Давайте ударим автопробегом по бездорожью попытаемся вопреки всему этому написать SPA приложение с бэком на .net core и клиентом на js, из инструментов разработки будем использовать горячо любимую Visual Studio.

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

Я знаю, о чём вы подумали: «Ещё одна скучная статья про DRY? Нам их мало, что ли?».

Возможно, вы правы. Но я встречаю слишком много разработчиков (junior и senior), применяющих DRY так, словно они охотятся на ведьм. Либо совершенно непредсказуемо, либо везде, где можно. Так что, судя по всему, в интернете никогда не будет достаточно статей о принципе DRY.

Если кто не знает: принцип DRY — это "Don't Repeat Yourself" (не повторяйся), и впервые о нём упомянуто в книге The Pragmatic Programmer. Хотя сам по себе этот принцип был известен и применялся задолго до появления книги, однако в ней ему было дано название и точное определение.

Итак, без лишних рассуждений отправимся в путешествие по чудесной стране DRY!

Эту книгу советует Алан Кей. Он часто говорит фразу «Компьютерная революция еще не случилась.» Но компьютерная революция началась. Точнее — ее начали. Ее начали определенные люди, с определенными ценностями и у них было видение, задумки, план. Исходя из каких предпосылок революционеры создали план? По каким причинам? Куда они замыслили вести человечество? На каком этапе мы сейчас?

(За перевод спасибо Oxoron, кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru)

От переводчика

Мы — внедрители. Мы должны внедрять, а не фантазировать!
(Рина Зеленая, к/ф «Девушка без адреса»)

К переводу этой статьи меня побудили две причины: 1) желание лучше разобраться с фреймворком Spring, 2) небольшое количество источников по теме на русском языке.

Краеугольный камень ООП — «внедрение зависимостей». Если описание процесса «внедрения» в целом, удовлетворительно, то объяснение понятия «зависимость» обычно оставляют за скобками. На мой взгляд, это существенное упущение.



Чтобы не фантазировать, а внедрять, нужно сначала разобраться с тем, что мы внедряем. И в этом нам может помочь лаконичная статья Jakob Jenkov «Understanding Dependencies». Она будет полезна не только тем, кто пишет на Java, но и тем, кто пишет на других языках и следит за качеством проектирования приложений.

UPD: Я перевел еще одну статью Jakob Jenkov о зависимостях. Читайте на Хабре перевод статьи Dependency Injection, которая открывает одноименную серию статей и по смыслу продолжает данную статью. В статьях серии рассматриваются такие понятия как Dependency, Dependency Injection (DI), DI-контейнеры.

Эта статья является продолжением темы «неквалифицированного заказчика», а также попыткой проанализировать причины взаимной неудовлетворенности менеджеров и специалистов в неудачных проектах. Думаю, что моим коллегам знакома ситуация, когда проект провалился и команда пытается понять причины.

Толчком для формулирования концепции «неквалифицированного исполнителя» послужила «Черная книга менеджера» Славы Панкратова, а точнее, кусочек из главы 5 «Люди».

Если человек чего-то не делает, есть 4 причины

1. Не понял
2. Не умеет
3. Не может
4. Не хочет»

Именно в такой последовательности эти причины следует рассматривать. Но вот как понять, какая из них привела к неудаче? Идти сверху вниз и использовать методы наблюдения? Просто поговорить «начистоту»? Но не факт, что в результате получим правильное понимание.

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

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



Я — IT-предприниматель с 20 летним стажем. Так получилось, что с самого начала карьеры мне пришлось управлять людьми. Как выпускник технического вуза и айтишник, я изначально понял, что люди сложно поддаются алгоритмизации, и вообще осознанию, пониманию и прогнозированию.

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

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

Этим летом я прочитал книгу Илона Маска Tesla, SpaceX, and the Quest for a Fantastic Future. Замечательное чтиво и подробный рассказа о взлётах и падениях одного из крупнейших визионеров нашего времени. Также книга позволила ознакомиться с рабочей этикой Маска и секретами продуктивности, которыми он пользуется для управления несколькими компаниями.

Этот список появился как личная памятка по темам, которые я обсуждал с коллегами и друзьями и в которых хотел разобраться поглубже…

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

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

В постмортемах многих игр часто повторяется одно и то же клише. Оно всплывает и в разговорах с инди-разработчиками. Звучит клише примерно так: «Чёртовы потребители! Они каждый день тратят по пять баксов на один и тот же безвкусный латте из Starbucks, но не могут выделить ту же сумму на покупку моей созданной с любовью, графически красивой инди-игры, которую я, вложив душу, разрабатывал целых три года? Почему, почему люди не могут дать моей игре шанса?»

Да, выбор кажется очевидным: или один и тот же пережаренный кофе или поистине независимое творение мысли.

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

Нежелание покупателя тратить пять долларов на странную инди-игру связано с тем, что он не представляет, какая она. Хорошо ли она сделана? Как долго можно в неё играть? На что похожа эта игра? Но, что более важно — кто её сделал? В конце концов, нам, инди-разработчикам нужно преодолеть огромное препятствие: установить взаимоотношения с нашими игроками, чтобы они доверяли нам и покупали наши игры.

«То, что привело вас к успеху, может стать неэффективным в будущем.»

Привет, Хабр. Помните офигенную статью «Вы и ваша работа» (+219, 2244 в закладки, 351k прочтений)?

Так вот у Хэмминга (да, да, самоконтролирующиеся и самокорректирующиеся коды Хэмминга) есть целая книга, написанная по мотивам его лекций. Давайте ее переведем, ведь мужик дело говорит.

Это книга не просто про ИТ, это книга про стиль мышления невероятно крутых людей. «Это не просто заряд положительного мышления; в ней описаны условия, которые увеличивают шансы сделать великую работу.»

Мы уже перевели 8 (из 30) глав.

Глава 26. Эксперты

(За перевод спасибо Mitroshin Evgeny, который откликнулся на мой призыв в «предыдущей главе».) Кто хочет помочь с переводом — пишите в личку или на почту magisterludi2016@yandex.ru

Как было отмечено в пятой главе, количество проблем предстающих перед нами растёт экспоненциально, и в качестве решения, мы справляемся с этим с помощью специализации. Это высказывание с годами становится лишь более правдивым:

Эксперт — это тот, кто знает всё в чём-то малом, эрудит — это тот кто знает мало, зато обо всём.

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

Спросите любого инди-разработчика игр, в чём заключается секрет маркетинга инди-игр, и от каждого слышите почти одинаковый ответ: нужно попасть в список рекомендаций Steam или магазина мобильных приложений, добиться обзоров в прессе, сделать так, чтобы в вашу игру сыграл популярный стример. В противном случае, игра, в которую вы вложили кучу сил и времени, просто провалится.

Но представьте рынок, на котором такие рекомендации неприменимы. На нём нет таких вещей, как Steam Launch Visibility Round или рекомендации в App Store. Что, если нет прессы, с радостью пишущей обзоры? И что, если вместо 7667 игр, выпущенных в Steam в 2017 году, в тот же год выпущено больше 100 000 новых книг? А общее количество книг на рынке превышает 4 000 000 наименований?

Введение

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

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

Вот уже несколько лет в России развивается движение открытых .NET-сообществ. Первопроходцем стало питерское сообщество SpbDotNet, стартовавшем в 2015 году. Последователем питерского сообщества стало московское сообщество MskDotNet, проводящее встречи с 2016 года. Разумеется, оба сообщества очень хорошо дружат и оказывают посильную взаимопомощь. С начала создания сообществ были проведены десятки встреч, рассказаны более сотни докладов. Отлично! Давайте немного поговорим о настоящем и будущем .NET движений.

День сегодняшний

За время существования наших замечательных коммьюнити были проведены десятки встреч, обсуждены тысячи вопросов, как в форме докладов, так и в форме живого общения в кулуарах. Многие познакомились с новыми коллегами, обзавелись полезными связями, нашли ответы на интересующие их вопросы, получили море позитива, а кто-то даже нашёл новых друзей. Те, кто по каким-либо причинам не посещают, или не могут посетить наши встречи вживую — смотрят наши видео на youtube. Кстати, на данный момент наш YouTube-канал пополняется записями и с MskDotNet и c SpbDotNet. На нём выложены уже более 70 видео с докладами. Звучит просто отлично!

«Какие у вас есть вопросы?» – вопрос, который гарантирован на любом собеседовании на работу.
«И если у кандидата нет вопросов, то вопрос возникает по поводу кандидата» – как-то сказала мне знакомая HR из Кремниевой долины в разговоре о поиске работы в США.

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

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

Мы начинаем профессиональный «разбор полетов» выступлений с HighLoad++, который поможет многим будущим и нынешним спикерам поучиться на чужих примерах. В прошлой публикации я рассказывал о том, что именно я буду делать и зачем все это нужно. Завершать каждый материал будет небольшой рассказ о важности какого-то определенного параметра в выступлении.



Первым под прицел попал Артем Данилов из Авито и его доклад про хранилище данных. В конце же вас ждет экскурс про дикцию.