На Хабре уже долгое время публикуется совместный перевод (у которого ещё есть отдельный сайт авторства MagisterLudi) замечательной книги Ричарда Хэмминга "The Art of Doing Science and Engineering". Я долгое время хотел её прочитать в оригинале. Да не просто прочитать, а составить насколько возможно краткую выжимку основных идей каждой главы. И вот недавно мне удалось это сделать.

Целью самой книги является "подготовить вас к вашему техническому будущему" путём обучения "стилю" мышления. Поэтому извлечённые идеи в основном имеют достаточно общий характер. Также из-за частого способа передачи идеи в виде историй некоторые пункты статьи являются моей личной их интерпретацией.

Из-за достаточно большого количества материала и его "плотной" подачи данная статья всё равно получилась достаточно объёмной. Поэтому предлагаю её TL;DR.

Есть две булевы функции аргументов, одна — константная, другая — сбалансированная. На какую сам сядешь, на какую фронтендера посадишь? Вот только функции неизвестны, а вызвать их разрешается лишь один раз.

Если не знаешь, как решить подобную задачу, добро пожаловать под кат. Там я расскажу про квантовые алгоритмы и покажу как их эмулировать на самом народном языке — на Python.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Overview and Comparison of Gate Level Quantum Software Platforms" автора Ryan LaRose.

Квантовые компьютеры доступны для использования в облачной инфраструктуре, но в тоже время недавний бурный рост квантовых программных платформ может быть ошеломляющим для тех, кто будет принимать решение, что использовать. В этой статье предлагается текущая картина быстро развивающегося ландшафта квантовых вычислений путем сравнения четырех программных платформ — Forest (pyQuil), QISKit, ProjectQ и комплекта Quantum Development Kit, — которые позволяют исследователям использовать реальные и моделируемые квантовые устройства. Этот анализ охватывает требования и установку, синтаксис языка на примере программ, поддержку на уровне библиотек и возможности квантового симулятора для каждой платформы. Для платформ с поддержкой квантового компьютера мы сравним аппаратные средства, квантовые ассемблерные языки и квантовые компиляторы. В заключение мы рассмотрим особенности каждого из них и кратко упомянем другие пакеты программного обеспечения для квантовых вычислений.

При поиске этого словосочетания англоязычный Гугл выдает 104 000 000 результатов. По статистике, боязнь публичных выступлений входит в топ-5 человеческих страхов. Каждый выступавший признается в интервью, что хотя бы раз испытывал страх перед выступлением.

У команды Microsoft Quantum Team хорошие новости для любителей квантовых вычислений и программистов, желающих бросить себе вызов. Мы рады сообщить о проведении летнего конкурса Microsoft по программированию на Q# — Microsoft Q# Coding Contest — Summer 2018! Приняв участие в нем, вы сможете отточить свои навыки в области квантового программирования, решая задачи различной сложности с помощью языка квантового программирования Q#. Победители получат футболки Microsoft Quantum!

У программы есть цель, о которой иногда забывают

Изображение молотка, лежащего на доске. В доске застрял шуруп, который туда усиленно забивали

Кажется, программисты забыли о предназначении программного обеспечения — решать проблемы реального мира.

50 лет назад, в 1968 году, прошла Рабочая конференция по инжинирингу ПО, организованная Комитетом по науке НАТО. Тогда стали замечать, что программное обеспечение становится фундаментальной частью общества. И одновременно его становится труднее понять. После этой конференции программирование начало превращаться в настоящую индустрию. Оно начало уходить из-под контроля бизнеса.

Цель статьи — рассказать немного о MSBuild, показать что такое таргеты и таски в MSBuild, научить работать с файлом .csproj, дать полезные ссылки. Если у вас будет более подходящее название для статьи, то буду рад обсудить в комментариях.

Меню

• Основные понятия — что такое target и task в MSBuild
• Жизненный цикл сборки MSBuild — какая последовательность вызова таргетов
• Подготовка окружения для примеров
• Таргеты в MSBuild — пример использования некоторых таргетов MSBuild
• Создание собственного таргета MSBuild
• Таски в MSBuild — пример использования некоторых тасков MSBuild
• Переменные и макросы в .csproj
• Ссылки

«Цель этого курса — подготовить вас к вашему техническому будущему.»

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

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

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

Мы уже перевели 21 (из 30) главу. И ведем работу над изданием «в бумаге».

Глава 27. Недостоверные данные

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

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

Позвольте мне начать с испытаний на долговечность. Хорошим примером служит мой опыт, участия в испытаниях жизненного цикла вакуумных труб. Они предназначались к использованию в первых подводных кабелях для передачи голоса с ожидаемым сроком службы 20 лет (после 22 лет мы просто вывели кабель из эксплуатации, которая стала слишком затратной – и это дает хорошее представление о скорости технического прогресса в те дни).

Я провел в играх сотни часов по статистике Стима, и тысячи, если считать на всех платформах. Но что меня поразило, так это соотношение времени в некоторых случаях. На прохождение великолепного Bioshock Infinite у меня ушло 8.5 часов, но на Sacura Clicker — на 12 минут больше. На Clicker Heroes — больше сорока часов, почти столько же, как на Torchlight 2. Фокус в том, что я помнил и хорошо представлял затраты времени на большие игры. Но маленькие игрушки совершенно не отложились в памяти, они украли мое время незаметно, растаскивая по пять-десять минут в течение недель и месяцев.

Когда я осознал это, то подумал, что было бы неплохо прикрутить к этой балерине турбину. То есть сделать полезный таймкиллер — простенькую игру, которая будет не воровать, а инвестировать мое время по пять-десять минут. К примеру, в словарный запас по английскому.

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

Большинство разработчиков знают о важных и нужных HTTP-заголовках. Самые известные — Content-Type и Content-Length, это почти универсальные хедеры. Но в последнее время для повышения безопасности начали использоваться заголовки вроде Content-Security-Policy и Strict-Transport-Security, а для повышения производительности — Link rel=preload. Несмотря на широкую поддержку в браузерах, лишь немногие их используют.

В то же время есть много чрезвычайно популярных заголовков, которые вообще не новые и не очень полезные. Мы можем это доказать с помощью HTTP Archive, проекта под управлением Google и спонсируемого Fastly, который каждый месяц при помощи WebPageTest скачивает 500 000 сайтов и выкладывает результаты в BigQuery.

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

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

DISCLAIMER: вы попались на clickbait. Очевидно, что TDD нельзя назвать ошибочным, но… Всегда есть какое-то но.

Содержание

• Вступление
• Тесты и есть проблема!
  
  • Немного истории
  • Небольшая викторина
• Обзор TDD
  
  • Тесты — это формализованные требования
  • TDD поощряет хорошую архитектуру
  • TDD экономит время
  • Тесты — это лучшая документация
  • Немного выводов
• В чём же решение?
  
  • Несколько примеров
  • Немного про планы

Вчера после публикации статьи zarytskiy «Какой язык программирования выбрать для работы с данными?» я понял, что .net в целом и C# в частности не рассматривается, как инструмент для машинного обучения и анализа данных. Не то, чтобы для этого совсем не было объективных причин, но все же надо восстановить справедливость и потратить пару минут на рассказ о фреймворке Accord.NET.

Итак, в прошлой статье цикла, посвящённого обучению Data Science с нуля, мы с вами разбирали вопрос создания своего собственного набора данных и обучение моделей из библиотеки scikit-learn (Python) на примере задачи классификации спектров излучения ламп и дневного света.

В этот раз, чтобы набор данных не пропадал мы рассмотрим и сопоставим нашей прошлой статье маленький кусочек задачи машинного обучения, но в этот раз реализованный на C#
Милости прошу всех под кат.

Открытый курс машинного обучения mlcourse.ai сообщества OpenDataScience – это сбалансированный по теории и практике курс, дающий как знания, так и навыки (необходимые, но не достаточные) машинного обучения уровня Junior Data Scientist. Нечасто встретите и подробное описание математики, стоящей за используемыми алгоритмами, и соревнования Kaggle Inclass, и примеры бизнес-применения машинного обучения в одном курсе. С 2017 по 2019 годы Юрий Кашницкий yorko и большая команда ODS проводили живые запуски курса дважды в год – с домашними заданиями, соревнованиями и общим рейтингом учаcтников (имена героев запечатлены тут). Сейчас курс в режиме самостоятельного прохождения.

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

1. Инженерная разработка — это цифры. Анализ без цифр — это просто мнение.

2. Создание правильной ракеты занимает бесконечное количество времени. Поэтому следует создавать ракеты, в которых что-то неправильно.

Если вы начинаете или уже давно ведете технический проект, проверьте: может быть все можно сделать намного проще и эффективнее?

Это вторая статья из серии НИИ (Не Искусственный Интеллект), в которой я рассказываю о некоторых приемах изобретательства (читай, о приемах решения технических проблем при управлении проектом).

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

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

Но подробности о проекте и первая его задачка в конце статьи, а пока первая история:

---

История №1

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

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

Собственными силами огромная фармкомпания не справилась с решением этой задачей, а вот один человек смог. Он предложил…

Если вы уже не первый год ведете какой-то проект, поверьте не похож ли он на нож мясорубки из истории №1 или на тарелку из истории №2

Это поможет вам оптимизировать свой проект выкинув из него все лишнее, что только тормозит его.

История №1

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

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

В 1987 году отдел роботизации и автоматизации завода «Электросила» разработал безумно дорогого супер-робота, который точно повторял движение рук рабочего (напоминаю, что это было 30 лет назад (!)), но его производительность оказалась столь малой, что рабочего вернули на заточку, чуть ли не на следующий день.

Для решения проблемы, был вызван внешний консультант из одного НИИ. Консультант начал свою работу, естественно с анализа….

Генерация кода в рантайме — очень мощная и хорошо изученная техника, но многие разработчики все еще неохотно её используют. Обычно изучение Expression Trees начинают с какого-нибудь простого примера типа создания предиката (фильтра) или математического выражения. Но не Expression Trees единым жив .NET-разработчик. Совсем недавно появилась возможность генерировать код, используя сам компилятор — это делается с помощью API библиотек Roslyn/CodeAnalisys, предоставляющих, кроме всего прочего, еще и парсинг, обход и генерацию исходников.

Эта статья основана на докладе Raffaele Rialdi (Twitter: @raffaeler) на конференции DotNext 2017 Moscow. Вместе с Рафаэлем мы проанализируем реальные способы использования кодогенерации. В отдельных случаях они позволяют очень сильно улучшить производительность приложения, что в свою очередь приводит нас к дилемме — если сгенерированный код так полезен и мы собираемся его часто использовать, то как же отлаживать этот код? Это один из фундаментальных вопросов, возникающих в реальных проектах.

Рафаэль — практикующий архитектор, консультант и спикер, имеющий MVP в категории Developer Security начиная с 2003 года, который прямо сейчас занимается бэкендами enterprise-проектов, специализируясь на генерации кода и кроссплатформенной разработки для C# и C++.

Про то, как в Avito работает performance review, я очень много раз рассказывал внутри компании, а этой весной ещё и на двух конференциях — TeamLeadConf и CodeFest. Мы активно вкладываемся в доработку процесса, проводим много экспериментов и собираем кучу полезных данных, поэтому каждое новое выступление стабильно включает в себя какой-то новый контент. Цель этой статьи — не выдать вам готовое коробочное решение, а поделиться всеми практиками и инсайтами, которые мы обнаружили на своем пути.