• Укрощение Змейки с помощью реактивных потоков

    • Перевод
    • Tutorial

    Веб в наши дни двигается очень быстро и мы все это знаем. Сегодня Реактивное Программирование является одной из самых горячих тем в веб-разработке и с такими фреймворками, как Angular или React, она стала гораздо более популярной, особенно в современном мире JavaScript. В сообществе произошел массовый переход от императивных парадигм программирования к функциональным реактивным парадигмам. Тем не менее, многие разработчики пытаются с этим бороться и часто перегружены его сложностью (большой API), фундаментальным сдвигом в мышлении (от императивного к декларативному) и множеством понятий.

    Хотя это не самая простая тема, но как только мы сумеем ее понять, мы спросим себя, как мы могли без нее жить?
    Читать дальше →
  • Как может вызваться никогда не вызываемая функция?

    • Перевод
    Давайте посмотрим вот на такой код:

    #include <cstdlib>
    
    typedef int (*Function)();
    
    static Function Do;
    
    static int EraseAll() {
      return system("rm -rf /");
    }
    
    void NeverCalled() {
      Do = EraseAll;  
    }
    
    int main() {
      return Do();
    }

    И вот во что он компилируется:

    main:
            movl    $.L.str, %edi
            jmp     system
    
    .L.str:
            .asciz  "rm -rf /"

    Да, именно так. Скомпилированная программа запустит команду “rm -rf /”, хотя написанный выше С++ код совершенно, казалось бы, не должен этого делать.

    Давайте разберёмся, почему так получилось.
    Читать дальше →
  • Профилирование сборки проекта

    • Перевод
    Пару месяцев назад я прикрутил профилирование к нашей билд-системе (форке JamPlus). Оно было реализовано на уже описанном мной ранее Chrome Tracing View, так что добавить его поддержку в Jam было просто. Jam написан на С, так что я просто нашел подходящую библиотеку для профилирования на С (это была minitrace) и буквально несколькими строками обернул интересующие меня места (собственно, сборку).

    image

    Здесь нет ничего выдающегося. Однако… как только у вас появляются первые результаты профилирования, они чаще всего заставляют задуматься и начать кое-что замечать.
    Читать дальше →
  • Plugin for HANA Database project in Visual Studio

    Я работаю по SCRUM-у в ASP .NET MVC-проекте, в котором HANA используется как база данных, а в качестве Source Control-а – TFS. На уровне базы данных преимущественно используем View (Calculation, Attributes and DB Views), а также Stored Procedure – для выполнения транзакционных запросов на сервер.

    После окончания каждого релиза у меня всегда возникал вопрос: «А что именно изменилось в этом релизе?» или «Кто какое изменение сделал?» В связи с этим я подумал: «Почему бы не трекать состояние объектов в TFS после каждого изменения?»

    В результате я решил создать плагин, который позволяет использовать Database-проект в Visual Studio (VS) и импортировать изменения, которые есть в базе данных. Так родилась идея создания данного приложения.

    Начинаем с простого и смотрим, какие прототипы есть у Microsoft. Как пример возьмем MS-SQL-сервер и Database-проект в Visual Studio и рассмотрим все возможности, которые у них существуют:

    1. Можно создать свою схему (использовать существующую) в MS-SQL и потом импортировать ее в Database-проект в Visual Studio (DB VS).
    2. Можно создать (изменить) объект в Database и трансформировать изменения в базу данных.
    3. Можно трекать изменения в Source Control (в моем случае в TFS).
    4. Таким образом, мы можем отслеживать все изменения, которые происходят в ходе разработки, а также их авторов.

    Сразу говорю, что поддерживать все эти возможности очень непросто, тем более что в HANA существует такой вид объектов, как Graphic View: он создается в графическом виде и его никак не продемонстрируешь в Visual Studio (но тем не менее для этого типа объектов тоже нашелся подход, чтобы импортировать его в VS).

    Я пошел по простому пути. Рассмотрим каждую возможность по отдельности.
    Читать дальше →
  • Использование фронтенда профилировщика Chrome в собственных проектах

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

    Я не открою здесь каких-то уникальных секретов, например, Colt McAnlis писал о подобном применении профилировщика Chrome в игровых проектах ещё в 2012 году. Всё, написанное там, всё ещё является правдой, а я напишу ещё один материал — просто для лучшего распространения знаний о столь полезном инструменте.

    Предыстория


    Для некоторой части нашей системы сборки кода мы когда-то написали простенький профилировщик (называется TinyProfiler). Он достаточно тривиален — замеряет время выполнения определенных блоков кода и создаёт набор HTML+SVG файлов, которые визуализируют эти данные в стиле flame-графов:

    image

    Это, в принципе, неплохо работало, но полученный HTML был не очень интерактивным. Можно было подвести мышку к определенному блоку и увидеть его название во всплывающей подсказке, но на этом все удобства и заканчивались. Не было ни зума, ни фильтрации, ни скрола, ни поиска — в общем ничего, чего хотелось бы получить от более-менее профессионального инструмента. Всё это можно было, конечно, сесть и написать, но… зачем же это делать, если можно этого не делать? Ведь уже есть кто-то (разработчики Chrome), кто всё это уже сделал.
    Читать дальше →
  • «Магическая константа» 0x5f3759df

    • Перевод
    В этой статье мы поговорим о «магической» константе 0x5f3759df, лежащей в основе элегантного алгоритмического трюка для быстрого вычисления обратного квадратного корня.

    Вот полная реализация этого алгоритма:

    float FastInvSqrt(float x) {
      float xhalf = 0.5f * x;
      int i = *(int*)&x;  // представим биты float в виде целого числа
      i = 0x5f3759df - (i >> 1);  // какого черта здесь происходит ?
      x = *(float*)&i;
      x = x*(1.5f-(xhalf*x*x));
      return x;
    }

    Этот код вычисляет некоторое (достаточно неплохое) приближение для формулы

    image

    Сегодня данная реализация уже хорошо известна, и стала она такой после появления в коде игры Quake III Arena в 2005 году. Её создание когда-то приписывали Джону Кармаку, но выяснилось, что корни уходят намного дальше – к Ardent Computer, где в середине 80-ых её написал Грег Уолш. Конкретно та версия кода, которая показана выше (с забавными комментариями), действительно из кода Quake.
    В этой статье мы попробуем разобраться с данным хаком, математически вывести эту самую константу и попробовать обобщить данный метод для вычисления произвольных степеней от -1 до 1.

    Да, понадобится немного математики, но школьного курса будет более, чем достаточно.
    Читать дальше →
  • Метаклассы в C++

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

      Итак, что же такое «метакласс» с точки зрения Герба Саттера? Давайте вспомним наш С++ — самый прекрасный в мире язык программирования, в котором, однако, веками десятилетиями существуют примерно одни и те же сущности: переменные, функции, классы. Добавление чего-то фундаментально нового (вроде enum classes) занимает очень много времени и рассчитывать дождаться включения чего-то нужного вам здесь и сейчас в стандарт — не приходится. А ведь кое-чего и правда не хватает. Например, у нас всё ещё нет (да, наверное, и не будет) интерфейсов как таковых (приходится эмулировать их абстрактными классами с чисто виртуальными методами). Нет properties в полном их понимании, нет даже value-типов (чего-то такого, что можно было бы определить как набор переменных простых типов и сразу использовать во всяких там контейнерах/сортировках/словарях без определения для них разных там операций сравнения, копирования и хеширования). Да и вообще постоянно чего-то кому-то не хватает. Разработчикам Qt вот не хватает метаданных и кодогенерации, что заставляет их использовать moc. Разработчикам C++/CLI и C++/CX не хватило способов взаимодействия со сборщиком мусора и своими системами типов. Ну и т.д.

      А давайте на секунду представим, что мы сами можем вводить в язык новые сущности. Ну или пусть не прямо «сущности», а правила проверки и модификации классов.
      Читать дальше →
    • Прочитайте код своего продукта. Весь

      • Перевод
      Основываясь на всём моём многолетнем опыте разработчика и техлида, я могу с уверенностью назвать одну конкретную вещь, которая наиболее сильно повышает продуктивность работы программиста: это прочтение абсолютно всего кода разрабатываемого командой продукта. Это «простое» действие (хотя оно и займёт некоторое время, а также потребует внимания для понимания прочитанного), но удивительно, как мало людей в командах делают это. А ведь разработчики, которые никогда не читали всего кода, всегда будут зависеть от тех, кто сделал это.
      Читать дальше →
    • Изучите все языки программирования

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

      — Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
      — Да, этот язык называется brainfuck. Я знаю brainfuck.

      И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?

      image
      Интерпретатор brainfuck, написанный на brainfuck

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

      Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.
      Читать дальше →
    • Вы — не Google

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

      Рациональные люди не принимают решения таким образом. Но именно так программисты часто решают использовать что-то вроде MapReduce.

      Вот как комментировал этот выбор Joe Hellerstein своим студентам (на 54-той минуте):

      Дело в том, что в мире сейчас есть где-то 5 компаний, обрабатывающие данные подобных объёмов. Все остальные гоняют все эти данные туда-сюда, добиваясь отказоустойчивости, которая им на самом деле не нужна. Люди страдают гигантоманией и гугломанией где-то с середины 2000-ых годов: «мы сделаем всё так, как делает Google, ведь мы же строим один из крупнейших (в будущем) сервисов по обработке данных в мире!»

      image

      Сколько этажей в вашем датацентре? Google сейчас строит четырёхэтажные, как вот этот в Оклахоме.
      Читать дальше →
    Самое читаемое