Антон Пискунов. Независимый разработчик.
«BeeGo для веб-приложений, API и демонов»
- Почему BeeGo? vs Revel and another guys.
- Что мы пишем на BeeGo? Наш личный опыт.
- Как написать облачный стартап и инфраструктурные сервисы на BeeGo за две недели.
- Sweet API, нэймспейсы и автодокументация.
- Демонизация BeeGo, к чему мы пришли?
- Разработчики, мэйнтейнинг, существующие проблемы
http://go-meetup-spb.timepad.ru/event/169777/
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
Доклад с PUG#2 https://www.facebook.com/events/292457000957088/
Доклад о работе в Shell, исполнении PHP в Shell, использовании REPL в PHP, а также эпический батл между Boris и PsySH.
PHP User Group Ukraine в социальных сетях:
https://www.facebook.com/pug.ukraine
https://vk.com/pug.ukraine
https://www.linkedin.com/groups/PHP-User-Group-Ukraine-6703717
Антон Пискунов. Независимый разработчик.
«BeeGo для веб-приложений, API и демонов»
- Почему BeeGo? vs Revel and another guys.
- Что мы пишем на BeeGo? Наш личный опыт.
- Как написать облачный стартап и инфраструктурные сервисы на BeeGo за две недели.
- Sweet API, нэймспейсы и автодокументация.
- Демонизация BeeGo, к чему мы пришли?
- Разработчики, мэйнтейнинг, существующие проблемы
http://go-meetup-spb.timepad.ru/event/169777/
Доклад с PUG#4 https://www.facebook.com/events/350783888446030/
Рассмотрим:
- Что такое Highload, термины, инструменты.
- Где тормозит PHP, родовые травмы языка, как с ними жить.
- Скорость работы vs скорость разработки.
- Архитектура, что стоит делать и когда.
Доклад с PUG#2 https://www.facebook.com/events/292457000957088/
Доклад о работе в Shell, исполнении PHP в Shell, использовании REPL в PHP, а также эпический батл между Boris и PsySH.
PHP User Group Ukraine в социальных сетях:
https://www.facebook.com/pug.ukraine
https://vk.com/pug.ukraine
https://www.linkedin.com/groups/PHP-User-Group-Ukraine-6703717
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...corehard_by
В докладе обсуждаются способы улучшения времени сборки C++ проектов, опыт полученный в ходе ускорения сборки клиента и тулов World Of Tanks. Также описывается эффект, который они оказывают на организацию кодобазы (как позитивный, так и негативный) и затраты, которые необходимы для поддержки этих решений, т.к. не все они бесплатны. Методики, описываемые в докладе: ускорение линковки (Incremental Linking, Fastlink), ускорение компиляции(Include what you use, использование precompiled headers).
Эволюция клиентской разработки: от веба ко "всеобщей мобилизации” или mobile-...Pavel Dovbush
История развития проекта с точки зрения клиентских технологий - от веб-сайта к появлению мобильных клиентов и смещению фокуса к mobile-first разработке. Общие черты нашей архитектуры и их отличия от стандартных решений.
Единый протокол общения с приложениями iOS/Android/WindowsMobile/MobileWeb/Web и особенности реализации для JavaScript платформ (десктопные и мобильные браузеры).
Изменение процесса разработки и подходов к реализации нового функционала для переключения на mobile-first стратегию.
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)
Дизайн платформа в Avito - Александр Лобашев (Avito)AvitoTech
Компонентный подход принес много пользы, а вместе с тем и проблему переиспользования компонентов. В проекте появились сотни, тысячи компонентов, но со временем мы совсем забыли где они живут, как их использовать и как они выглядят. А что если дизайнер нарисовал интерфейс с новой кнопкой? Использовать текущий компонент или сделать новую кнопку для маленького интерфейса?
Я расскажу, как мы сделали пряничный домик для дизайнеров, а также наладили коммуникацию и коллаборацию между дизайнерами, разработчиками и менеджерами.
Rempl — крутая платформа для крутых инструментов - Роман Дворнов (Avito)AvitoTech
Роман Дворнов (Avito)
Фронтенд усложняется с каждым днем, и уже не представить жизнь разработчика без инструментов. Инструментов становится все больше, но нельзя сказать, что их достаточно. Если у вас собственный стек или технологическое решение, вам рано или поздно потребуется сделать свой инструмент. Это не так просто! Особенно если вы захотите интегрировать его интерфейс в браузерные Developer Tools, IDE, редакторы или открыть их на другом устройстве. Добавьте сюда проблему версионирования и другие сложности, и вам покажется, что задача неподъемная.
Но есть хорошая новость! Большинство из этих проблем решает Rempl — платформа для создания и использования удаленных инструментов (на самом деле не только инструментов). Сделаем небольшой обзор Rempl: что это, зачем нужно, какие проблемы решает. А также посмотрим примеры готовых решений, построенных на Rempl.
После докладов мы проведём дискуссионную панель на тему "Организация системы компонент", в которой примут участие докладчики, а также приглашенные эксперты.
Performance management lessons learnt / Андрей Дмитриев (JUGRU)Ontico
В идеальном мире нагрузочное тестирование проводится своевременно, с должной поддержкой со стороны разработчиков, на подходящем железе и с нужным объемом данных.
В реальности выполнение многих задач может запаздывать, способ решения может меняться и заказчик может менять свои планы.
Как минимальными усилиями можно провести тестирование производительности, при этом не упустив важных кейсов?
Наша команда проводит нагрузочное тестирование на десятке различных аккаунтов по всему миру и за последнее время накопила большой опыт, проводя тестирование полного цикла: от сбора требований до выдачи отчета заказчику.
В этом докладе я постараюсь охватить не только подход к нагрузочному тестированию, который мы практикуем, но и подход к управлению скоростными характеристиками проекта.
Работаем с API по-взрослому - Максим Кислов (Badoo)AvitoTech
Я расскажу о том, как мы разрабатываем фронтенд и бэкенд параллельно, используя protobuf + JSON RPC.
Часто фронтенд выставляет требования к бэкенду, из этих требований получается API, и разработка возможна только при одновременной работе серверного и клиентского девелопера.
Мы же начинаем разработку с API, и фронтенд (а также мобильные приложения) никак не зависят от степени готовности бэкенда.
– Я поделюсь тем, как мы делаем API до начала разработки;
– Success story использования protobuf + RPC;
– И немного – о разработке клиента вообще без серверного кода.
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
C++ CoreHard Autumn 2018. Ускорение сборки C++ проектов, способы и последстви...corehard_by
В докладе обсуждаются способы улучшения времени сборки C++ проектов, опыт полученный в ходе ускорения сборки клиента и тулов World Of Tanks. Также описывается эффект, который они оказывают на организацию кодобазы (как позитивный, так и негативный) и затраты, которые необходимы для поддержки этих решений, т.к. не все они бесплатны. Методики, описываемые в докладе: ускорение линковки (Incremental Linking, Fastlink), ускорение компиляции(Include what you use, использование precompiled headers).
Эволюция клиентской разработки: от веба ко "всеобщей мобилизации” или mobile-...Pavel Dovbush
История развития проекта с точки зрения клиентских технологий - от веб-сайта к появлению мобильных клиентов и смещению фокуса к mobile-first разработке. Общие черты нашей архитектуры и их отличия от стандартных решений.
Единый протокол общения с приложениями iOS/Android/WindowsMobile/MobileWeb/Web и особенности реализации для JavaScript платформ (десктопные и мобильные браузеры).
Изменение процесса разработки и подходов к реализации нового функционала для переключения на mobile-first стратегию.
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)
Дизайн платформа в Avito - Александр Лобашев (Avito)AvitoTech
Компонентный подход принес много пользы, а вместе с тем и проблему переиспользования компонентов. В проекте появились сотни, тысячи компонентов, но со временем мы совсем забыли где они живут, как их использовать и как они выглядят. А что если дизайнер нарисовал интерфейс с новой кнопкой? Использовать текущий компонент или сделать новую кнопку для маленького интерфейса?
Я расскажу, как мы сделали пряничный домик для дизайнеров, а также наладили коммуникацию и коллаборацию между дизайнерами, разработчиками и менеджерами.
Rempl — крутая платформа для крутых инструментов - Роман Дворнов (Avito)AvitoTech
Роман Дворнов (Avito)
Фронтенд усложняется с каждым днем, и уже не представить жизнь разработчика без инструментов. Инструментов становится все больше, но нельзя сказать, что их достаточно. Если у вас собственный стек или технологическое решение, вам рано или поздно потребуется сделать свой инструмент. Это не так просто! Особенно если вы захотите интегрировать его интерфейс в браузерные Developer Tools, IDE, редакторы или открыть их на другом устройстве. Добавьте сюда проблему версионирования и другие сложности, и вам покажется, что задача неподъемная.
Но есть хорошая новость! Большинство из этих проблем решает Rempl — платформа для создания и использования удаленных инструментов (на самом деле не только инструментов). Сделаем небольшой обзор Rempl: что это, зачем нужно, какие проблемы решает. А также посмотрим примеры готовых решений, построенных на Rempl.
После докладов мы проведём дискуссионную панель на тему "Организация системы компонент", в которой примут участие докладчики, а также приглашенные эксперты.
Performance management lessons learnt / Андрей Дмитриев (JUGRU)Ontico
В идеальном мире нагрузочное тестирование проводится своевременно, с должной поддержкой со стороны разработчиков, на подходящем железе и с нужным объемом данных.
В реальности выполнение многих задач может запаздывать, способ решения может меняться и заказчик может менять свои планы.
Как минимальными усилиями можно провести тестирование производительности, при этом не упустив важных кейсов?
Наша команда проводит нагрузочное тестирование на десятке различных аккаунтов по всему миру и за последнее время накопила большой опыт, проводя тестирование полного цикла: от сбора требований до выдачи отчета заказчику.
В этом докладе я постараюсь охватить не только подход к нагрузочному тестированию, который мы практикуем, но и подход к управлению скоростными характеристиками проекта.
Работаем с API по-взрослому - Максим Кислов (Badoo)AvitoTech
Я расскажу о том, как мы разрабатываем фронтенд и бэкенд параллельно, используя protobuf + JSON RPC.
Часто фронтенд выставляет требования к бэкенду, из этих требований получается API, и разработка возможна только при одновременной работе серверного и клиентского девелопера.
Мы же начинаем разработку с API, и фронтенд (а также мобильные приложения) никак не зависят от степени готовности бэкенда.
– Я поделюсь тем, как мы делаем API до начала разработки;
– Success story использования protobuf + RPC;
– И немного – о разработке клиента вообще без серверного кода.
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного se...Sergey Xek
Полмиллиона юзеров в онлайне без падений: оптимизация высоконагруженного server-side API десктопного приложения. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Evolution of web-project requires scalable architecture and scalable development process. In my presentation (in Russian): different techniques, how to achieve this if talking about Perl-based web project.
Когда проект делает один разработчик — все просто. Когда над ним работает небольшая команда, можно синхронизироваться и договориться. А вот когда проектов (сайтов и приложений) становится много, и над ними трудится множество команд с перекрестной функциональностью и смежными зонами ответственности, все становится сложным и запутанным.
Я расскажу о своем виденье архитектуры фронтенда, какой она должна быть, чтобы обеспечить её масштабируемость. На основе своего опыта и проблем, с которыми сталкиваются большие проекты.
Видео: https://www.youtube.com/watch?list=PLknJ4Vr6efQFtZmsXmGG64Rz_PHrcXCBL&v=z9y6PNC2FL0
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Ontico
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
См. тезисы - http://rootconf.ru/2015/abstracts/1746
Мониторинг в высоконагруженных (и не только) проектах: сравнительный анализ с...Anton Baranov
Выбор системы мониторинга - это практически holy-war-ная тема среди администраторов и разработчиков. Какая система лучше? Что удобнее? Какая система сможет выдержать большое количество статистики, а какая - лучше собрать и представить данные?
В своем докладе мы попробуем предельно непредвзято рассмотреть существующие решения и понять, что и когда можно использовать.
Прежде всего, мы постараемся сделать доклад не сравнением feature-листов, а рассмотреть особенности практического применения разных систем для конкретной задачи - для сайта, который не должен падать (а точнее - для возможности оперативно отреагировать на аварию, понять что к ней привело, и как можно ее исправить).
15. Берём отчет по скриптам. Периоды ? ... Это базы грузит регулярно запускаемый скрипт! Имея «разрез» по тегам (что за операции, какие базы) – ещё быстрее найдем причину