TL;DR: Конференции компании JUG Ru Group, запланированные на апрель и май этого года (DotNext, Heisenbug, HolyJS, C++ Russia, DevOops и JPoint), переносятся на июнь-июль из-за коронавируса.

Законы, теории, принципы и закономерности, полезные для разработчиков

Введение

Перевод репозитория github.com/dwmkerr/hacker-laws

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

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

Законы

Закон Амдала

Закон Амдала — это формула, демонстрирующая потенциал ускорения вычислительной задачи, которого можно достичь при увеличении количества ресурсов системы. Обычно он используется в параллельных вычислениях, и может предсказать наличие реальных преимуществ от увеличения количества процессоров с учётом ограничений параллелизуемости программы.

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

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

Но ведь в интернете буквально сотни статей про ФП и монады, зачем писать еще одну?

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

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

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

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

Хотя люди обычно признают удобства ФП фич, ведь намного приятнее писать:

int Factorial(int n)
{
    Log.Info($"Computing factorial of {n}");
    return Enumerable.Range(1, n).Aggregate((x, y) => x * y);
}

чем ужасные императивные программы вроде

int Factorial(int n)
{
    int result = 1;
    for (int i = 2; i <= n; i++)
    {
        result *= i;
    }
    return result;
}

Так ведь? С одной стороны да. А с другой именно вторая программа в отличие от первой является функциональной.

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

В предыдущей статье я поделился своим видением процесса построения базовой системы для организации собственного развития (применимой к сфере ИТ).

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

Так что всех заинтересованных прошу под кат!

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

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

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

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

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

В последнее время я много экспериментировал с процедурной генерацией на основе ограничений. В частности, с алгоритмом Wave Function Collapse (WFC, коллапс волновой функции). Я даже написал собственную open source-библиотеку и ассет unity.

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

В этой статье я расскажу, чему научился и что сможет поднять генераторы на основе ограничений на новый уровень.

• Появился шрифт JetBrains Mono — приятный и красивый шрифт для разработчиков

  
  

• Вышел плагин для интеграции GitLab с IntelliJ IDEA. Теперь можно делать код-ревью прямо в вашей любимой IDE!

  
  

• В Java-плагине для Visual Studio Code добавили кучу важных ништяков (действительно влияющих на качество жизни). Теперь в браузере файлов есть компактизация папок в привычный нам вид (как в Идее), у методов можно смотреть иерархию вызовов, в отладчике можно ставить брейкпоинты с условием (сработают, только если выполнилось условие), запускатор тестов визуально отображает статус теста (не нужно постоянно смотреть логи), и еще много всего.

  
  

• Вышел Repeat 5.4, кроссплатформенный (Mac/Lin/Win) инструмент для хоткеев, макросов и автоматизации, на 70% написанный на Java. 442 коммита, 574 звездочки, проект пользуется массовой любовью и обожанием у своей узкой аудитории. Разрабатывается ровно одним человеком.

В прошлом году у Андрея Акиньшина (DreamWalker) вышла книга «Pro .NET Benchmarking»: подробнейший труд о бенчмаркинге, полезный как .NET-разработчикам, так и айтишникам других направлений.

Когда до её выхода оставалась пара месяцев, мы проводили конференцию DotNext 2019 Piter, где в онлайн-трансляции расспросили Андрея про книгу и вообще про бенчмаркинг. Казалось бы, с тех пор это интервью должно было устареть: там о книге говорят в будущем времени, а сейчас ей уже полгода. Но за эти полгода человечество не стало как-то иначе считать 99-й перцентиль — так что для всех, кому может пригодиться бенчмаркинг, в ответах Андрея по-прежнему много актуального и интересного.

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

Годами эксперты в С++ рассуждают о семантике значений, иммутабельности и разделении ресурсов за счет коммуникации. О новом мире без мьютексов и гонок, без паттернов Command и Observer. На деле все не так просто. Главная проблема по-прежнему в наших структурах данных.



Иммутабельные структуры данных не меняют своих значений. Чтобы что-то с ними сделать, нужно создавать новые значения. Старые же значения остаются на прежнем месте, поэтому их можно без проблем и блокировок читать из разных потоков. В итоге ресурсы можно совместно использовать более рационально и упорядоченно, ведь старые и новые значения могут использовать общие данные. Благодаря этому их куда быстрей сравнить между собой и компактно хранить историю операций с возможностью отмены. Все это отлично ложится на многопоточные и интерактивные системы: такие структуры данных упрощают архитектуру десктопных приложений и позволяют сервисам лучше масштабироваться. Иммутабельные структуры — секрет успеха Clojure и Scala, и даже сообщество JavaScript теперь пользуется их преимуществами, ведь у них есть библиотека Immutable.js, написанная в недрах компании Facebook.

Под катом — видео и перевод доклада Juan Puente с конференции C++ Russia 2019 Moscow. Хуан рассказывает про Immer — библиотеку иммутабельных структур для C++. В посте:

• архитектурные преимущества иммутабельности;
• создание эффективного персистентного векторного типа на основе RRB-деревьев;
• разбор архитектуры на примере простого текстового редактора.

Функция Аккермана — одна из самых знаменитых функций в Computer Science. С ней связан как минимум один фундаментальный результат и как минимум один просто важный. Фундаментальный результат, говоря аккуратно и непонятно, таков: существует всюду определённая вычислимая функция, не являющаяся примитивно-рекурсивной. Важный результат заключается в том, что лес непересекающихся множеств (также известный как disjoint set union) работает очень быстро.

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

Из текста ниже вы узнаете, что такое примитивно-рекурсивные функции и как выяснить, что функция Аккермана к таковым не относится. И, конечно, этот текст убедит вас в том, что это невероятно красивая конструкция и невероятно красивое рассуждение!

Существует распространённое мнение о том, что винтажная техника 70-х — 80-х годов многократно превосходит современную по верности воспроизведения. Мол, трава была зеленее, земля круглее, солнце ярче, АЧХ ровнее, а инженеры талантливей и ответственней. Отчасти я готов с этим согласиться, особенно, когда речь о некоторых акустических системах и усилителях. Притязания покупателей того времени и недостатки источников музыкального сигнала делали своё дело. Но всё ли так однозначно было с наушниками? Я решил выяснить на примере легендарной флагманской разработки компании AKG из конца 80-х годов — гибридных диностатических наушников AKG K340.

Тут вот праздники скоро. Спросил недавно друг «как мне это все пережить?». Я сначала объяснял, а потом решил написать статью на Хабр. Рассказанное — услышит один человек, а написанное — прочитают сотни!

Меня, если честно, достаточно сильно раздражают всевозможные застолья. Потому что гораздо приятнее посидеть с паяльником или читая книгу, а не "… хорохорясь, ерепенясь и валяясь, как колода..." провести выходные. Но традиции-с, будь они неладны, формировались столетиями и не умея пить — бывает достаточно сложно вписаться в коллектив, найти нужный подход и т.д. Особенно грешат этим делом всевозможные руководящие кадры из старого поколения. Что же делать тем, для кого алкоголь и необходимость его употреблять — это просто лишняя головная боль? Самый простой ответ — НЕ ПИТЬ, но на практике полностью это очень сложно реализовать. Эффективнее в наших реалиях принять тезис «алкоголь — просто инструмент» и учиться с ним правильно работать и использовать для решения своих задач с минимизацией ущерба для здоровья.

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

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

В этой статье мы рассмотрим некоторые из основных методик приведения (inference techniques) в оптимизирующих компиляторах: как спроектировать программу, с которой компилятору будет легко работать; какие приведения можно сделать в вашей программе и как использовать их для её уменьшения и ускорения.

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

Рецепт системы ZenCad довольно прост. Концепт скриптового 3д моделирования OpenScad, геометрическое ядро OpenCascade, python3 в качестве клея, библиотека ленивых вычислений evalcache для агресивного кеширования вычислений. Добавить специй еще из пары-тройки инструментов, приправить gui под соусом PyQt, и подать к столу перемешав, но не взбалтывая.

Теперь асинхронную связь внедряют не только на удалёнке

Иллюстрация: Yin Weihung

Исследование за исследованием вновь доказывают, что удалённые работники более продуктивны, чем их коллеги в офисе.

Только не совсем понятно, почему.

Да, люди сохраняют время (и рассудок), избегая пробок в час пик. На них не действуют отвлекающие факторы в офисе. Они обретают чувство контроля над рабочим графиком. Больше времени остаётся для семьи, друзей и хобби.

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

Силовая установка — звучит как-то странно, но если подумать, то очень четко описывает те самые компоненты которые заставляют модель двигаться. Не уверен входит ли сюда сервопривод (лево/право). Если вы читали первую часть этого цикла, то вы знаете, что есть модели на ДВС и на электромоторах. Так как по большей части я описываю свой опыт — речь пойдет об электромоторах и комплектующих под них.

Обучение с подкреплением (Reinforcement Learning) делится на два больших класса: Model-Free и Model-Based. В первом случае действия оптимизируются напрямую по сигналу награды, а во втором нейросеть является только моделью реальности, а оптимальные действия выбираются с помощью внешнего планировщика. У каждого подхода есть свои достоинства и недостатки.

Разработчики из Berkeley и Google Brain представили Model-Based алгоритм PDDM с улучшенным планировщиком, позволяющий эффективно обучаться сложным движениям с большим числом степеней свободы на небольшом числе примеров. Чтобы научиться вращать мячи в роботизированной руке с реалистичными суставами пальцев с 24 степенями свободы, потребовалось всего 4 часа практики на реальном физическом роботе.

В смысле, привет, Хабр! Если вы можете сказать про себя слово «интроверт» (как и я) то вас, скорее всего, можно заносить в эту категорию. Другое дело, что категория, мягко говоря, размыта. И в неё от души навалено сразу несколько синдромов.

Но сначала главное. Итак, есть версия, что мозг приматов развился до невероятных высот рода Homo из-за социальных взаимодействий. Это когда надо думать за себя, потом как вон та обезьяна-вожак, потом его ближайшее окружение, потом как все омеги (можно посчитать их за одного, ладно), нужно продумать действия, понять, что они сделают в ответ, учесть, что они могут предсказать такой ход наших мыслей. В общем, кончается это рекурсией и высокой вычислительной сложностью. Механизмы, позволяющие прогнозировать реакции других — начиная от зеркальных нейронов — так плотно в нас вшиты, что если мы посмотрим видео про зубного и его пациента, то почувствуем сами отголосок его реакции.

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

А теперь давайте разбираться в деталях.