Старые подходы к построению программных систем не так актуальны для создания современных решений. В дополнение к масштабируемости добавляются требования отзывчивости, отказоустойчивости и событийности. Пытаться работать на родном старом или посмотреть в сторону новых технологий? В своем выступлении я расскажу про концепцию reactive programming. Какие технологии реализуют концепцию и как сделать первые шаги в этом новом прекрасном мире.
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
Доклад читался на http://university.jokerconf.com/. Целевая аудитория -- начинающие программисты.
У enterprise-приложений много общих подводных камней, которые подстерегают на пути к выводу систему в эксплуатацию.
Что делать, если через неделю после выхода в production система начала тормозить? Что делать, если проблема воспроизводится только у заказчика?
В докладе рассмотрим частые случаи, приводящие к полной или частичной недоступности production-системы. Научимся обходить стороной грабли и поднимать их до того, как на них кто-то наступит.
There is a problem of finding the best instance of a service in distributed systems with dynamic configuration. Nowadays, there are many products for the configuration storage and service discovery. It should be mentioned at least Netflix Eureka, Consul, etc or good old Zookeeper. These products can keep and give configuration, manage service instances lifecycle and some of them even can be as dynamic DNS service. But main question is not about what instance may be called at the certain time. It is about what instance is better for call? This means that smart load balancing top on service discovery is required. Spring Cloud project allows to integrate these products to your project and provides powerful solutions for typical problems, that make cloud native services developing easier. This talk will review the internal structure of SpringCloud implementation of Client-Side Service Discovery and Client Load Balancing patterns. It also will include specific details of concrete implementations with examples from official libraries and the author’s own library.
Общедоступные программы и библиотеки подкупают своей бесплатностью. Если же исходный код открыт, то все сразу думают, что «умные дядьки уже исправили всё, что нужно». На практике же оказывается, что грабли разложены там, где их мало кто ждёт. Тормозит всё, кроме, разве что, самой java. В докладе мы рассмотрим примеры проблем производительности при использовании таких библиотек как Wildfly, Spring, HornetQ, pgjdbc.
Например, оказывается, что spring.getBean тормозит, а в комбинации с autoproxy вообще может занимать до 50% времени приложения. Cglib мешает работе garbage collector’а в попытках проксировать Object#finalize, а HornetQ внезапно притормаживает отправку JMS, что запросто приводит к 5-и секундным задержкам на одно сообщение. Узнаем как их опознать и обезвредить.
http://javapoint.ru/talks/sitnikov/
В этом докладе рассмотрен опыт NetCracker по выбору инструмента для изучения причин проблем производительности.
Рассмотрены критерии по которым не подошли имеющиеся инструменты и показаны примеры того, чего не хватает при анализе результатов обычными профайлерами.
http://jeeconf.com/program/implement-your-own-profiler-with-blackjack-and-fun/
A step-by-step approach toward high quality OutOfMemoryError analysisVladimir Sitnikov
Все говорят, что при проблемах с памятью нужно открыть Eclipse MemoryAnalyzer и немного покрутить. Да, часто это срабатывает, но бывает, что даже опытного инженера задача ставит в тупик.
В докладе мы рассмотрим примеры коварных OOM, и научимся анализировать причины их возникновения. На живых мертвецах дампах памяти увидим почему может не очищаться WeakHashMap, куда утекает native память, сколько finalizer'ов поместится на кончике иглы.
Полученные знания позволят вам уверенно разбирать дампы памяти и избегать шаблонов кода, приводящих к утечкам.
http://jeeconf.com/program/a-step-by-step-approach-toward-high-quality-outofmemoryerror-analysis/
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
Доклад читался на http://university.jokerconf.com/. Целевая аудитория -- начинающие программисты.
У enterprise-приложений много общих подводных камней, которые подстерегают на пути к выводу систему в эксплуатацию.
Что делать, если через неделю после выхода в production система начала тормозить? Что делать, если проблема воспроизводится только у заказчика?
В докладе рассмотрим частые случаи, приводящие к полной или частичной недоступности production-системы. Научимся обходить стороной грабли и поднимать их до того, как на них кто-то наступит.
There is a problem of finding the best instance of a service in distributed systems with dynamic configuration. Nowadays, there are many products for the configuration storage and service discovery. It should be mentioned at least Netflix Eureka, Consul, etc or good old Zookeeper. These products can keep and give configuration, manage service instances lifecycle and some of them even can be as dynamic DNS service. But main question is not about what instance may be called at the certain time. It is about what instance is better for call? This means that smart load balancing top on service discovery is required. Spring Cloud project allows to integrate these products to your project and provides powerful solutions for typical problems, that make cloud native services developing easier. This talk will review the internal structure of SpringCloud implementation of Client-Side Service Discovery and Client Load Balancing patterns. It also will include specific details of concrete implementations with examples from official libraries and the author’s own library.
Общедоступные программы и библиотеки подкупают своей бесплатностью. Если же исходный код открыт, то все сразу думают, что «умные дядьки уже исправили всё, что нужно». На практике же оказывается, что грабли разложены там, где их мало кто ждёт. Тормозит всё, кроме, разве что, самой java. В докладе мы рассмотрим примеры проблем производительности при использовании таких библиотек как Wildfly, Spring, HornetQ, pgjdbc.
Например, оказывается, что spring.getBean тормозит, а в комбинации с autoproxy вообще может занимать до 50% времени приложения. Cglib мешает работе garbage collector’а в попытках проксировать Object#finalize, а HornetQ внезапно притормаживает отправку JMS, что запросто приводит к 5-и секундным задержкам на одно сообщение. Узнаем как их опознать и обезвредить.
http://javapoint.ru/talks/sitnikov/
В этом докладе рассмотрен опыт NetCracker по выбору инструмента для изучения причин проблем производительности.
Рассмотрены критерии по которым не подошли имеющиеся инструменты и показаны примеры того, чего не хватает при анализе результатов обычными профайлерами.
http://jeeconf.com/program/implement-your-own-profiler-with-blackjack-and-fun/
A step-by-step approach toward high quality OutOfMemoryError analysisVladimir Sitnikov
Все говорят, что при проблемах с памятью нужно открыть Eclipse MemoryAnalyzer и немного покрутить. Да, часто это срабатывает, но бывает, что даже опытного инженера задача ставит в тупик.
В докладе мы рассмотрим примеры коварных OOM, и научимся анализировать причины их возникновения. На живых мертвецах дампах памяти увидим почему может не очищаться WeakHashMap, куда утекает native память, сколько finalizer'ов поместится на кончике иглы.
Полученные знания позволят вам уверенно разбирать дампы памяти и избегать шаблонов кода, приводящих к утечкам.
http://jeeconf.com/program/a-step-by-step-approach-toward-high-quality-outofmemoryerror-analysis/
Запустить нагрузочный тест — дело нехитрое. Но запуск без анализа — время на ветер. При анализе выявляется такое, от чего приходится повторять замер. Например: времена отклика получились хорошее, а при детальном анализе оказалось, что все страницы показывали 404-ую ошибку. В начале теста времена хорошие, а потом вообще никакие. Или даже так: JMeter показывает, что «всё замечательно», а в реальности нагрузка не подавалась полчаса. Бывает, что в целом всё хорошо, но есть неприятные выбросы. Как анализировать причины выбросов? Как узнать, на каких данных они возникают? И на этот вопрос будет рекомендация.
В докладе будут рассмотрены типичные подводные камни при тестировании enterprise приложений и варианты решения этих проблем. Доклад построен на примере JMeter, но многие подходы могут с тем же успехом применяться и к другим инструментам. Владимир расскажет, чем среднее отличается от 90% line, как coordinated omission мешает измерять времена отклика, и научит способам обхода типичных проблем, возникающих при замере производительности.
Все говорят, что для максимальной производительности работы из Java с базой данных нужно использовать PreparedStatements и Batch DML. Практика показывает, что нельзя слепо идти на поводу у прописных истин. Нужно понимать особенности конкретной базы и характера передаваемых данных.
В докладе мы рассмотрим то, как эффективное использование протокола PostgreSQL позволяет добиться высокой производительности при выборке и сохранении данных. На примерах увидим как простые изменения в коде приложения и JDBC драйвера на порядок ускоряют запросы. Мы увидим как задействовать механизм server prepared statements из клиенсткого кода и узнаем его узкие места. Обсудим средства эффективной передачи данных в базу.
Многие обсуждаемые доработки недавно вошли в состав официального JDBC драйвера. Доклад будет полезен не только Java программистам, т.к. многие подводные грабли вытекают из самого протокола общения PostgreSQL с внешним миром.
Zabbix 3.4 - простая непростая дружба с сообществом / Алексей Владышев (Zabbix)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 14:00
Тезисы:
http://rootconf.ru/2017/abstracts/2708.html
Сообщество любого открытого проекта созидательно по сути, не использовать эту силу будет большой ошибкой. Но всегда ли нужно слепо следовать за мнением большинства?
В своём докладе я расскажу о новой функциональности, ожидаемой в версии Zabbix 3.4, какие запросы наших пользователей мы решили реализовать, и какую роль в формировании роадмапа играет сообщество. Затрону тему общих принципов формирования роадмапа, и почему мы не готовы работать над всеми хотелками сообщества. Некоторые из них приходится ждать годами, а некоторые мы реализуем буквально за день.
Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?
Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Пара простых советов как ускорить регулярные выражения и предотвратить stackoverflowerror.
Да, хоть и нужны они нечасто, но почему-то мало кто знает про *+ и ?>.
Рассмотрен и вопрос xpath vs regexp. Регулярные выражения побеждают стандартный XML движок.
Все говорят, что при проблемах с памятью нужно открыть Eclipse MemoryAnalyzer и немного покрутить. Да, часто это срабатывает, но бывает, что даже опытного инженера задача ставит в тупик.
В докладе мы рассмотрим примеры коварных OOM, и научимся анализировать причины их возникновения. На живых мертвецах дампах памяти увидим почему может не очищаться WeakHashMap, куда утекает native память, сколько finalizer'ов поместится на кончике иглы.
Полученные знания позволят вам уверенно разбирать дампы памяти и избегать шаблонов кода, приводящих к утечкам.
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
В этом докладе рассмотрен опыт NetCracker по выбору инструмента для изучения причин проблем производительности.
Рассмотрены критерии по которым не подошли имеющиеся инструменты и показаны примеры того, чего не хватает при анализе результатов обычными профайлерами.
http://jokerconf.com/#sitnikov
How to build solid CI-CD pipeline / Илья Беда (beda.software)Ontico
РИТ++ 2017, Root Conf
Зал Конгресс-холл, 6 июня, 15:00
Тезисы:
http://rootconf.ru/2017/abstracts/2551.html
На основе своего опыта работы в консалтинге я расскажу, как избавить разработчиков от рутинных задач и как сэкономить на ресурсах команды с помощью правильно настроенного CI-CD pipeline.
Единствено верный способ упаковки приложений - это Docker-контейнеры, благодаря этому способу вы сможете унифицировать процесс деплоя. Нужно деплоить приложения с помощью Ansible-плейбука, запакованного в Docker-контейнер, это снижает требования к окружению CI-ранера. Вам нужен только Docker.
...
"Fault tolerant workflow orchestration on PHP", Anton TsitouFwdays
Workflow orchestration systems.
About Temporal.IO (Cadence, AWS SWF).
Integrating Temporal to RoadRunner and PHP.
Overview of PHP SDK for durable workflow orchestration.
Архитектура поиска в Booking.com / Иван Круглов (Booking.com)Ontico
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Zabbix и миллионы метрик: наилучший опыт масштабного мониторинга / Алексей Вл...Ontico
Управление миллионами метрик таит в себе множество сложностей. Это вопросы автоматизации, масштабируемости, интеграции с другими системами и многое другое. Хочется максимально всё автоматизировать — один раз настроил и забыл. Возможно ли это?
Я подробно расскажу о накопленном практическом опыте использования Zabbix в самых жестоких условиях различных сценариев, расскажу на реальных примерах о том, как справиться с мониторингом тысяч удалённых точек, как не заблудиться в десятках миллионов триггеров и осилить динамические среды. Тут и о производительности нужно серьёзно задуматься.
Zabbix обладает целым набором функциональности, которая позволяет упростить жизнь отдела мониторинга. Конечно, подробности можно найти в документации, только не всегда понятно, как это правильно использовать.
Цель доклада — поделиться практическим опытом, это бесценно!
Быстрое прототипирование бэкенда игры с геолокацией на OpenResty, Redis и Doc...Ontico
Докладчик разберёт кейс быстрой разработки небольшого прототипа серверной части мобильной игры с геолокацией на стеке nginx, OpenResty (Lua), Redis и Docker. Вы услышите о том, почему был выбран такой стек, о его преимуществах (и некоторых недостатках), о том, как прототип устроен внутри, о том, как именно особенности стека были использованы для того, чтобы реализовать задуманное. Не будет обойден стороной вопрос о том, как максимально быстро собрать прототип и быстро итерироваться по нему, но при этом удержаться в золотой середине между Сциллой макаронной копипасты и Харибдой кристаллического перфекционизма. Немного времени будет уделено и рассказу о том, как можно превратить такой прототип в продакшен-систему.
Функциональное программирование в браузере / Никита ПрокоповOntico
Писать веб-приложение — то еще занятие: медленно, сложно. Особенно трудно, если вы взялись за большой интерфейс.
В докладе мы ответим на следующие вопросы:
— Что такое функциональное программирование?
— Как функциональный подход помогает делать веб-приложения?
— Что в ФП хорошо ложится на специфику интерфейсостроения?
— Как может выглядеть архитектура современного фронтенд приложения, использующего ФП?
— Какие есть истории успеха и живые примеры?
На примерах из ClojureScript, JavaScript, Elm и React.js.
Запустить нагрузочный тест — дело нехитрое. Но запуск без анализа — время на ветер. При анализе выявляется такое, от чего приходится повторять замер. Например: времена отклика получились хорошее, а при детальном анализе оказалось, что все страницы показывали 404-ую ошибку. В начале теста времена хорошие, а потом вообще никакие. Или даже так: JMeter показывает, что «всё замечательно», а в реальности нагрузка не подавалась полчаса. Бывает, что в целом всё хорошо, но есть неприятные выбросы. Как анализировать причины выбросов? Как узнать, на каких данных они возникают? И на этот вопрос будет рекомендация.
В докладе будут рассмотрены типичные подводные камни при тестировании enterprise приложений и варианты решения этих проблем. Доклад построен на примере JMeter, но многие подходы могут с тем же успехом применяться и к другим инструментам. Владимир расскажет, чем среднее отличается от 90% line, как coordinated omission мешает измерять времена отклика, и научит способам обхода типичных проблем, возникающих при замере производительности.
Все говорят, что для максимальной производительности работы из Java с базой данных нужно использовать PreparedStatements и Batch DML. Практика показывает, что нельзя слепо идти на поводу у прописных истин. Нужно понимать особенности конкретной базы и характера передаваемых данных.
В докладе мы рассмотрим то, как эффективное использование протокола PostgreSQL позволяет добиться высокой производительности при выборке и сохранении данных. На примерах увидим как простые изменения в коде приложения и JDBC драйвера на порядок ускоряют запросы. Мы увидим как задействовать механизм server prepared statements из клиенсткого кода и узнаем его узкие места. Обсудим средства эффективной передачи данных в базу.
Многие обсуждаемые доработки недавно вошли в состав официального JDBC драйвера. Доклад будет полезен не только Java программистам, т.к. многие подводные грабли вытекают из самого протокола общения PostgreSQL с внешним миром.
Zabbix 3.4 - простая непростая дружба с сообществом / Алексей Владышев (Zabbix)Ontico
РИТ++ 2017, Root Conf
Зал Пекин + Шанхай, 5 июня, 14:00
Тезисы:
http://rootconf.ru/2017/abstracts/2708.html
Сообщество любого открытого проекта созидательно по сути, не использовать эту силу будет большой ошибкой. Но всегда ли нужно слепо следовать за мнением большинства?
В своём докладе я расскажу о новой функциональности, ожидаемой в версии Zabbix 3.4, какие запросы наших пользователей мы решили реализовать, и какую роль в формировании роадмапа играет сообщество. Затрону тему общих принципов формирования роадмапа, и почему мы не готовы работать над всеми хотелками сообщества. Некоторые из них приходится ждать годами, а некоторые мы реализуем буквально за день.
Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?
Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.
Как devops исчерпывает себя, и что будет дальше / Кирилл Вечера (Jetware)Ontico
* Следующее поколение моделей проектирования и эксплуатации серверных приложений в публичных облаках и на классических серверах.
* Сравнение методов эксплуатации: "традиционных" Chef/Salt/Ansible, immutage images/virtual appliances/Docker, и автономных рабочих окружений Jetware/Snappy/Nix/Habitat.
* Самоконфигурация, самоадминистрирование и самовосстановление серверов.
** Управление большими системами Mesos, Kubernetes, Docker Swarm.
** Управление внутри микросервисов.
* Независимость рабочего окружения приложений от операционной системы и ядра, just enough OS.
* Приложение - это не только исходный код, но и операционное окружение. Разработка, тестирование и версионирование всего полностью.
* Сервер как программа - компонентный подход.
Пара простых советов как ускорить регулярные выражения и предотвратить stackoverflowerror.
Да, хоть и нужны они нечасто, но почему-то мало кто знает про *+ и ?>.
Рассмотрен и вопрос xpath vs regexp. Регулярные выражения побеждают стандартный XML движок.
Все говорят, что при проблемах с памятью нужно открыть Eclipse MemoryAnalyzer и немного покрутить. Да, часто это срабатывает, но бывает, что даже опытного инженера задача ставит в тупик.
В докладе мы рассмотрим примеры коварных OOM, и научимся анализировать причины их возникновения. На живых мертвецах дампах памяти увидим почему может не очищаться WeakHashMap, куда утекает native память, сколько finalizer'ов поместится на кончике иглы.
Полученные знания позволят вам уверенно разбирать дампы памяти и избегать шаблонов кода, приводящих к утечкам.
Случалось ли, что вы видели (чужой) код и хотели все переписать? Бывало такое, что вы не могли понять, почему кем-то было принято конкретное решение, не другое? Хотели ли вы воскликнуть:«А я бы сделал еще круче!»?
Если вы задумывались об этом, вам будет интересно послушать историю о том, как эти вопросы возникали у Александра и Кирилла и как они решались в условиях большой компании.
Разработчики расскажут, как в самом начале пути вытаскивали шашки и шли в атаку на проблемную архитектуру. Но все оказалось не так просто, и по мере погружения в проект парни стали понимать, что архитектура большой системы — компромисс между различными подходами и решениями, инновациями и легаси (наследованным кодом), централизацией и децентрализацией компонентов. Докладчики наработали очень много опыта в решении архитектурных задач и поделятся опытом и выработанными принципами, которых придерживаются в настоящее время.
Во время доклада будут обсуждаться непростые вопросы, возникающие при принятии решений о том, как будет жить и эволюционировать система.
Вместе со слушателями Александр и Кирилл проделают упражнение по созданию «таблицы технологий» и её эволюции. Также они покажут, насколько важно инженерное решение на любой из стадий развития системы.
One-cloud — система управления дата-центром в Одноклассниках / Олег Анастасье...Ontico
HighLoad++ 2017
Зал «Калининград», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2964.html
Одноклассники состоят из более чем восьми тысяч железных серверов, расположенных в нескольких дата-центрах. Каждая из этих машин была специализированной под конкретную задачу - как для обеспечения изоляции отказов, так и для обеспечения автоматизированного управления инфраструктурой.
...
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
smart balancing with nginx+lua / Андрей Кононов (IPONWEB)Ontico
В этом докладе я планирую осветить следующие проблемы:
- Почему стандартных механизмов балансировки бывает недостаточно.
- Как выбирать фундамент для решения, и какие принципы проектирования использовались.
- Как формировались требования для решения, которое работает сейчас в продакшне и пропускает через себя ощутимое количество.
Расскажу, как без помощи сторонних сессионных хранилищ и довольно за дёшево организовать "sticky balancing", и как это работает с точки зрения науки. Покажу пример отказоустойчивой геораспределённой системы, расскажу, что мониторить и как правильно это делать при помощи специального расширения для nginx и не только. Расскажу о том, как было организовано нагрузочное и функциональное тестирование конечного продукта. Также расскажу про полный жизненный цикл этого весьма критичного для инфраструктуры приложения.
Поскольку мы живём в публичных облаках, я по ходу доклада расскажу, как мы тестировали и сравнивали AWS и GCP, а также про некоторые сугубо практические особенности организации in-house балансировки внутри публичного облака.
Как сделать ваш JavaScript быстрее / Роман Дворнов (Авито)Ontico
JavaScript, который мы пишем, не всегда исполняется, как мы думаем. Виртуальные машины, исполняющие его, делают многое, чтобы он работал быстрее. Но они не всесильны, и чтобы сделать код действительно быстрым, нужно знать их особенности и как все работает под капотом.
Поговорим об этих особенностях, что может служить причиной потери производительности, как это диагностировать и как делать код действительно быстрым. Доклад базируется на опыте, полученном в ходе работы над такими проектами как basis.js (весьма быстрый фреймворк для SPA), CSSO (минификатор CSS, который из медленного стал один из самых быстрых), CSSTree (самый быстрый детальный CSS парсер) и других.
Опыт разработки модуля межсетевого экранирования для MySQL / Олег Брославский...Ontico
HighLoad++ 2017
Зал «Кейптаун», 8 ноября, 15:00
Тезисы:
http://www.highload.ru/2017/abstracts/2957.html
Расскажем о нашем опыте разработки модуля межсетевого экрана для MySQL с использованием генератора парсеров ANTLR и языка Kotlin.
Подробно рассмотрим следующие вопросы:
— когда и почему целесообразно использовать ANTLR;
— особенности разработки ANTLR-грамматики для MySQL;
— сравнение производительности рантаймов для ANTLR в рамках задачи синтаксического анализа MySQL (C#, Java, Kotlin, Go, Python, PyPy, C++);
— вспомогательные DSL;
— микросервисная архитектура модуля экранирования SQL;
— полученные результаты.
В этом докладе рассмотрен опыт NetCracker по выбору инструмента для изучения причин проблем производительности.
Рассмотрены критерии по которым не подошли имеющиеся инструменты и показаны примеры того, чего не хватает при анализе результатов обычными профайлерами.
http://jokerconf.com/#sitnikov
How to build solid CI-CD pipeline / Илья Беда (beda.software)Ontico
РИТ++ 2017, Root Conf
Зал Конгресс-холл, 6 июня, 15:00
Тезисы:
http://rootconf.ru/2017/abstracts/2551.html
На основе своего опыта работы в консалтинге я расскажу, как избавить разработчиков от рутинных задач и как сэкономить на ресурсах команды с помощью правильно настроенного CI-CD pipeline.
Единствено верный способ упаковки приложений - это Docker-контейнеры, благодаря этому способу вы сможете унифицировать процесс деплоя. Нужно деплоить приложения с помощью Ansible-плейбука, запакованного в Docker-контейнер, это снижает требования к окружению CI-ранера. Вам нужен только Docker.
...
"Fault tolerant workflow orchestration on PHP", Anton TsitouFwdays
Workflow orchestration systems.
About Temporal.IO (Cadence, AWS SWF).
Integrating Temporal to RoadRunner and PHP.
Overview of PHP SDK for durable workflow orchestration.
Архитектура поиска в Booking.com / Иван Круглов (Booking.com)Ontico
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Zabbix и миллионы метрик: наилучший опыт масштабного мониторинга / Алексей Вл...Ontico
Управление миллионами метрик таит в себе множество сложностей. Это вопросы автоматизации, масштабируемости, интеграции с другими системами и многое другое. Хочется максимально всё автоматизировать — один раз настроил и забыл. Возможно ли это?
Я подробно расскажу о накопленном практическом опыте использования Zabbix в самых жестоких условиях различных сценариев, расскажу на реальных примерах о том, как справиться с мониторингом тысяч удалённых точек, как не заблудиться в десятках миллионов триггеров и осилить динамические среды. Тут и о производительности нужно серьёзно задуматься.
Zabbix обладает целым набором функциональности, которая позволяет упростить жизнь отдела мониторинга. Конечно, подробности можно найти в документации, только не всегда понятно, как это правильно использовать.
Цель доклада — поделиться практическим опытом, это бесценно!
Быстрое прототипирование бэкенда игры с геолокацией на OpenResty, Redis и Doc...Ontico
Докладчик разберёт кейс быстрой разработки небольшого прототипа серверной части мобильной игры с геолокацией на стеке nginx, OpenResty (Lua), Redis и Docker. Вы услышите о том, почему был выбран такой стек, о его преимуществах (и некоторых недостатках), о том, как прототип устроен внутри, о том, как именно особенности стека были использованы для того, чтобы реализовать задуманное. Не будет обойден стороной вопрос о том, как максимально быстро собрать прототип и быстро итерироваться по нему, но при этом удержаться в золотой середине между Сциллой макаронной копипасты и Харибдой кристаллического перфекционизма. Немного времени будет уделено и рассказу о том, как можно превратить такой прототип в продакшен-систему.
Функциональное программирование в браузере / Никита ПрокоповOntico
Писать веб-приложение — то еще занятие: медленно, сложно. Особенно трудно, если вы взялись за большой интерфейс.
В докладе мы ответим на следующие вопросы:
— Что такое функциональное программирование?
— Как функциональный подход помогает делать веб-приложения?
— Что в ФП хорошо ложится на специфику интерфейсостроения?
— Как может выглядеть архитектура современного фронтенд приложения, использующего ФП?
— Какие есть истории успеха и живые примеры?
На примерах из ClojureScript, JavaScript, Elm и React.js.
Назад в будущее! …и другие мысли о подготовке программистов в ВУЗахDennis Schetinin
Как бы вы охарактеризовали сегодняшнюю ситуацию в сфере разработки программного обеспечения?
Автор считает, что ее без особой натяжки можно назвать стагнацией, и предлагает поразмышлять над одной из возможных причин: подготовкой программистов в ВУЗах…
JavaScript завтра / Сергей Рубанов (Exante Limited)Ontico
За последние несколько лет в мире js-разработки особое внимание получили такие проекты как AtScript, TypeScript, SoundScript, Flow, Traceur, Babel, каждый из которых пытается предоставить разработчикам некую "улучшенную" версию JavaScript. Комитет TC39 также стал очень активен и разработал стратегию развития стандарта ECMAScript с более частыми релизами. Движки JavaScript стремительно приближаются к полной поддержке ES6. Огромное количество JS-фреймворков и библиотек выбирают следующую версию стандарта уже сегодня. Это означает, что необходимо уже сегодня обратить внимание на происходящее в мире JavaScript-разработки и разобраться, что ждет язык завтра.
В своем докладе я постараюсь дать ответы на следующие вопросы:
- почему такие фреймворки и библиотеки как Angular, Ember, React начали активно и кардинально меняться;
- почему новая версия стандарта языка ES6 так долго внедряется вендорами браузеров и как TC39 решил ускорить процесс стандартизации и внедрения последующих версий ECMAScript;
- почему CoffeeScript больше не "just JavaScript", и действительно ли он сделал такой значимый вклад в следующую версию JavaScript;
- почему были созданы AtScript, TypeScript, Flow, чем каждый из них отличается от остальных, и как они влияют на дальнейшее развитие JavaScript;
- что такое Strong Mode и SoundScript;
- как начать писать ES6+ код уже сегодня.
Based on the core.async library Clojure allows a CSP programming style, so your system is made up of asynchronous, lightweight processes which communicate through channels.
The talk shows common pitfalls in classic OO GUI
approaches and shows how to tackle some of these problems in a fundamentally simpler way.
End to End Akka Streams / Reactive Streams - from Business to SocketKonrad Malawski
The Reactive Streams specification, along with its TCK and various implementations such as Akka Streams, is coming closer and closer with the inclusion of the RS types in JDK 9. Using an example Twitter-like streaming service implementation, this session shows why this is a game changer in terms of how you can design reactive streaming applications by connecting pipelines of back-pressured asynchronous processing stages. The presentation looks at the example from two perspectives: a raw implementation and an implementation addressing a high-level business need.
Understanding Akka Streams, Back Pressure, and Asynchronous ArchitecturesLightbend
The term 'streams' has been getting pretty overloaded recently–it's hard to know where to best use different technologies with streams in the name. In this talk by noted hAkker Konrad Malawski, we'll disambiguate what streams are and what they aren't, taking a deeper look into Akka Streams (the implementation) and Reactive Streams (the standard).
You'll be introduced to a number of real life scenarios where applying back-pressure helps to keep your systems fast and healthy at the same time. While the focus is mainly on the Akka Streams implementation, the general principles apply to any kind of asynchronous, message-driven architectures.
Exploring Reactive Integrations With Akka Streams, Alpakka And Apache KafkaLightbend
Since its stable release in 2016, Akka Streams is quickly becoming the de facto standard integration layer between various Streaming systems and products. Enterprises like PayPal, Intel, Samsung and Norwegian Cruise Lines see this is a game changer in terms of designing Reactive streaming applications by connecting pipelines of back-pressured asynchronous processing stages.
This comes from the Reactive Streams initiative in part, which has been long led by Lightbend and others, allowing multiple streaming libraries to inter-operate between each other in a performant and resilient fashion, providing back-pressure all the way. But perhaps even more so thanks to the various integration drivers that have sprung up in the community and the Akka team—including drivers for Apache Kafka, Apache Cassandra, Streaming HTTP, Websockets and much more.
In this webinar for JVM Architects, Konrad Malawski explores the what and why of Reactive integrations, with examples featuring technologies like Akka Streams, Apache Kafka, and Alpakka, a new community project for building Streaming connectors that seeks to “back-pressurize” traditional Apache Camel endpoints.
* An overview of Reactive Streams and what it will look like in JDK 9, and the Akka Streams API implementation for Java and Scala.
* Introduction to Alpakka, a modern, Reactive version of Apache Camel, and its growing community of Streams connectors (e.g. Akka Streams Kafka, MQTT, AMQP, Streaming HTTP/TCP/FileIO and more).
* How Akka Streams and Akka HTTP work with Websockets, HTTP and TCP, with examples in both in Java and Scala.
Картинки к моему рассказу о том, как мы делаем Банки.ру. Некоторые слайды очень неоднозначны без текста. Тезисы тут: http://nastachku.ru/lectures?lecture_id=630#lecture_630
Видео тут https://www.youtube.com/watch?v=m5QuiTZwMrU
Технические аспекты блокировки интернета в России. Проблемы и перспективыPhilipp Kulin
Технические детали блокировок. Как сейчас организован механизм блокировок. Кто, что, где, когда и как. Почему он так организован. Почему РКН блокирует сетями. В чем проблема текущего механизма блокировок с технической точки зрения. В каком направлении надо двигаться с технической точки зрения в рамках минимальных изменений сегодняшней нормативной правовой базы.
HighLoad++ 2018 http://www.highload.ru/moscow/2018/abstracts/4280
Performance management lessons learnt / Андрей Дмитриев (JUGRU)Ontico
В идеальном мире нагрузочное тестирование проводится своевременно, с должной поддержкой со стороны разработчиков, на подходящем железе и с нужным объемом данных.
В реальности выполнение многих задач может запаздывать, способ решения может меняться и заказчик может менять свои планы.
Как минимальными усилиями можно провести тестирование производительности, при этом не упустив важных кейсов?
Наша команда проводит нагрузочное тестирование на десятке различных аккаунтов по всему миру и за последнее время накопила большой опыт, проводя тестирование полного цикла: от сбора требований до выдачи отчета заказчику.
В этом докладе я постараюсь охватить не только подход к нагрузочному тестированию, который мы практикуем, но и подход к управлению скоростными характеристиками проекта.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
LuaJIT как основа для сервера приложений - проблемы и решения / Игорь Эрлих (...Ontico
С того момента, как было принято решение использовать язык Lua в качестве языка описания бизнес-логики в нашей платформе, прошло уже больше восьми лет. Проекты росли, данных становилось больше, возрастала нагрузка на сервера приложений. Со временем у нас накопился солидный багаж знаний о том, как устроен LuaJIT, с какими проблемами можно столкнуться при его использовании и как эти проблемы можно решать.
Я расскажу про то...
* Почему при миграции с x86 на x64 доступной памяти в LuaJIT становится меньше, и как мы с этим боролись.
* Как загрузить в LuaJIT несколько миллионов объектов и не умереть в тормозах от сборщика мусора.
* Насколько ужасна встроенная функция хеширования строк и почему иногда надо жертвовать производительностью в пользу качества.
Highload++2013: TopGun - архитектура терабитной платформы DPILeonid Yuriev
Презентация с конференции HighLoad-2013 об архитектуре новой DPI платформы Петер-Сервис.
http://www.highload.ru/2013/abstracts/1178.html
Представлен обзор архитектуры многоцелевой DPI-платформы, на основе которой могут строиться как "шпионские" приложения класса СОРМ/PRISM, так и коммерческие системы PCEF/TDF (Traffic Shaping), безопасного Интернета (интеллектуальная фильтрация содержимого), таргетирования рекламы и т. д. К особенностям рассматриваемого решения можно отнести мультитерабитное масштабирование, способ балансировки, обработку "роем" (Swarm Intelligence) и аварийного восстановления (failover) посредством репликации конечных автоматов.
Roadmap:
- offtopic: кому и зачем нужен DPI?
- offtopic: законность и морально-этические вопросы.
- на какую "луну" нужно сесть, что мы хотим сделать?
- распределение трафика за счет использования коммутаторов и MAC rewrite.
- роевой интеллект (Swarm Intellegence) для управления балансировкой и обработкой данных.
- репликация конечных автоматов (виртуальных микромашин).
- распределенное "Табло" как оперативное хранилище с элементами key-value и eventual consistency, lockfree в shared memory.
- транспортный фасад, унифицирующий DPDK, netmap, Infiniband (RDMA), 0mq и zerocopy и lockfree обмен через shared memory.
Картинки к моему рассказу о том, что такое фреймворки и с чем их едят, что лучше не есть и как выбрать приправы для приготовления. Тезисы тут: http://backendconf.ru/2016/abstracts/2123.html
Similar to Алексей Романчук «Реактивное программирование» (20)
Поговорим, как и зачем функционально тестировать хайлоад, получать от тестов больше, чем «прошёл/не прошёл», а их количество превратить в качество продукта.
Фреймворк Slot, Good Parts, Александр БирюковDevDay
Расскажу о ключевых особенностях продукта: о какой изоморфности идёт речь, как мы управляем состоянием SinglePage-приложения и какой профит для SEO извлекли, с примерами кода. Посмотрим как быстро начать свой проект на Slot.
Рендеринг может больше: vue.js vs React, Андрей СолодовниковDevDay
О том, как перестать вручную контролировать DOM, писать логику навигаций и почему DOM-шаблонизация — это классно, а так же немного самокритики и сравнительных тест-кейсов.
Devops-практики в разработке решений для бизнеса, Максим ПашукDevDay
Обычно разработчик успокаивается как только написан код, решающий задачи бизнеса. На самом деле есть ещё целый ряд вопросов, которые также необходимо решать.
Как донести изменения разработчика до тестирования в согласованном виде (база данных, приложение, конфиги)? Как донести эти же изменения до production и ничего не потерять по дороге? Что делать если продукт — распределённая многокомпонентная система, работающая в отказоустойчивом кластере? Тогда ситуация требует тесной совместной работы разработчиков и администраторов, а это, как известно, люди немного с разных планет.
Я расскажу на примере конкретного проекта на .NET стеке, как мы построили мост дружбы. Как свели воедино систему сборки, развёртывания и автоматизации, используя библиотеку psake и достигли взаимопонимания.
Inversion of Control в деталях, Дмитрий КожевниковDevDay
Казалось бы всё сказано об инверсии управления, особенно в .NET. Но нетривиальные квесты вокруг дизайна, построенного на DI, продолжают возникать из проекта в проект. Предлагаю поговорить немного о прописных истинах, а потом перейти к более любопытным вещам и болезненным вопросам.
Чем плох ServiceLocator? Почему IoC-контейнер — это фреймворк, а не библиотека? Как быть с множественными реализациями? Convention over configuration?
Отдельно поговорим об архитектуре enterprise решений в свете возможностей IoC-контейнеров.
Год от года многие программисты решают одни и те же задачи, но не всегда среди огромного многообразия решений можно найти что-то подходящее. Вот и мы не смогли найти ни одной библиотеки логирования для C++, которая удовлетворяла бы всем нашим требованиям. Теперь у нас есть свой велосипед, и мы расскажем, чем он лучше других.
Манипулятор на Ti Stellaris Launchpad, Лёша РоманенкоDevDay
За последние несколько десятков лет робототехника стала очень доступной. Настолько, что можно собрать робота и запрограммировать его даже в домашних условиях, имея подходящий инструментарий. С чего начать? Как попробовать? Именно об этом мы и поговорим на докладе на примере контроллера TI Stellaris Launchpad (аналог Arduino), управляемого с Android-смартфона.
Все мы привыкли писать программы, результаты работы которых можно увидеть и услышать. Хотите, чтобы их можно было ещё и потрогать? На примере создания электронной игры «Лабиринт» вы увидите, как не имея знаний и опыта сделать первый шаг в мир hardware.
Расскажу про первый продукт 2ГИС, который не совсем про организации – 2GIS Dialer. О трудностях создания, и почему их не нужно бояться. Делая что-то новое, вы обязательно с ними столкнетесь:
— Команда будет меняться.
— Конкуренты будут поджимать и опережать.
— Промо-кампании не будут стрелять.
«Бегущий по лезвию. Продуктовые сценарии в дизайне», Макс Карпылев DevDay
С чего начинается проектирование и дизайн новых продуктов — со сценариев. Продуктовые сценарии работы — ключевой элемент в пазле проектирования новых взаимодействий. В докладе покажу какое место сценарии занимают в 2ГИСе, почему они важны и какие сценарии бывают.
«Роль исследований в формировании продуктового видения компании», Лиза Алексе...DevDay
В своем докладе я расскажу о постановке цели и подготовительном этапе при проведении продуктовых исследований. Мы рассмотрим наиболее популярные виды исследований. Специфику исследований на локальном и междунароных рынках. Прикладную ценность результатов исследований. И это всё на примерах продуктов компании 2ГИС.
Матвей Мальков «Ещё один поиск контактов на Android»DevDay
Многие дайлеры не умеют делать поиск по Т9 клавиатуре. Те, что умеют, в большинстве своем делают поиск только по имени/фамилии контакта или по началу номера, а кто-то только с использованием английского алфавита. В 2GIS Dialer нам хотелось искать все контакты по имени, фамилии, телефону (любому из списка и с любого символа), а так же по должности и месту работу (опционально: e-mail и вебсайт, адрес и группы контактов). Кроме того, нам хотелось, чтобы пользователь на любом языке мог найти свои контакты. И в завершение необходимо было, чтобы весь этот поиск работал быстро. О том, как мы добились прогресса в этом деле я и расскажу.
40. • Недоступность узла это норма
• Максимальное время ожидания ответа
17
Особенности в распределенных системах
41. • Недоступность узла это норма
• Максимальное время ожидания ответа
• Корректная деградация вместо полной недоступности
17
Особенности в распределенных системах
44. • Ошибка в своем коде
19
Что может пойти не так
45. • Ошибка в своем коде
• Ошибка в чужом коде (сервис или ОС)
19
Что может пойти не так
46. • Ошибка в своем коде
• Ошибка в чужом коде (сервис или ОС)
• Железо вышло из строя
19
Что может пойти не так
47. • Ошибка в своем коде
• Ошибка в чужом коде (сервис или ОС)
• Железо вышло из строя
• Сеть вышла из строя
19
Что может пойти не так
48. • Ошибка в своем коде
• Ошибка в чужом коде (сервис или ОС)
• Железо вышло из строя
• Сеть вышла из строя
• Эксплутаторы тоже люди
19
Что может пойти не так
97. • Java, C++
• Плюсы
• Параллелизм
34
Языки общего назначения
98. • Java, C++
• Плюсы
• Параллелизм
• Асинхронность
34
Языки общего назначения
99. • Java, C++
• Плюсы
• Параллелизм
• Асинхронность
• Минуcы
34
Языки общего назначения
100. • Java, C++
• Плюсы
• Параллелизм
• Асинхронность
• Минуcы
• Монолит в рантайме
34
Языки общего назначения
101. • Java, C++
• Плюсы
• Параллелизм
• Асинхронность
• Минуcы
• Монолит в рантайме
• Сложно масштабируемы
34
Языки общего назначения
102. • Java, C++
• Плюсы
• Параллелизм
• Асинхронность
• Минуcы
• Монолит в рантайме
• Сложно масштабируемы
• Возможно все, но сложно
34
Языки общего назначения
105. • PHP фреймворки, Ruby on Rails, Django и т.д.
36
Process per Request
106. • PHP фреймворки, Ruby on Rails, Django и т.д.
• Плюсы
36
Process per Request
107. • PHP фреймворки, Ruby on Rails, Django и т.д.
• Плюсы
• Изоляция
36
Process per Request
108. • PHP фреймворки, Ruby on Rails, Django и т.д.
• Плюсы
• Изоляция
• Масштабируемость
36
Process per Request
109. • PHP фреймворки, Ruby on Rails, Django и т.д.
• Плюсы
• Изоляция
• Масштабируемость
• Минуcы
36
Process per Request
110. • PHP фреймворки, Ruby on Rails, Django и т.д.
• Плюсы
• Изоляция
• Масштабируемость
• Минуcы
• Не событийны
36
Process per Request
111. • PHP фреймворки, Ruby on Rails, Django и т.д.
• Плюсы
• Изоляция
• Масштабируемость
• Минуcы
• Не событийны
• Нет асинхронности и неблокируемости
36
Process per Request
112. • PHP фреймворки, Ruby on Rails, Django и т.д.
• Плюсы
• Изоляция
• Масштабируемость
• Минуcы
• Не событийны
• Нет асинхронности и неблокируемости
• Простое масштабирование до определенного предела
36
Process per Request
127. • Node.js, Vert.x
• Вся работа в event loop
• Плюсы
• Событийны, асинхронны, неблокируемы
40
Event Loop
128. • Node.js, Vert.x
• Вся работа в event loop
• Плюсы
• Событийны, асинхронны, неблокируемы
• Минусы
40
Event Loop
129. • Node.js, Vert.x
• Вся работа в event loop
• Плюсы
• Событийны, асинхронны, неблокируемы
• Минусы
• Ограничен одной нодой
40
Event Loop
130. • Node.js, Vert.x
• Вся работа в event loop
• Плюсы
• Событийны, асинхронны, неблокируемы
• Минусы
• Ограничен одной нодой
• Не масштабируется по процессорам
40
Event Loop
131. • Node.js, Vert.x
• Вся работа в event loop
• Плюсы
• Событийны, асинхронны, неблокируемы
• Минусы
• Ограничен одной нодой
• Не масштабируется по процессорам
• Нет механизмов управления отказами
40
Event Loop
136. • Erlang, Akka
• Плюсы
• Событийны, асинхронны, неблокируемы
42
Actor Model
137. • Erlang, Akka
• Плюсы
• Событийны, асинхронны, неблокируемы
• Не ограничены одной нодой
42
Actor Model
138. • Erlang, Akka
• Плюсы
• Событийны, асинхронны, неблокируемы
• Не ограничены одной нодой
• Присутствуют механизмы управления отказами
42
Actor Model
139. • Erlang, Akka
• Плюсы
• Событийны, асинхронны, неблокируемы
• Не ограничены одной нодой
• Присутствуют механизмы управления отказами
• Минусы
42
Actor Model
140. • Erlang, Akka
• Плюсы
• Событийны, асинхронны, неблокируемы
• Не ограничены одной нодой
• Присутствуют механизмы управления отказами
• Минусы
• Форсисрует архитектуру
42
Actor Model
184. • Reactive Manifesto
• Coursera
• Functional Programming Principles in Scala
54
С чего начать
185. • Reactive Manifesto
• Coursera
• Functional Programming Principles in Scala
• Principles of Reactive Programming
54
С чего начать
186. • Reactive Manifesto
• Coursera
• Functional Programming Principles in Scala
• Principles of Reactive Programming
• Typesafe
54
С чего начать
187. • Reactive Manifesto
• Coursera
• Functional Programming Principles in Scala
• Principles of Reactive Programming
• Typesafe
• Activator
54
С чего начать
188. • Reactive Manifesto
• Coursera
• Functional Programming Principles in Scala
• Principles of Reactive Programming
• Typesafe
• Activator
• Видео
54
С чего начать
189. • Reactive Manifesto
• Coursera
• Functional Programming Principles in Scala
• Principles of Reactive Programming
• Typesafe
• Activator
• Видео
• Reactive Streams
54
С чего начать