Заканчивается неделя постов про карму. В очередной раз разжевано, почему карма — плохо, в очередной раз предлагаются изменения. Давайте прикинем, почему карма — это хорошо.

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

Основа основ Хабра — это посты. Под многими встречаются ценные комментарии, иногда даже ценнее поста. Время «активной» жизни большинства постов — два-три дня. Затем обсуждение затихает, и пост открывают либо из закладок, либо по выдаче гугла.

У авторов должна быть мотивация писать посты. Вариантов несколько.

1. Деньги. Это редакция, возможно, потоковые переводчики.
2. Проф-заказ. В основном, статьи в корпоративных блогах.
3. Личность. Хочется поделиться чем-то важным (или интересным), структурировать собственные знания, показать себя перед условным будущим работодателем.

Мощность квантового компьютера измеряется в кубитах, базовой единице измерения в квантовом компьютере. Источник.

Я делаю фейспалм после каждого прочтения подобной фразы. До добра это не довело, начало садиться зрение; скоро придется обращаться к Meklon.

Думаю, пора несколько систематизировать основные параметры квантового компьютера. Их несколько:

1. Количество кубитов
2. Время удержания когерентности (время декогеренции)
3. Уровень ошибок
4. Архитектура процессора
5. Цена, доступность, условия содержания, время амортизации, инструменты программирования, и т.д.

Если живешь среди сумасшедших, надо и самому научиться быть безумным

Вы когда-нибудь пробовали «научиться быть безумным»? Нетривиальная задачка. Даже нормальной методики не найдешь, ибо каждый сходит с ума по-своему. Моя первая попытка: теория заговора. Теория не предполагает практики, а значит не придется много работать. Опять-таки, при любом раскладе никто не пострадает.


Итак, еретическая теория: через 5 лет Пейдж и Грин решат, кто будет главным в Google, и сделают это с помощью игры. У каждого из них есть группа исследователей. Команда AlphaGo со своими боевыми нейросетями натянула соперников в Го. Оппоненты вынуждены были искать новые методы, и таки обнаружили инструмент тотального превосходства: квантовые вычисления.

Можно ли использовать Квантовые Вычисления для игр? Легко. Покажем для примера, что игра «охотник на лис» может быть «решена» за 6 ходов. Ради правдоподобности ограничимся 15 кубитами (онлайн-редактор quirk больше пятнадцати не эмулирует), ради простоты проигнорируем ограничения архитектуры процессора и коррекцию ошибок.

В недавней статье товарищ KvanTTT поднял вопрос:

Можете пояснить что вам не нравится в современной записи (математических положений и) формул и как ее можно улучшить?

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

Сразу скажу, материал холиварный. Местами слишком эмоциональный. Очень спорный. Слишком личный — часто основан на собственном опыте, небогатом, хоть и разнообразном. Пост касается школьных и университетских текстов учебников: у «профессиональной» литературы своя специфика, своя аудитория. Решения у проблемы в текущих реалиях нет. При этом, часть «моих» наблюдений задолго до меня высказывали такие авторитеты, как Кнут и Хэмминг; чуть менее популярные ребята даже запилили инструкцию "Как читать математику".

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

Стажировки очевидно бывают разные. В моей компании стажируют джунов. Чтобы был понятен контекст: компания в ~300 человек, разрабатываем на Java\C#\10 видов JS, разработчиков стажируем только в 2 городах в Литве. Веб-сайты, банки, электростанции, зоопарки — проекты самые разные. Компания растет, нужны люди. Один из вариантов найма: стажировка.

Обычный стажер-разработчик — студент 2-4 курса, IT, математика; стажируется параллельно учебе в Вильнюсе или Каунасе. Начинает стажировку 40 человек, заканчивает 30-35, 10 нанимается джунами.

10 человек — это не просто красивое число. Для нанятого джуна нужен хотя бы один сеньор\лид, имеющий свободное время и проект, куда стажера можно безболезненно ввести и загрузить, где он получит экспу и принесет пользу (и пройдет клиентскую проверку безопасности). Плюс, нет резона вешать джуна на сеньора, который не горит желанием быть наставником. Плюс, джависты не горят желанием нанимать .NET стажеров.

Читать я начал в 5-4-3 года. Цифра, называемая моей мамой, почему-то уменьшается со временем. До сих пор помню диван, пушистое одеяло на нем, и несколько букв вырезанных из цветной бумаги. «Мама», «папа», «Саша» — составление слов казалось чудом.

Научившись составлять слова, я незаметно научился их разбирать. Сказки Андерсена, «Денискины рассказы», энциклопедии — столько всего можно было прочитать! И я читал. Чтение уже не казалось чудом, но сколько же чудес было в описываемых мирах.

Разработчик обязан знать свои инструменты! Знание инструментов увеличивает продуктивность, эффективность, производительность, потенцию разработчика! Не могу программировать без R#!

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

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

Сегодня я пошвыряю камни в огород Code Coverage (CC). Достаточно полезная метрика, под которой лежат несколько скудно документированных граблей.

На днях объяснял одному товарищу что такое анализаторы Roslyn и как их писать. Ответ получился массивным, и я решил вынести его в отдельную публикацию.

Что такое анализаторы Roslyn? Если коротко — это отличный способ писать рефакторинги вроде Решарперовских. Постоянно встречаете одну и ту же ошибку в процессе ревью? Напишете анализатор с фиксером и забудьте про эту ошибку. Техническая сторона довольно проста, для первоначального знакомства отлично подойдут вот эта статья, вот это видео, вот эта серия постов, и вот этот туториал. Я же попытаюсь описать грабли моменты, которые лично у меня вызывали затруднение.

Все началось лет 8 назад. Я тогда писал одну программу для математических расчетов, и мой преподаватель указал, что я неверно именую переменные. Он был прав: x, xx, xxx сложновато различить в коде. После переименования они превратились в redSegment, greenSegment, blueSegment (в контексте задачи именование было подходящее). Потом были «Рефакторинг» Фаулера, «Совершенный код» Макконнелла, «Паттерны проектирования» банды четырех… каждый день я погружался все глубже в бездну.

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

Близится Новый Год. В Хабаровске он уже наступил, поздравляю!

По традиции, нужно подвести итоги уходящего года, и я решил перечитать свои посты. Перечитать-то перечитал, но как их оценить? Карма? Рейтинг? Просмотры? Слишком сухо и серьезно. Попугаи? Слишком несерьезно. Я решил измерять в Milfgard-ах.

Последние две мои статьи — интервью со спикерами одной прошедшей конференции. Мне показалось интересным поговорить с человеком, который в свое время отказался выступать на этой конференции, “из за одного маленького семейного обстоятельства”. Этот человек — Сергей SergeyT Тепляков, MVP, автор отличной книги про паттерны проектирования, адепт TDD, ныне разработчик Tools for Software Engineers в Microsoft и мейнтейнер библиотеки Code Contracts.

Под катом много текста про конференции, TDD, парное программирование, архитектуру Code Contracts, Хабру.

Некоторые разработчики программируют взглядом. Другие слепы и программируют на слух\ощупь. Отдельным товарищам достаточно маркера и доски. Но все-таки большинство .NET-разработчиков пользуется Visual Studio для кодирования и дебага, парочкой профайлеров, декомпилятором, плагином для VCS, браузерными инструментами, R#\CodeRush, тулзой для контроля базы данных, баг-трекером, билд-системой и кофемашиной.

Мне удалось поговорить с разработчиками некоторых из перечисленных средств разработки.

Под катом — скучная и совершенно неинтересная реклама, немного Roslyn, чуть-чуть Rider, минимум CodeRush, малость описаны фичи C# 7.0, бегло рассмотрены перспективы .NET и один раз упоминается PVS-Studio.

Что такое C#? Объектно-ориентированный эсперанто со сборщиком мусора, функциональными примочками и бесплатным массажем после обеда. Он позволяет писать Действительно Важные Вещи, скрывая от нас ненужные детали работы с памятью, процессором и прочее низкоуровневое программирование. Естественно, находятся люди с повышенным уровнем любопытства в крови, желающие знать как же .NET работает на самом деле (само собой, они изучают .NET исключительно ради повышения производительности разрабатываемого софта). Сегодня с нами разговаривают:

Приветствую. Недавно я наткнулся на статью товарища Dywar «Интересные заметки по C# и CLR» и заинтересовался пунктом 13:

«Константы помещаются в метаданные сборки, поэтому если были изменения, нужно перекомпилировать все использующие ее сборки. Т.к. DLL с константой может даже не загружаться.»

Да ладно, подумал я, и полез ставить эксперименты. Создал проект TestConstants, в нем класс,

public class Master
    {
        public const string Const = "Hello world";
    }

затем проект TestConstantsSlave,

static void Main()
        {
            Console.WriteLine(Master.Const);
            Console.ReadKey();
        }

Заменил константу на “Hello habr”, перебилдил основной проект, запустил по F5…

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

public class Example
{
  private int JustInt;

  // Some code here

  public void DoSomething(Example example)
  {
    this.JustInt = example.JustInt; // Вполне валидная строка, некоторых удивляет
  }
}

Добрый день. Неделю назад я в третий раз применил библиотеку для создания\запуска .NET бенчмарков BenchmarkDotNet. Библиотека оказалась достаточно удобной, но практически не освещенной на хабре, что я сейчас и исправлю.

Под бенчмарком я подразумеваю измерение времени выполнения метода(ов). Для начала представим процесс написания бенчмарка руками. Создаем тестируемый метод, выбираем Release билд, создаем «замеряющий» метод, в нем собираем мусор, ставим StopWatch в начале и в конце, запускаем прогрев, запускаем тестируемый метод. Если тестируемый метод выполняется быстрее одного «тика» StopWatch, запускаем тестируемый метод много раз (пусть будет миллион), делим суммарное время на миллион, получаем результат (при этом нужно не забыть вычесть из суммарного времени время «холостого» прогона цикла на миллион операций).

За последние полтора месяца мне довелось поработать над backend-ом трех проектов. В каждом требовалось подготовить классы для взаимодействия с удаленным сервисом посредством обмена XML-документами; в частности, требовалось подготовить DTO-классы для каждого из типов сообщений. Для каждого из сервисов шло описание от разработчиков, с примерами XML-документов, так что работа была относительно простая: взять пример, прогнать через утилиту xsd, получить класс, поправить типы, добавить недостающие поля\свойства, протестировать. Операции рутинные, после десятка классов думать уже особо не требовалось, так что в голове начали скапливаться мысли, как ускорить процесс разработки либо улучшить выходной результат. Получилось и то, и другое.