17 граней Вавилона

Сможем ли мы писать программы на естественном языке и насколько это будет удобно? Как предупредить «раздувание памяти» и не вызвать состояние гонки? Про эти и другие темы рассказываем в нашем июньском дайджесте.

Достигая естественности

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

А что если заставить интерпретатор Ruby воспринимать программы на естественном языке? Насколько удобным будет такое программирование? Ответы на эти вопросы можно найти в статье. Там пошагово расписаны все подводные камни, которые можно встретить, обучая интерпретатор естественному языку.

Вкратце — основные проблемы возникают с реализацией методов и обработкой ошибок из-за особенностей синтаксиса. Превратить фразу «how long will it take to get from london to glasgow» в код не так сложно, как может показаться. Станет ли это когда-нибудь мейнстримом? Не исключено. А пока можете попробовать это проделать самостоятельно.

Сплошное надувательство

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

Вооружаемся киркой и добываем драгоценный камень IoMonitor. Он позволяет предупреждать о раздувании памяти, контролируя ActiveRecord, Net::HTTP и Redis. Логика настройки следующая: если соотношение размера данных ввода/вывода к размеру HTTP-ответа достигает порогового значения, следует отправить предупреждение. 

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

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

Никаких гонок

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

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

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

Вы Кафку любите?

Да, особенно Apache Kafka. Сегодня затронем тему стриминга событий в Rails. Под событием подразумевается изменение состояния. Под стримингом  — шаблон сбора данных в реальном времени от источников (например, баз данных). Чтобы передавать эти данные потребителям, нужен брокер сообщений, такой как Kafka. 

Паттерн «издатель-подписчик» даёт ряд примущств. Это независимость, отказоустойчивость, низкие задержки и обработка в реальном времени. Звучит неплохо, согласитесь. Но есть и ложка дёгтя — выбирая Kafka, сложно реализовать клиентские библиотеки на любом языке, отличном от Java. Кроме того, инструменты для стриминга событий не всегда обладают возможностями полного мониторинга.

Самым популярный gem ruby-kafka был создан компанией Zendesk. Для разработки приложений на базе Kafka существуют удобные платформы, такие как karafka. Фактически это абстракция более высокого уровня. Полностью автономный фреймворк с минимальным набором зависимостей. С его помощью интегрировать Kafka в Ruby не составит труда.

Митапы