Предисловие

Привет, %username%! Этот год принес много интересных новинок и приятных новостей. Вышел долгожданный релиз Spring 5, с реактивным ядром и встроенной поддержкой Kotlin, для которой еще появится много всего интересного. Sébastien представил новый функциональный подход конфигурации Spring на Kotlin. Зарелизился JUnit 5. Близится релиз Kotlin 1.2 c улучшенной поддержкой мульти-платформенных приложений. И в этом году произошло знаменательное событие! Теперь Kotlin перешел от сборки на Groovy Dsl в Gradle на сборку с помощью Kotlin Dsl.

Как правило, начать сразу с нового стека проще, но всегда возникают вопросы насчет того, как реализовать старые подходы. Поэтому рассмотрим как на примере приложения написанного на Java, Spring Boot 1.5 (Spring 4+) с использованием Lombok и Groovy Dsl в Gradle, поэтапно перейти на Spring boot 2 (Spring 5), JUnit 5, Kotlin, и попробовать реализовать проект в функциональном стиле на spring-webflux без spring-boot. А также как перейти с Groovy Dsl на Kotlin Dsl. В посте основное внимание будет уделяться именно переходу, поэтому будет неплохо, если уже знакомы со Spring, Spring Boot и Gradle.

Для тех, кому лень читать, можно посмотреть пример кода на github, для всех остальных — прошу под кат:

Ключевое слово mutable относится к малоизвестным уголкам языка С++. В то же время оно может быть очень полезным, или даже необходимым в случае, если вы хотите строго придерживаться const-корректности вашего кода или писать лямбда-функции, способные изменять своё состояние.

Пару дней назад Eric Smolikowski написал в своём твиттере:

«Я часто спрашиваю программистов на собеседовании насколько хорошо (по 10-бальной шкале) они знают С++. Обычно они отвечают 8 или 9. И тогда я спрашиваю что такое „mutable“. Они не знают. :)»

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

Kotlin пока еще очень новая технология и это значит, что существует множество возможностей сделать что-то лучше. Для меня этот путь был таким. Я начал писать простой слой веб-обработки на Netty и coroutine-ах. Всё было в порядке, я даже сделал что-то вроде веб-фреймворка с роутингом, веб-сокетами, DSL и полной асинхронностью. Для первого раза всё показалось лёгким в освоении. Действительно, coroutine-ы делают из лапши коллбэков линейный и читаемый код.

Сюрприз ожидал меня, когда я начал тестировать это всё. Оказывается, Kotlin и mocking сложно совместимые вещи. В первую очередь из-за final полей.

Состояние — поведенческий шаблон проектирования. Используется в тех случаях, когда во время выполнения программы объект должен менять своё поведение в зависимости от своего состояния. Классическая реализация предполагает создание базового абстрактного класса или интерфейса, содержащего все методы и по одному классу на каждое возможно состояние. Шаблон представляет собой частный случай рекомендации «заменяйте условные операторы полиморфизмом».

Казалось бы, все по книжке, но есть нюанс. Как правильно реализовать методы не релевантные для данного состояния? Например, как удалить товар из пустой корзины или оплатить пустую корзину? Обычно каждый state-класс реализует только релевантные методы, а в остальных случаях выбрасывает InvalidOperationException.

Нарушение принципа подстановки Лисков на лицо. Yaron Minsky предложил альтернативный подход: сделайте недопустимые состояния непредставимыми (make illegal states unrepresentable). Это дает возможность перенести проверку ошибок со времени исполнения на время компиляции. Однако control flow в этом случае будет организован на основе сопоставления с образцом, а не с помощью полиморфизма. К счастью, частичная поддержка pattern matching появилась в C#7.

Привет!

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

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

Результатом работы, описанием процесса, кодом на git'е готов поделиться с вами.

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

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

Часть 1
Часть 2
Часть 3

Люди иногда спрашивают, почему код, скомпиливанный в LLVM иногда генерирует сигналы SIGTRAP, когда оптимизация была включена. Покопавшись, они обнаруживают, что Clang сгенерировал инструкцию «ud2» (подразумевается код X86) — то же, что генерируется __builtin_trap(). В этой статье рассматривается несколько вопросов, касающихся неопределённого поведения кода на C и того, как LLVM его обрабатывает.


В этой статье (первой из трёх) мы попытаемся объяснить некоторые из этих вопросов, чтобы вы могли лучше понять связанные с ними компромиссы и сложности, и возможно, изучить немного больше тёмные стороны С. Мы выясним, что C не является «высокоуровневым ассемблером», как многие опытные программисты на C (особенно те, кто сфокусирован на низком уровне) предпочитают думать, и что C++ и Objective-C напрямую унаследовали множество таких проблем.

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

Почему название "Broo"?

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

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

Как-то для своих некоторых планов мне потребовалось сделать небольшую песочницу в 2D пространстве с базовыми возможностями:

1. Передвижение по игровому миру
2. Физика при движении, столкновения
3. Создание блоков
4. Удаление блоков

Графическое исполнение меня не беспокоило, поэтому я решил оформить все в серых тонах, выглядит это так:

Всем йо, хабражители.

В общем, так вышло, что я пишу на JavaScript уже довольно долго, и одной из самых главных задач всегда была организация состояния приложения.
TL; DR;
Нет ничего привычнее на свете,
Чем писать колесо на велосипеда

Что-то хочется кешировать, что-то обновлять, причем обновлять везде, а не только в локальном компоненте, не хочется перерисовывать весь компонент если поменялся весь Store (shout out to Vuex), а хочется подписываться на то, что используешь (shout out to MobX).

Мы уже 2 года плотно общаемся с HFT трейдерами и разработчиками решений для HFT торговли. И испытываем некоторую неловкость от того, что никто в этой среде открыто не рассказывает о своих технологических успехах. Так как мы делаем устройства CEPappliance на основе FPGA, применимые в том числе для HFT торговли, мы неустанно интересуемся кто и как использует FPGA в этой сфере. Складывается навязчивое впечатление, что FPGA в HFT торговле, как секс у подростков — все о них говорят, но мало кто ими занимается, да еще и успешно.

Перевод статьи Синди Шридхаран.

В этой статье автор собирается:

• Пролить свет на некоторые предполагаемые преимущества маленьких функций.
• Объяснить, почему некоторые из преимуществ вовсе не такие радужные, как рекламируется.
• Объяснить, почему маленькие функции иногда контрпродуктивны.
• Объяснить, в каких случаях маленькие функции действительно полезны.

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

Java была разработана в 1995 году компанией Sun Microsystems и изначально создавалась для интерактивного телевидения и программирования бытовых электронных устройств. Тем не менее, публичный релиз Java 1.0 выявил смену фокуса на интернет-использование, превратив его в один из самых популярных языков программирования.

Очевидно, со времен 1.0 многое изменилось и вот наконец после множества переносов 21 сентября 2017 года состоялся релиз Java 9.

Особенности предыдущей (8-й) версии благодаря своей универсальности предоставили разработчикам возможность создавать решения для самых разных секторов бизнеса, включая финтех, здравоохранение и другие индустрии. Среди ключевых нововведений Java 8 следует отметить лямбда-выражения, стримы и изменения в API.

В свою очередь Java 9 также изобилует разнообразием обновлений “под капотом” и в API. Кроме очевидного проекта Jigsaw, на который возложена обязанность по внедрению модулярности в основные компоненты Java, новая версия может похвастаться ещё тремя важными фичами:

1. Полная поддержка клиента HTTP 2.0: Вопрос в скорости, и HTTP 2.0 предоставляет более высокие результаты, колеблющиеся от 11.81% до 47.7% по сравнении с клиентом HTTP 1.1.
2. Jshell: Новый инструмент командной строки. Если разработчик хочет автономно запустить несколько строк Java, то это можно выполнить без необходимости заворачивать все в отдельный метод или проект.
3. Microbenchmark: Теперь производительность отдельных небольших частей кода можно измерить стандартизированным методом. Анализ JMH за наносекунды уникален для Java 9.

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

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

Темой поисковых подсказок в Яндексе я занялся в начале 2016 года. Цель, стоящая в то время перед командой саджеста, звучала очень амбициозно: «Сделать лучший саджест на мобильных», ни больше ни меньше!

Вспоминая о том, что было сделано с тех пор в области поисковых подсказок в Яндексе, трудно отделаться от двух ощущений. Первая: как же много всего мы сделали! Вторая: неужели всего этого не было раньше? Сделано действительно много, но эти вещи кажутся часто такими простыми и очевидными, что не верится, что их не было всегда.

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

Начну с того, что всем известно. ICO повсюду, все предлагают разные проекты, все продают токены. И у всех есть какая-то модель продаж со скидками, бонусами, сроками и т.п.
Как ни странно хоть область и достаточно экспериментальная, модель бонусов достаточно примитивна. Просто есть разные объемы или временные интервалы и проценты в них. Да и зачем усложнять? А я все таки попробую. Эксперимента ради. Новое всегда привлекает.

Метод (алгоритм) Виолы и Джонса [1] является одним из способов выявления границ объектов на изображении. Хотя алгоритм, разработанный П. Виолой и М. Джонсом еще в 2001 году, был первоначально ориентирован на быстрый поиск лиц на изображениях, сейчас разнообразные вариации этого популярного алгоритма с успехом используются в различных задачах поиска границ:

• образов пешеходов [2],
• образов автомобилей [3],
• образов дорожных знаков [4],

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

В последнее время все чаще в новостях можно услышать слова "криптовалюта" и "блокчейн" и, как следствие, наблюдается приток большого количества заинтересованных этими технологиями людей, а вместе с этим и огромное количество новых продуктов. Зачастую, для реализации какой-то внутренней логики проекта или же для сбора средств используются "умные контракты" — особые программы, созданные на платформе Ethereum и живущие внутри его блокчейна. В сети уже существует достаточно материала, посвященного созданию простых смарт-контрактов и базовым принципам, однако практически нету описания работы виртуальной машины Ethereum (далее EVM) на более низком уровне, поэтому в этой серии статей я бы хотел разобрать работу EVM более детально.

Solidity — язык, созданный для разработки умных контрактов, существует относительно недавно — его разработка началась только в 2014 году и, как следствие, местами он ''сыроват''. В этой статье я начну с более общего описания работы EVM и некоторых отличительных особенностей solidity, которые нужны для понимая более низко-уровневой работы.

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

• Hello world на solidity и деплой контракта в сеть
• Подборка инструментов для разработки
• Описание работы Ethereum и его блокчейна

Зачем этот рассказ? Когда я изучал blockchain по открытым источникам, например по Википедии, информация казалась отрывочной и бессвязной. Прошло время, прежде чем она сложилась в целостную картину. Кажется, я знаю, в каком порядке и какими словами описать введение в blockchain, чтобы любой профессиональный разработчик смог понять общую картину за 1—1,5 часа. В тексте будут некоторые упрощения. Понятно, что в любой теме есть много деталей, куда можно при желании погрузиться.

В этой статье рассматривается проектирование типов для работы с объектами линейной алгебры: векторами, матрицами, кватернионами. Показано классическое применение механизма перегрузки стандартных операций, использование приёма «Copy On Write» и аннотаций.

Термин "модуль" (module) взят из статьи Modules vs. microservices. Так же для описания чего-то среднего между микросервисами и монолитами иногда используют термины "микролит" (microlith) или "моносервис" (monoservice). Но, не смотря на то, что термин "модуль" и так уже нагружен общеизвестным смыслом, на мой взгляд он подходит лучше других вариантов. Update: В комментарии lega использовал термин "встроенный микросервис" — он лучше описывает суть подхода, чем "модуль".

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

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