UPD: схема заменена на вариант с контейнерами из С++11, соавторы — в комментариях ниже

Привет, коллеги!

Я расскажу о библиотеке для Питона с лаконичным названием f. Это небольшой пакет с функциями и классами для решения задач в функциональном стиле.

— Что, еще одна функциональная либа для Питона? Автор, ты в курсе, что есть fn.py и вообще этих функциональных поделок миллион?

— Да, в курсе.

Причины появления библиотеки

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

Недавно в финском городе Оулу завершилась встреча международной рабочей группы WG21 по стандартизации C++, в которой впервые официально участвовали сотрудники Яндекса. На ней утвердили черновой вариант C++17 со множеством новых классов, методов и полезных нововведений языка.



Во время поездки мы обедали с Бьярне Строуструпом, катались в лифте с Гербом Саттером, жали руку Беману Дейвсу, выходили «подышать воздухом» с Винцентом Боте, обсуждали онлайн-игры с Гором Нишановым, были на приёме в мэрии Оулу и общались с мэром. А ещё мы вместе со всеми с 8:30 до 17:30 работали над новым стандартом C++, зачастую собираясь в 20:00, чтобы ещё четыре часика поработать и успеть добавить пару хороших вещей.

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

Вряд ли можно представить мир современных сетевых технологий без DPI (deep packet inspection – глубокий анализ пакетов). На нём держатся системы обнаружения сетевых атак, львиная доля политик безопасности корпоративных сетей, шейпинг и блокировка пользовательского трафика оператором связи – да-да, чтобы выполнять требования Роскомнадзора, средства DPI обязан иметь каждый провайдер.

И всё-таки, при всей своей востребованности, DPI имеет некоторые недостатки. Главный из них в том, что средствам DPI необходимо видеть полезную нагрузку анализируемых пакетов. А что делать, когда клиент использует шифрование? Или, например, если у нас нет DPI здесь и сейчас, но в перспективе потребуется проводить какой-то анализ текущего по сети трафика – тогда нам остаётся только сохранять всю полезную нагрузку для последующего анализа, что очень неудобно.

В данной статье я хочу предложить альтернативный способ решения одной из главных задач DPI – определения протокола прикладного уровня – на основе очень маленького количества информации, при этом не сверяясь со списком широко известных портов (well-known ports) и не глядя в полезную нагрузку пакетов. Вообще.

Всё началось с того, что мне понадобилось написать функцию, принимающую на себя владение произвольным объектом. Казалось бы, что может быть проще:

template <typename T>
void f (T t)
{
    // Завладели экземпляром `t` типа `T`.
    ...

    // Хочешь — переноси.
    g(std::move(t));

    // Не хочешь — не переноси.
    ...
}

Но есть один нюанс: требуется, чтобы принимаемый объект был строго rvalue. Следовательно, нужно:

1. Сообщать об ошибке компиляции при попытке передать lvalue.
2. Избежать лишнего вызова конструктора при создании объекта на стеке.

А вот это уже сложнее сделать.

Поясню.

Эта статья является второй в цикле о библиотеке cpprt, предназначенной для добавления и использования минимальной метаинформации о классах С++.

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

В статье затрагиваются вопросы лицензирования, структуры проекта и достаточно много внимания уделяется CMake.

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

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

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

В этом цикле статей будет я подробно рассказываю о том, как создавал свою микро-библиотеку, реализующую подобное поведение и как готовил её к публикации.

Некоторое время назад мне захотелось написать свой небольшой интерпретируемый скриптовый язык, просто ради фана, не ставя перед собой каких-либо серьезных задач. Я тогда активно читал известную волшебную книгу SICP (Структура и интерпретация компьютерных программ), и мне захотелось реализовать описываемые в ней абстракции — функции как объекты первого класса, замыкания, макросы и т.п. Параллельно я интересовался языком Haskell, и решил совместить приятное с приятным, и написать интерпретатор языка на нем. В моем языке должна была быть строгая семантика с вызовом по значению и мутабельные переменные. Получившийся язык Lisp-семейства я в своем локальном окружении связал с именем Liscript, полная реализация которого уместилась в примерно 250 строк, включая парсер, ядро и консольный/файловый ввод-вывод. Этого более чем хватало, чтобы ради интереса решать любые задачки, какими обычно мучают студентов, которых угораздило изучать Lisp по учебной программе.

По прошествии времени мне захотелось сделать к интерпретатору кроссплатформенный GUI-интерфейс с перспективой портирования на Android, поэтому я реализовал второй вариант интерпретатора на Java, внешний вид которого вы можете видеть на картинке выше. Да, он поддерживает графический вывод и вообще interoperability с Java, и этот Тетрис написан на Liscript, видна часть его кода. Кому интересны подробности — прошу под кат.

Надеюсь, кто хотел, ознакомился с моим пробным экспериментом на Хабре в этой статье. Теперь я считаю, что будет правильным огласить его результаты и даже дать более детальное объяснения причин, по которым вообще подобные эксперименты проводятся. Пост будет наполовину философским, поскольку сейчас в компьютерном мире всё настолько сложно, что без философского осмысления принять какие-то осмысленные решения просто невозможно. Я постараюсь вообще выразить своё мнение о сферических измерениях в вакууме, поэтому будет много букв. В статье есть опрос, проводимый до 1-го мая 2016. Под катом целиком ИМХО.

От автора:

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

Теперь, когда мы понимаем основные принципы Rx, настало время научиться создавать и управлять последовательностями. Стиль управления последовательностями был позаимствован у оригинального C# LINQ, который в свою очередь был вдохновлен функциональным программироанием. Мы поделим все операции по темам, которые отсортированы в порядке возрастания сложности операций. Большинство операторов Rx управляют уже существующими последовательностями, но для начала мы научимся их создавать.

Отличная новость завершает рабочую неделю - версия Visual Studio Code 1.0 вышла в релиз!

Мы с удовольствием делимся этим событием с разработчиками и вспоминаем, что с момента первого публичного выпуска превью Visual Studio Code прошел почти год, и за это время инструмент был установлен и протестирован 2 миллионами разработчиков.

Начинавшийся в качестве эксперимента, редактор кода превратился за это время в новый кросс-платформенный инструмент разработки, отлично дополнивший всю историю платформы для создания программного обеспечения средствами Visual Studio. Сейчас Visual Studio Code предоставляет расширенные возможности редактирования, навигации, отладки и встроенной поддержки Git. Скачать и установить Visual Studio Code 1.0 можно для операционных систем Windows, Linux и OS X.

Выпуск Visual Studio Code 1.0 — это не просто набор новых возможностей редактора, дополнивших предыдущие бета-версии, это результат плотной работы команды с сообществом, совместная работа над ошибками, улучшением производительности и т.д. Ведь изначально, VS Code создавался, как инструмент для разработчиков веб-приложений, ориентированных на JavaScript и TypeSript.

Я написал маленькую электронную книгу в которой рассматриваю вопросы как сделать код лучше. Книга ориентирована на Си/Си++ программистов, но будет интересна и разработчикам, использующих другие языки. Формат книги не подходит для моего любимого Хабра, но мне интересно получить обратную связь и обсудить мысли, изложенные в статье. Поэтому я решил разместить здесь только анонс, а с самой статьей можно познакомиться здесь. И приглашаю в комментарии для обсуждения.

Статья написана по мотивам одного не очень приятного разговора на последнем IT global митапе в Питере.

Результат и выводы для тех кто не любит длинный текст

	100.000 вызовов, 20 итераций теста, x86	100.000 вызовов, 20 итераций теста, x64	1.000.000 вызовов, 10 итераций теста, x86	1.000.000 вызовов, 10 итераций теста, x64
Прямой вызов	Min: 1 ms Max: 1 ms Mean: 1 ms Median: 1 ms Abs: 1	Min: 1 ms Max: 1 ms Mean: 1 ms Median: 1 ms Abs: 1	Min: 7 ms Max: 8 ms Mean: 7,5 ms Median: 7,5 ms Abs: 1	Min: 5 ms Max: 6 ms Mean: 5,2 ms Median: 5 ms Abs: 1
Вызов через отражение	Min: 32 ms Max: 36 ms Mean: 32,75 ms Median: 32,5 ms Rel: 32	Min: 35 ms Max: 44 ms Mean: 36,5 ms Median: 36 ms Rel: 36	Min: 333 ms Max: 399 ms Mean: 345,5 ms Median: 338 ms Rel: 45	Min: 362 ms Max: 385 ms Mean: 373,6 ms Median: 376 ms Rel: 75
Вызов через делегат	Min: 64 ms Max: 71 ms Mean: 65,05 ms Median: 64,5 ms Rel: 64	Min: 72 ms Max: 86 ms Mean: 75,95 ms Median: 75 ms Rel: 75	Min: 659 ms Max: 730 ms Mean: 688,8 ms Median: 689,5 ms Rel: 92	Min: 746 ms Max: 869 ms Mean: 773,4 ms Median: 765 ms Rel: 153
Вызов через делегат с оптимизациями	Min: 16 ms Max: 18 ms Mean: 16,2 ms Median: 16 ms Rel: 16	Min: 21 ms Max: 25 ms Mean: 22,15 ms Median: 22 ms Rel: 22	Min: 168 ms Max: 187 ms Mean: 172,8 ms Median: 170,5 ms Rel: 22.7	Min: 218 ms Max: 245 ms Mean: 228,8 ms Median: 227 ms Rel: 45.4
Вызов через dynamic	Min: 11 ms Max: 14 ms Mean: 11,5 ms Median: 11 ms Rel: 11	Min: 12 ms Max: 14 ms Mean: 12,5 ms Median: 12 ms Rel: 12	Min: 124 ms Max: 147 ms Mean: 132,1 ms Median: 130 ms Rel: 17	Min: 127 ms Max: 144 ms Mean: 131,5 ms Median: 129,5 ms Rel: 26
Вызов через Expression	Min: 4 ms Max: 4 ms Mean: 4 ms Median: 4 ms Rel: 4	Min: 4 ms Max: 5 ms Mean: 4,15 ms Median: 4 ms Rel: 4	Min: 46 ms Max: 55 ms Mean: 50 ms Median: 50,5 ms Rel: 6.7	Min: 47 ms Max: 51 ms Mean: 47,7 ms Median: 47 ms Rel: 9.4

При использованиии .NET Framework 3.5 лучше всего использовать вызов методов через делегат с оптимизацией вызова. Для .NET Framework 4.0+ отличным выбором будет использование dynamic.
UPD: новый вывод от mayorovp: лучше всего использовать Expression

UPD: и как подсказал CdEmON, такое исследование было опубликовано на хабре ранее

Привет, %username%!

Ранее мы уже затрагивали тему замедления хэширования. Это было еще до введения моды на быстрые хэшедробилки aka майнеры. Как оказалось, тема намного серьезней, чем «прокрутить хэш 100500 раз и подмешивать к нему всякий мусор», потому что GPU и спец девайсы драматически ускоряют перебор, с которым сложно бороться даже с помощью таких вещей как bcrypt.
И вот, люди запилили соревнование, результатом которого должен был стать алгоритм, который сложно ускорить на спец чипах и GPU, при этом он должен быть настраиваемым в зависимости от пожеланий разработчика. Таким алгоритмом стал Argon2.

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

Отсутствуют материализованные дженерики (reified generics). Об этом не писал только ленивый, причём большинство комментариев свидетельствуют о непонимании сути затирания типов. Если Java-разработчик говорит: «Я не люблю затирание типов», то в большинстве случаев это означает «Мне нужен List int». Вопрос примитивной специализации дженериков лишь косвенно связан с затиранием, а польза от дженериков, видимых в ходе исполнения, сильно преувеличена молвой.

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

Длинные указатели для массивов. Опять же, внедрение этой функциональности потребует слишком глубокой переработки JVM с возможными неприятными последствиями, причём далеко не только с точки зрения поведения и семантики сборщиков мусора. Хотя нужно отметить, что Oracle ищет пути внедрения подобной функциональности с помощью проекта VarHandles.

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

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