Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Тестирование через мониторинг или холакратия на практике / Максим Чистяков (U...Ontico
Чтобы быстро двигаться, надо быстро двигаться :-)
Скоростная разработка продукта невозможна без непрекращающегося выкатывания свежих изменений в боевое окружение. Именно это позволяет Ultimate-Guitar оставаться #1 world's guitar service.
Когда-то давным-давно мы приняли для себя, что "мы движемся очень быстро и иногда из-за этого что-то ломаем. Недоставленный пользователям продукт/непроверенная гипотеза хуже, чем временная неработоспособность части сервиса. Поэтому мы убираем преграды между новым кодом и продакшном: не тратим время ни на тестирование, ни на строгий релиз-менеджмент".
Многие возникающие проблемы касаются только обслуживания (датацентр, OS, каналы) и мониторинг, естественно, необходим. Ну, а раз уж у нас есть мониторинг, то давайте считать систему единым целым, которая может выходить из строя по различным причинам, одной из которых является ошибка в коде. Это привело нас к идее использовать мониторинг вместо тестирования. К чему это привело, почему мы любим Anturis, Graylog, Grafana, что главное в деплое - это быстрый откат и другие прелести управления звездолётом Ultimate-Guitar с дневным населением больше Москвы на скорости 10 деплоев/час - обо всё этом пойдёт речь в этом докладе:
- Про скорость и цену быстрого развития (Innovation Costs).
- Холакратия в бранчах, "сам себе релиз-инженер", ответственность и честность.
- Скорость отката > скорость деплоя.
- Как умер QA или демоны с tail и Graylog.
- Когда не нужны микросервисы: успеть за 30 секунд, медленный Mercurial и шустрое комбо Git + Capistrano + Ansible.
- Бесполезные фичи, бритва Оккама и пользователи, которые на самом деле любят изменения :-)
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Доклад о том, как мы добились идеально ровной балансировки нагрузки по кластеру из 200+ серверов, реализовали автоматический подбор весов и получили разброс CPU usage в 2,5% в пике трафика. Это позволило сэкономить нам около 40-50 серверов и улучшить время отклика мобильного сайта в пике нагрузки. Реализацию приведенного алгоритма мы выложим в open-sourсe. Доклад Юрия Насретдинова на Highload 2015.
Тестирование через мониторинг или холакратия на практике / Максим Чистяков (U...Ontico
Чтобы быстро двигаться, надо быстро двигаться :-)
Скоростная разработка продукта невозможна без непрекращающегося выкатывания свежих изменений в боевое окружение. Именно это позволяет Ultimate-Guitar оставаться #1 world's guitar service.
Когда-то давным-давно мы приняли для себя, что "мы движемся очень быстро и иногда из-за этого что-то ломаем. Недоставленный пользователям продукт/непроверенная гипотеза хуже, чем временная неработоспособность части сервиса. Поэтому мы убираем преграды между новым кодом и продакшном: не тратим время ни на тестирование, ни на строгий релиз-менеджмент".
Многие возникающие проблемы касаются только обслуживания (датацентр, OS, каналы) и мониторинг, естественно, необходим. Ну, а раз уж у нас есть мониторинг, то давайте считать систему единым целым, которая может выходить из строя по различным причинам, одной из которых является ошибка в коде. Это привело нас к идее использовать мониторинг вместо тестирования. К чему это привело, почему мы любим Anturis, Graylog, Grafana, что главное в деплое - это быстрый откат и другие прелести управления звездолётом Ultimate-Guitar с дневным населением больше Москвы на скорости 10 деплоев/час - обо всё этом пойдёт речь в этом докладе:
- Про скорость и цену быстрого развития (Innovation Costs).
- Холакратия в бранчах, "сам себе релиз-инженер", ответственность и честность.
- Скорость отката > скорость деплоя.
- Как умер QA или демоны с tail и Graylog.
- Когда не нужны микросервисы: успеть за 30 секунд, медленный Mercurial и шустрое комбо Git + Capistrano + Ansible.
- Бесполезные фичи, бритва Оккама и пользователи, которые на самом деле любят изменения :-)
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
Многие аналитики предрекают реактивному программированию большое будущее в решении задач Mobile и Big Data.
TypeSafe, разработчики языка Scala, создали многообещающий реактивный фреймворк Akka, который "дружит" с Java.
Чем он может быть интересен Java-разработчикам? Сможет ли Akka+Java конкурировать с Akka+Scala? И как ей в этом помогут новые фичи Java 8?
Об этом я расскажу в своем докладе "Посмотрим на Акку-Джаву".
Chef по обе стороны Bamboo / Артем Семенов (Align Technology)Ontico
Строим CI/CD в Bamboo, используя Chef
-----
Мы покажем эволюционный путь нашего CI/CD-процесса от маленького скрипта на python, до фреймворка на ruby:
+ рассмотрим типичные трудности, возникающие при построении CI/CD процесса с помощью CI-движка и Configuration management tools.
+ покажем реализованные решения на примере связки Chef + Bamboo:
o унификация деплоймент-процесса компании;
o деплойменты на гетерогенные environment'ы, включая Linux/Windows системы;
o инструментарий для построения CD-процесса в Bamboo.
Управление билд-фермой Bamboo с помощью Chef
-----
Для поддержки SDLC-процесса компании мы эксплуатируем большую географически распределенную гетерогенную билд-ферму агентов (80+ агентов на базе Windows, Linux и MacOS). С ростом количества билд-конфигураций и агентов мы столкнулись с задачей управления конфигурациями билд-агентов, с которой успешно справляемся с помощью решения на базе Chef.
Примеры решаемых задач:
+ настройка Bamboo-агентов с нуля;
+ сapability management при помощи ohai;
+ повышение эффективности использования билд-фермы.
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".Badoo Development
О чем доклад:
- Как в нашем проекте устроен Zabbix, применяемые нами способы автоматизации, собственные методы "дискавери" серверов и сервисов. Плюс как правильно держать Zabbix под высокой нагрузкой и не упираться в ресурсы серверов.
- Для чего мы используем Pinba, какие именно метрики помогают нам узнать о реальных проблемах пользователей.
- Как мы храним графики в RRD. Мониторинг этих графиков: User activity monitoring.
- Zabbix -> RRD => Capacity Planning.
Как быстро найти слабые места среди кластеров в десятки и сотни нод.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Microsoft и Linux на одном проекте: как получить лучшее из обоих миров и не р...Ontico
2-3 года назад у нас был на 100% MS стек (Винда, Hyper-V, MSSQL, IIS, C#, WCF, Azure), и было не очень понятно, как продукт дальше развивать: C#, конечно, неплохой язык, но оставаться в рамках MS - слишком большие ограничения по выбору продуктов: чего-то на винде до сих пор нет (например, Докера), а для многих серверных продуктов рынок винды вторичен.
Получалось, что все понимают тупиковость ситуации, но продолжают тащить этот чемодан без ручки, потому что делать-то что-то надо. Переписать весь проект с нуля под новые технологии - это год работы вхолостую для бизнеса, и ни один инвестор в мире на такое не согласился бы.
Так вот, могу рассказать, как нам удалось постепенно выйти из этого тупика без остановки бизнес-девелопмента и переобучения всей команды на другой язык/платформу.
Сейчас у нас диверсифицированная система:
- виртуалки на винде и убунте. HA организуется силами Hyper-V и Rancher;
- несколько разных стораджей: Cassandra, Redis, MS SQL, PostgreSQL и Spark, который из всего этого зоопарка делает общую аналитику (нет, мы не ставили все подряд, они все нужны, зачем - расскажу);
- сервисы на C# и питоне, которые прекрасно общаются по общей шине и мы спокойно можем ждать выхода полноценного .net core еще пару лет.
И, предваряя вопрос - нет, на Mono или текущий .NET core без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
мониторинг производительности Web приложений на pythonSlach
как понять где тормозит твое приложение в реальном времени? как не потеряться в океане метрик и собрать на дашборде только нужные? видео https://youtu.be/JgezdgtoNG8
Архитектура поиска в Avito / Андрей Смирнов (Avito)Ontico
Из доклада вы узнаете о том, как в Avito используется Sphinx search, почему было выбрано это решение, какие подводные камни встретились на пути, и как их преодолеть.
Андрей поделится практическим опытом настройки и оптимизации Sphinx search, который позволяет добиться стабильной работы кластера и высокой скорости индексации и поиска. В Avito Sphinx индексирует 35 млн. объявлений каждые 7 минут!
Многие аналитики предрекают реактивному программированию большое будущее в решении задач Mobile и Big Data.
TypeSafe, разработчики языка Scala, создали многообещающий реактивный фреймворк Akka, который "дружит" с Java.
Чем он может быть интересен Java-разработчикам? Сможет ли Akka+Java конкурировать с Akka+Scala? И как ей в этом помогут новые фичи Java 8?
Об этом я расскажу в своем докладе "Посмотрим на Акку-Джаву".
Chef по обе стороны Bamboo / Артем Семенов (Align Technology)Ontico
Строим CI/CD в Bamboo, используя Chef
-----
Мы покажем эволюционный путь нашего CI/CD-процесса от маленького скрипта на python, до фреймворка на ruby:
+ рассмотрим типичные трудности, возникающие при построении CI/CD процесса с помощью CI-движка и Configuration management tools.
+ покажем реализованные решения на примере связки Chef + Bamboo:
o унификация деплоймент-процесса компании;
o деплойменты на гетерогенные environment'ы, включая Linux/Windows системы;
o инструментарий для построения CD-процесса в Bamboo.
Управление билд-фермой Bamboo с помощью Chef
-----
Для поддержки SDLC-процесса компании мы эксплуатируем большую географически распределенную гетерогенную билд-ферму агентов (80+ агентов на базе Windows, Linux и MacOS). С ростом количества билд-конфигураций и агентов мы столкнулись с задачей управления конфигурациями билд-агентов, с которой успешно справляемся с помощью решения на базе Chef.
Примеры решаемых задач:
+ настройка Bamboo-агентов с нуля;
+ сapability management при помощи ohai;
+ повышение эффективности использования билд-фермы.
Доклад Ильи Аблеева на DevOps Meetup "Мониторинг высоконагруженного проекта".Badoo Development
О чем доклад:
- Как в нашем проекте устроен Zabbix, применяемые нами способы автоматизации, собственные методы "дискавери" серверов и сервисов. Плюс как правильно держать Zabbix под высокой нагрузкой и не упираться в ресурсы серверов.
- Для чего мы используем Pinba, какие именно метрики помогают нам узнать о реальных проблемах пользователей.
- Как мы храним графики в RRD. Мониторинг этих графиков: User activity monitoring.
- Zabbix -> RRD => Capacity Planning.
Как быстро найти слабые места среди кластеров в десятки и сотни нод.
Путь DevOps в «Parallels» / Константин Назаров (Parallels)Ontico
В этом докладе я расскажу вам историю о своих попытках улучшить процессы в компании Parallels. Она будет насыщена "фейлами" и набором неочевидных и спорных ситуаций, с коротыми вы можете столкнуться, если пойдете по "пути инноватора".
Я расскажу:
- чего удалось добиться за 3 года;
- далеко ли могут увести вас чисто инструментальные решения;
- с какими управленческими проблемами приходится столкнуться, если вы "внедряете DevOps";
- какой может быть предел влияния у "DevOps команды";
- типичные ситуации, в которых можно легко "завязнуть", и их корневые причины.
Docker в работе: взгляд на использование в Badoo через годBadoo Development
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
- 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
- Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
- Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
- Лучшее ли место для тестирования production? Путь образа от сборки до Production.
- baDocker: webUI своими руками: зачем и почему?
- Как дать возможность управлять запущенными сервисами и их версиями разработчику.
- Docker: мониторинг и анализ работающих контейнеров.
Доклад Антона Турецкого на Highload 2015.
https://youtu.be/UgUuF_qZmWc
Microsoft и Linux на одном проекте: как получить лучшее из обоих миров и не р...Ontico
2-3 года назад у нас был на 100% MS стек (Винда, Hyper-V, MSSQL, IIS, C#, WCF, Azure), и было не очень понятно, как продукт дальше развивать: C#, конечно, неплохой язык, но оставаться в рамках MS - слишком большие ограничения по выбору продуктов: чего-то на винде до сих пор нет (например, Докера), а для многих серверных продуктов рынок винды вторичен.
Получалось, что все понимают тупиковость ситуации, но продолжают тащить этот чемодан без ручки, потому что делать-то что-то надо. Переписать весь проект с нуля под новые технологии - это год работы вхолостую для бизнеса, и ни один инвестор в мире на такое не согласился бы.
Так вот, могу рассказать, как нам удалось постепенно выйти из этого тупика без остановки бизнес-девелопмента и переобучения всей команды на другой язык/платформу.
Сейчас у нас диверсифицированная система:
- виртуалки на винде и убунте. HA организуется силами Hyper-V и Rancher;
- несколько разных стораджей: Cassandra, Redis, MS SQL, PostgreSQL и Spark, который из всего этого зоопарка делает общую аналитику (нет, мы не ставили все подряд, они все нужны, зачем - расскажу);
- сервисы на C# и питоне, которые прекрасно общаются по общей шине и мы спокойно можем ждать выхода полноценного .net core еще пару лет.
И, предваряя вопрос - нет, на Mono или текущий .NET core без серьезного переписывания перейти зачастую нельзя. Мы - как раз тот случай.
My talk on Hadoop stack operations engineering at OSPConAlex Chistyakov
My talk on Hadoop stack operations engineering at OSPCon Nov 2015 (http://www.ospcon.ru/event/prakticheskaya-konferentsiya-tekhnologii-bolshikh-dannykh_130.html)
Сравнение решений по балансировке высоконагруженных систем / Евгений Пивень (...Ontico
+ Функционал разных решений для балансировки.
+ Виды балансировщиков (DNS, hardware, software, облачные решения).
+ Поведение при скачках трафика и возможности скалирования сервиса.
+ Специфика трафика RTB в контексте балансировки.
+ Проблемы, которые возникали у нас, и как мы их решали.
Zabbix 3.2 - мониторинг качественно нового уровня / Алексей Владышев (Zabbix)Ontico
Вне зависимости от размера инфраструктуры, весьма сложно разобраться в проблемах, обнаруженных системой мониторинга, особенно если их сотни или тысячи. Они могут быть о железе, приложениях, связаны с безопасностью, тестовыми и продакшн средами, различными датацентрами и сервисами. Как эффективно управлять этой сложностью? Как удобно отображать проблемы для коллег, отвечающих за различные куски инфраструктуры?
Новая мажорная версия Zabbix 3.2 революционна и отвечает на эти вопросы!
Модуль корреляции событий на глобальном уровне и уровне одной проблемы, система тагов, новая супер быстрая панель для отображения проблем, вложенные группы устройств, возможность ручного закрытия проблем и многое другое позволяют построить эффективный мониторинг любого размера или качественно улучшить существующий.
Я расскажу о новой функциональности и покажу, как её использовать для построения, в том числе, сервис-ориентированного мониторинга. Многие вещи стали намного проще. Иногда может быть достаточно одного триггера для мониторинга всех сервисов или приложений компании. Фантастика! Как это возможно? Приходите и узнаете.
Загрузка больших объемов данных для бизнес-аналитикиBadoo Development
В Badoo мы разрабатываем собственную систему Business intelligence (сокращённо BI). И прежде, чем приступать к анализу данных, их необходимо извлечь (Extract) из источников, преобразовать (Transform) и загрузить (Load) в аналитическую базу.
Я расскажу об этом процессе - ETL (Extract, Transform, Load). Какие бывают источники данных, какие методы сбора мы используем. И самое главное - об инструменте под названием ETLMaster, созданным в нашей компании для автоматизации управления процессом трансформации и загрузки данных.
мониторинг производительности Web приложений на pythonSlach
как понять где тормозит твое приложение в реальном времени? как не потеряться в океане метрик и собрать на дашборде только нужные? видео https://youtu.be/JgezdgtoNG8
Переход с Objective-C на Swift — все ли так просто? / Олег Алексеенко (SuperJob)Ontico
РИТ++ 2017, App's Conf
Зал Найроби, 6 июня, 10:00
Тезисы:
http://appsconf.ru/2017/abstracts/2818.html
Ни для кого не секрет, что Swift — это mainstream: его активно продвигает Apple, на нем пишутся все новые фреймворки, многие разработчики начинают именно с него. Но так ли просто мигрировать c Objective-С, если твоему приложению 5 лет и оно имеет большую аудиторию? В докладе мы расскажем о том, как сделать это без ущерба для бизнеса.
Вы узнаете об этапах такого перехода:
1. Какую бизнес-проблему решали? - Ускоряем разработку, уменьшаем количество багов, проще и быстрее находим новых сотрудников, ограждаем от будущих рисков (старых не поддерживаемых фреймворков, устаревших АПИ).
...
Подходы и технологии, используемые в разработке iOS-клиента Viber, Кирилл Лаш...Yandex
Рассказ об основных принципах, которых придерживается Viber в длительной разработке приложения с большой кодовой базой — если разработкой занимается распределённая команда. Мы обсудим используемые технологии, библиотеки, работу с кодом и многое другое.
WebCamp2016:Front-End_Роман Якобчук_Relay, GraphQL и остальные радости соврем...WebCamp
WebCamp2016, 29 июля, Одесса
Роман Якобчук (Senior Software Engineer, RevJet)
Relay, GraphQL и остальные радости современного React
После бури различных библиотек, направлений и обновлений в мире React, которая обрушилась на нас в прошлом году, мы почувствовали некоторое затишье. Действительно за последние полгода мы уже успели немного заскучать, это прекрасный момент выдохнуть и разобраться с технологиями которые выпустил Facebook для фетчинга данных в React (GraphQL, Relay), и тем, на что это вдохновило комьюнити.
Website: http://webcamp.in.ua/devops.html#theme
Facebook: https://www.facebook.com/WebCamp/
VK: https://vk.com/webcamp
Twitter: https://twitter.com/WebCampOdessa
Youtube: http://bit.ly/2bsQ0LO
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
Семинар по Node.js в КПИ 20 октября 2014. Докладчики: Тимур Шемсединов, Никита Савченко, Максим Петренко. Краткое содержание:
* Что такое Node.js и как работает JavaScript в V8
* Профессионалы расскажут, почему они выбрали Node.js
* Вы узнаете его сильные и слабые стороны и где его лучше применять
* Будет полный обзор особеностей и внутреннего строения Node.js
* Примеры внедрения и Highload-проекты
* Вопросы развертывания, хостинг, тестирования, и отладки
* Где и что учить, что читать, как осваивать
Юлия Цисык «RESTFul API в вашем.NET приложении: как, зачем и почему?»Yulia Tsisyk
Ни один современный продукт не обходится без API. Этот API может быть внешним, для публичного использования, а может быть сугубо внутренним, но требования к созданию расширяемого, версионируемого, тестируемого, документированного программного интерфейса очень похоже. В этом докладе мы поговорим о том, как создавать подобные API на основе REST, какие существуют best-practices, чего следует избегать, на что обращать внимание при проектировании.
Similar to SECON'2016. Мухаметов Андрей, RxSwift && Apple TV - так ли хорошо всё новое? (20)
SECON'2017, LAZADA Effartlrss Shopping, Как мы тестируем?SECON
Тестирование заказов в ecommerce международного масштаба/ Order Lifecycle - Жизненный цикл заказа vs QA / Lazada. Азиатская кухня ecommerce тестирования.
The document provides an overview of Go as a programming language and its use for building servers. Some key points covered include:
- Go encourages a certain programming style with features like error handling, concurrency, and static typing.
- Utilities for working with Go like go get, gofmt, golint, go vet, and go test are discussed.
- Examples of using Go for building chat servers, distributed systems, and profiling/monitoring Go applications are provided.
- Common errors when programming in Go like data races, channel sends to closed channels, variable reuse, and WaitGroup reuse are mentioned.
The document serves as an introduction to Go and outlines some of its features and common patterns for
SECON'2017, Макарычев Костантин, Использование Spark для машинного обученияSECON
This document discusses machine learning in Apache Spark. It describes how Spark can be used for large-scale machine learning tasks through libraries like MLlib. It provides an example machine learning pipeline that preprocesses text data using tokenization and hashing, trains a logistic regression model, and saves the model for later use. The document also discusses serving machine learning models and different approaches for deploying Spark and machine learning applications in production.
11. Задача
• Загрузка бесконечного потока контента
через REST API
• Отображение ленты контента в виде
плиток
• Автоматическая прокрутка ленты
изображений
14. Alamofire router
enum Router: URLRequestConvertible {
static let baseURLString = "http://web-api.ifunny.mobi/ifunny/v1/feeds/featured"
case GetFeatured(next: String?)
var URLRequest: NSMutableURLRequest {
let parameters: ([String: AnyObject]) = {
switch self {
case .GetFeatured(let next) where next != nil:
return (["next": next!])
case .GetFeatured(_):
return ([:])
}
}()
let URL = NSURL(string: Router.baseURLString)!
let URLRequest = NSURLRequest(URL: URL)
let encoding = Alamofire.ParameterEncoding.URL
return encoding.encode(URLRequest, parameters: parameters).0
}
}
15. ObjectMapper + Alamofire
• Удобный маппинг объектов
• Полностью заменяет все средства
RestKIT
• Поддерживает маппинг в объекты из
JSON и обратно
• Поддержка структур