Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет. В докладе пойдет речь о том, что хорошо работающий фронтенд — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но и циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Эволюция клиентской разработки: от веба ко "всеобщей мобилизации” или mobile-...Pavel Dovbush
История развития проекта с точки зрения клиентских технологий - от веб-сайта к появлению мобильных клиентов и смещению фокуса к mobile-first разработке. Общие черты нашей архитектуры и их отличия от стандартных решений.
Единый протокол общения с приложениями iOS/Android/WindowsMobile/MobileWeb/Web и особенности реализации для JavaScript платформ (десктопные и мобильные браузеры).
Изменение процесса разработки и подходов к реализации нового функционала для переключения на mobile-first стратегию.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагр...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагрузкой, в поисках проблем...", Филипп Дельгядо (CTO Goodwix, ex-teamlead Яндекс.Деньги)
Аннотация
Не так давно с некоторым изумлением узнал, что Java для нагруженных систем представляется совершенной terra incognita. Хотя и совершенно не хочется бороться с мифами, по крайней мере, с удовольствием расскажу, как просто и без хлопот использовать Java в вебе. Про "суровый" highload рассказывать не буду, а вот про простые решения - с удовольствием. Ну и на закуску расскажу, за что я нежно люблю блобы.
О себе
Teamlead сколько себя помню, успел поработать и в "Яндекс.Деньгах" и в "БК Марафон". Люблю простые решения, сложные задачи и хорошую коммуникацию.
Badoo — это большая социальная сеть с более чем 180 млн. пользователей. Большинство новых фич в нашей компании мы предварительно оцениваем посредством A/B тестирования. Вот уже примерно год мы используем собственный высоконагруженный фреймворк тестирования, при этом по моему мнению он очень прост, понятен, и не требует огромных ресурсов на разработку и поддержку. В докладе я расскажу вам о том, почему мы пришли к собственному решению, его архитектуру и принципы работы. Я уверен, каждый из вас может сделать что-то подобное для своего проекта и начать принимать более обоснованные решения.
Тезисы:
* Как мы раньше тестировали
* Почему мы сделали свой инструмент
* Архитектура: API, граф. интерфейсы, транспорт, скрипты, БД
* Структура теста
* Основные правила А/Б тестирования
* Оценка результатов, примеры отчетов
* И заключительная часть про то, что от человека с головой полностью не избавиться
Для кого доклад:
Для разработчиков и техн. менеджеров соц. сетей, сайтов объявлений, блогов с рассылками, проектов, продающих что-то через e-mail расслыки, разных коммьюнити-сайтов, банков и вообще проектов, где взаимодействие с каждым клиентом долгосрочное.
Сложность:
Несмотря на то, что конференция называется Highload++, я уверяю, что представленную здесь архитектуру может потянуть проект с посещаемостью в 1000 чел в день и тремя программистами в штате. Закодить все, что здесь рассказано на PHP займет меньше недели одного человека. А результат, между прочим, пожно вполне изменрять в живой прибыли.
Badoo Desktop: оптимизация приложения на миллион юзеров онлайнSergey Xek
Badoo Desktop: оптимизация приложения на миллион юзеров онлайн. Сергей Аверин, Badoo.
Доклад рассказывает о реально примененных способах оптимизации производительности API компании Badoo для собственных десктоп-приложений: как специфика «много постоянных соединений/однотипные запросы/большая нагрузка» повлияла на стратегию оптимизации производительности.
Что было сделано:
• Планирование архитектуры изначально (fault-tolerance, адаптивные апдейты и тайм-ауты, отказ от попыток восстановления после ошибок для единичных команд).
• Переехали с redis на handlersocket.
• Rate-limiting запросов к демонам.
• Синхронизация записей.
• Асинхронность.
• Записи при достижении порога изменения параметров.
• Профилирование кода, анализ потребления CPU, времени ответа.
• Статистика, статистика и еще раз статистика.
• Pconnect.
Доклад будет интересен:
• системным архитекторам,
• server-side разработчикам.
Javascript-фреймворки: должен остаться только одинSergey Xek
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Эволюция клиентской разработки: от веба ко "всеобщей мобилизации” или mobile-...Pavel Dovbush
История развития проекта с точки зрения клиентских технологий - от веб-сайта к появлению мобильных клиентов и смещению фокуса к mobile-first разработке. Общие черты нашей архитектуры и их отличия от стандартных решений.
Единый протокол общения с приложениями iOS/Android/WindowsMobile/MobileWeb/Web и особенности реализации для JavaScript платформ (десктопные и мобильные браузеры).
Изменение процесса разработки и подходов к реализации нового функционала для переключения на mobile-first стратегию.
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагр...IT-Portfolio
13 октября, DEV {web} - конференция о Highload веб-разработке. "Java под нагрузкой, в поисках проблем...", Филипп Дельгядо (CTO Goodwix, ex-teamlead Яндекс.Деньги)
Аннотация
Не так давно с некоторым изумлением узнал, что Java для нагруженных систем представляется совершенной terra incognita. Хотя и совершенно не хочется бороться с мифами, по крайней мере, с удовольствием расскажу, как просто и без хлопот использовать Java в вебе. Про "суровый" highload рассказывать не буду, а вот про простые решения - с удовольствием. Ну и на закуску расскажу, за что я нежно люблю блобы.
О себе
Teamlead сколько себя помню, успел поработать и в "Яндекс.Деньгах" и в "БК Марафон". Люблю простые решения, сложные задачи и хорошую коммуникацию.
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
SWD Page Recorder: Записывает PageObject'ы со скоростью ниндзя SeleniumCamp 2014Dmytro Zharii
Демонстрация работы инструмента записи веб-элементов PageObject для Selenium WebDriver при помощи SWD Page Recorder. Демонстрация работы фреймворка SWD Starter Kit
Читабельные отчеты для автоматизации на C# / Gallio / BDDfyDmytro Zharii
Мой доклад про создание читабельных отчетов для автоматизации тестирования на .NET/C# + Webdriver + Gallio Icarus/MbUnit + BDDfy
Доклад был сделан специально для онлайн конференции Auto ConfeT&QA, прошедшей в октябре 2012 года.
http://confetqa.ru/
======================================
См. также:
Gallio Icarus:
http://gallio.org
BDDfy – фреймворк для БыДиДификации кода :)
Страница проекта на Github:
http://teststack.github.com/TestStack.BDDfy/
Описание на английском:
http://www.mehdi-khalili.com/bddify-in-action/introduction
Александр Баумгертнер — Преимущества БЭМ для небольших проектов и компанийYandex
БЭМ хорош не только для крупных проектов и больших команд. БЭМ — не про именование CSS-классов и i-bem. Он вполне подходит для прототипирования. В докладе пойдет речь о библиотеке для создания основных блоков (форма регистрации, список новостей и статей, категория товаров, карточка товара, форма заказа и т.д.), сборке статичной html-версии сайта и практике разработки.
Субъективная точка зрения на фронтенд разработку.
Площадка: IT-бар КЛЮЧ, https://vk.com/event69759919
Видео с доклада: https://www.youtube.com/watch?v=pyAYbbDJjPo
Microsoft Edge и платформа веб-приложений в Windows 10 / Константин Кичинский...Ontico
Microsoft Edge -- новый браузер от Microsoft с новым движком и новым интерфейсом.
Какие цели преследует Microsoft, и что это нововведение означает для веб-разработчиков?
Что нового в движке браузера по сравнению с IE, и как он будет развиваться дальше?
Движок Edge внутри Windows 10: хостинг сайтов внутри приложений и доступ к нативной функциональности.
Дорожная карта: к чему и когда готовиться?
Как мы разрабатываем новый фронтенд / Филипп Нехаев (Tinkoff.ru)Ontico
Недавно запустили новый сайт Тинькофф.
У нас есть желание поделиться с аудиторией подходом и опытом разработки большого изоморфного приложения на React.js и Flux. Меньше чем за год мы разработали новый сайт и интернет-банк, заложив платформу на ближайшие несколько лет для быстрой разработки фронтенда новых продуктов.
Сейчас tinkoff.ru насчитывает более 3000 компонентов и сотни страниц.
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Построение собственного JS SDK — зачем и как?buranLcme
Многие разработчики любят делать свои велосипеды, но не все задумываются зачем. Мы расскажем о том, зачем вам может понадобится собственный JavaScript SDK и полезно ли кататься на велосипедах.
Мы делали собственный JS SDK для того, чтобы дать возможность создания плагинов в рамках большой enterprise системы - <b>Parallels Automation</b> и <b>Plesk Panel</b>. Сам SDK является частью общего стандарта <b>APS</b>, который является шиной, объединяющей все наши продукты по автоматизации. Обе панели брендируются и мы должны были сохранить брендинг при уже существующей кодовой базе верстки и существующих правилах оформления. И главное - надо было дать возможность создания UI сторонним девелоперам, которые могут иметь абсолютно разный уровень - от пришедших бекэндеров до профессиональных js-разработчиков.
Как взаимодействовать с графическими дизайнерами: готовим UI Kit / Артем Моло...Ontico
Frontend-разработчики и веб-дизайнеры решают совместную задачу – чтобы пользователь получил лучший user experience. Но часто смотрят на проблему с разных позиций — либо наилучшего технического решения проблемы, либо художественного видения мира. Различие инженерных и художественных подходов нередко приводит к конфликту интересов и снижает эффективность работы команды. Однако поле битвы мировоззрений можно превратить в совместное рабочее пространство. В качестве основного подхода к поиску оптимального процесса создания и сопровождения визуального стиля веб-сайта рассматривается подготовка User Interface Kit (или UI Kit). UI Kit содержит элементы, которые служат кирпичами при построении единообразного интерфейса корпоративных веб-сайтов.
Из предлагаемого доклада слушатели смогут узнать следующее:
– какие плюсы предоставляет декомпозиция дизайна;
– что такое UI Kit и какими свойствами он обладает;
– почему работа с UI Kit понравится и разработчикам, и дизайнерам, и даже менеджеру проекта;
– как можно реализовать UI Kit и организовать его хранение.
Горячко Дмитрий, Солигорск. Организатор конференции Solit. JazzTeam, Founder & CEO. Ведёт блог на http://www.zmicer.com
«Scrum/Agile для команд разного уровня: students, juniors, engineers, seniors, experts. Практические наблюдения и рекомендации». Development секция.
«Создание продукта для автоматизации тестировании. Что нужно учитывать, чтобы создать технологическую платформу. Разбор конкретного примера – продукта XML2Selenium». Development секция.
Javascript-фреймворки: должен остаться только один / Аверин Сергей (Acronis)Ontico
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Использование компонентного подхода это тяжеловесно, медленно, не гибко. Так ли это?
Доклад с фестиваля 404, Самара, 13 октября 2013
Видео: https://www.youtube.com/watch?v=QpZy0WW0Ig4
Инструменты разные нужны, инструменты разные важныRoman Dvornov
В мире фронтенда уже существует большое количество инструментов: как браузерных, так и консольных. Но достаточно ли этих инструментов? Мне кажется, что нет. Веб-приложения становятся все больше и сложнее, и многое остается вне нашего поля зрения. Потому фреймворки и приложения должны предоставлять дополнительные инструменты, упрощающие разработку и улучшающие понимание того, что же происходит у них там — «под капотом». В ходе доклада я расскажу о таких инструментах: какими они могут быть, какие задачи могут решать, что необходимо для их создания.
CodeFest, Новосибирск, 28 марта 2015
http://www.youtube.com/watch?v=HMTc3DERw5c
SWD Page Recorder: Записывает PageObject'ы со скоростью ниндзя SeleniumCamp 2014Dmytro Zharii
Демонстрация работы инструмента записи веб-элементов PageObject для Selenium WebDriver при помощи SWD Page Recorder. Демонстрация работы фреймворка SWD Starter Kit
Читабельные отчеты для автоматизации на C# / Gallio / BDDfyDmytro Zharii
Мой доклад про создание читабельных отчетов для автоматизации тестирования на .NET/C# + Webdriver + Gallio Icarus/MbUnit + BDDfy
Доклад был сделан специально для онлайн конференции Auto ConfeT&QA, прошедшей в октябре 2012 года.
http://confetqa.ru/
======================================
См. также:
Gallio Icarus:
http://gallio.org
BDDfy – фреймворк для БыДиДификации кода :)
Страница проекта на Github:
http://teststack.github.com/TestStack.BDDfy/
Описание на английском:
http://www.mehdi-khalili.com/bddify-in-action/introduction
Александр Баумгертнер — Преимущества БЭМ для небольших проектов и компанийYandex
БЭМ хорош не только для крупных проектов и больших команд. БЭМ — не про именование CSS-классов и i-bem. Он вполне подходит для прототипирования. В докладе пойдет речь о библиотеке для создания основных блоков (форма регистрации, список новостей и статей, категория товаров, карточка товара, форма заказа и т.д.), сборке статичной html-версии сайта и практике разработки.
Субъективная точка зрения на фронтенд разработку.
Площадка: IT-бар КЛЮЧ, https://vk.com/event69759919
Видео с доклада: https://www.youtube.com/watch?v=pyAYbbDJjPo
Microsoft Edge и платформа веб-приложений в Windows 10 / Константин Кичинский...Ontico
Microsoft Edge -- новый браузер от Microsoft с новым движком и новым интерфейсом.
Какие цели преследует Microsoft, и что это нововведение означает для веб-разработчиков?
Что нового в движке браузера по сравнению с IE, и как он будет развиваться дальше?
Движок Edge внутри Windows 10: хостинг сайтов внутри приложений и доступ к нативной функциональности.
Дорожная карта: к чему и когда готовиться?
Как мы разрабатываем новый фронтенд / Филипп Нехаев (Tinkoff.ru)Ontico
Недавно запустили новый сайт Тинькофф.
У нас есть желание поделиться с аудиторией подходом и опытом разработки большого изоморфного приложения на React.js и Flux. Меньше чем за год мы разработали новый сайт и интернет-банк, заложив платформу на ближайшие несколько лет для быстрой разработки фронтенда новых продуктов.
Сейчас tinkoff.ru насчитывает более 3000 компонентов и сотни страниц.
http://techtalks.nsu.ru
Видеозапись: http://www.youtube.com/watch?v=9sWD3RBwz30
23 сентября 2014. Проходим тест Джоэла (Семён Факторович и Олег Годовых, Noveo)
«Вот уже 14 лет как Джоэл Спольски придумал свой Joel test, но до сих пор далеко не все компании успешно проходят его. Мы поговорим о самых важных частях этого теста: о сервисах и инфраструктурных инструментах разработки (к ним относятся системы контроля версий, багтрекеры, continuous integration...) Принципы, о которых мы расскажем, одинаково применимы и для крупных компаний, и для стильных молодежных стартапов, и для студенческих курсовых проектов.»
Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете.
Подробности: http://techtalks.nsu.ru
Построение собственного JS SDK — зачем и как?buranLcme
Многие разработчики любят делать свои велосипеды, но не все задумываются зачем. Мы расскажем о том, зачем вам может понадобится собственный JavaScript SDK и полезно ли кататься на велосипедах.
Мы делали собственный JS SDK для того, чтобы дать возможность создания плагинов в рамках большой enterprise системы - <b>Parallels Automation</b> и <b>Plesk Panel</b>. Сам SDK является частью общего стандарта <b>APS</b>, который является шиной, объединяющей все наши продукты по автоматизации. Обе панели брендируются и мы должны были сохранить брендинг при уже существующей кодовой базе верстки и существующих правилах оформления. И главное - надо было дать возможность создания UI сторонним девелоперам, которые могут иметь абсолютно разный уровень - от пришедших бекэндеров до профессиональных js-разработчиков.
Как взаимодействовать с графическими дизайнерами: готовим UI Kit / Артем Моло...Ontico
Frontend-разработчики и веб-дизайнеры решают совместную задачу – чтобы пользователь получил лучший user experience. Но часто смотрят на проблему с разных позиций — либо наилучшего технического решения проблемы, либо художественного видения мира. Различие инженерных и художественных подходов нередко приводит к конфликту интересов и снижает эффективность работы команды. Однако поле битвы мировоззрений можно превратить в совместное рабочее пространство. В качестве основного подхода к поиску оптимального процесса создания и сопровождения визуального стиля веб-сайта рассматривается подготовка User Interface Kit (или UI Kit). UI Kit содержит элементы, которые служат кирпичами при построении единообразного интерфейса корпоративных веб-сайтов.
Из предлагаемого доклада слушатели смогут узнать следующее:
– какие плюсы предоставляет декомпозиция дизайна;
– что такое UI Kit и какими свойствами он обладает;
– почему работа с UI Kit понравится и разработчикам, и дизайнерам, и даже менеджеру проекта;
– как можно реализовать UI Kit и организовать его хранение.
Горячко Дмитрий, Солигорск. Организатор конференции Solit. JazzTeam, Founder & CEO. Ведёт блог на http://www.zmicer.com
«Scrum/Agile для команд разного уровня: students, juniors, engineers, seniors, experts. Практические наблюдения и рекомендации». Development секция.
«Создание продукта для автоматизации тестировании. Что нужно учитывать, чтобы создать технологическую платформу. Разбор конкретного примера – продукта XML2Selenium». Development секция.
Javascript-фреймворки: должен остаться только один / Аверин Сергей (Acronis)Ontico
Рассказ от tech-менеджера о том, как мы в Acronis выбирали фреймворк в условиях, когда любое более-менее важное технологическое решение сразу затрагивает с десяток команд, несколько сотен человек и права «случайно все сломать» нет.
В докладе пойдет речь о том, что производительность фронтенда — это больше про слаженную работу команды, про понятный и масштабируемый код, чем про сухие циферки. Но циферки тоже будут.
1) Какие у нас были проблемы с текущим фреймворком — UI, архитектура, код.
2) Как измеряли, что примерно стоит брать (исследование популярности).
3) Что рассматривали.
4) На пути к демо-проекту, какие были сложности (то, что уперли идею с Typescript, собственный компилятор шаблонов, четыре Flux-фреймворка и все плохи).
5) Два пилотных демо-проекта: цифры.
6) Оценка трудоемкости перехода.
Использование компонентного подхода это тяжеловесно, медленно, не гибко. Так ли это?
Доклад с фестиваля 404, Самара, 13 октября 2013
Видео: https://www.youtube.com/watch?v=QpZy0WW0Ig4
Как развивать библиотеку компонентов, не ломая ее / Артур Удалов (Mail.Ru Group)Ontico
HighLoad++ 2017
Зал «Пекин + Шанхай», 8 ноября, 17:00
Тезисы:
http://www.highload.ru/2017/abstracts/2991.html
Нынче стало модно выделять UI-компоненты в отдельную библиотеку и использовать её в нескольких проектах. Мы в команде почты Mail.ru делаем так же, но столкнулись с проблемой: каждый разработчик, меняя библиотеку под свои нужды, обязательно ломает что-нибудь, что работало у других.
Я расскажу о том, как мы решили эту проблему, и о том, какие инструменты для этого можно использовать. Storybook, BackstopJS, Jest, Webdriver.io, TypeScript - в их числе.
Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.
D2D Pizza JS Илья Беда "Куда мы все катимся?"Dev2Dev
Окружение JavaScript, наверно, самая быстроразвивающаяся отрасль в мире разработки программного обеспечения. Все слышали шутку про книгу “36 новых JavaScript фреймворков, выпущенных в марте”, и это не далеко от правды.
В своем обзорном докладе я расскажу о своем пути во frontend. О том, как вижу современную индустрию, о существующих проблемах и путях их решения. Все не так уж радужно, как может показаться. Надеюсь, мой доклад позволит вам взглянуть на мир JavaScript с другой стороны или, по крайней мере, задуматься о том, в правильном ли направлении вы движетесь?
Доклад с конференции D2D Pizza JS - http://dev2dev.ru/events/8/
TК°Conf. Организация разработки Frontend. Виталий Слободин.TKConf
Расскажу об организации процесса разработки Frontend в единый конвейер, чтобы увеличить скорость и минимизировать затраты с рисками.
Как организовать верстку макета по фантастичному макету дизайнера при этом не вогнав в когнитивный диссонанс результатом на Bootstrap.
Каким образом объединить воинствующие стороны: Frontend, Backend и дизайнеров.
Юрий Василевский «Автоматизация в XCode»
Yandex Mobile Camp в Санкт-Петербурге 2012
http://events.yandex.ru/events/yamobcamp/spb-may-2012/
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач. Мы обсудим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Yandex Mobile Camp в Санкт-Петербурге, 30 мая 2012
Юрий Василевский, ведущий разработчик EPAM Systems, Mobile Solutions
Тема: Автоматизация в XCode
Тезисы:
Xcode — основной инструментарий разработки приложений под Mac OS X и Apple iOS. Он обладает широкими возможностями как для редактирования кода, так и для автоматизации задач.
Мы рассмотрим некоторые из аспектов автоматизации (Code Sense, Targets, Services, Help), связанные с нумерацией сборок билдов, форматированием и контролем стиля кода, анализом дублированных участков кода, управлением внешними библиотеками.
Микросервисная архитектура на базе CoreOS и KubernetesDenis Izmaylov
13 июля 2016 состоялся восьмой Node.js Meetup в Москве. В этом докладе мы рассмотрели Scale Cube, Docker, CoreOS и кратко Kubernetes и Concourse CI.
В следующем докладе взглянем более подробно на Kubernetes и Concourse CI, посмотрим как с помощью этих быстрых и прекрасных инструментов построить Deployment Automation.
SECON'2017, LAZADA Effartlrss Shopping, Как мы тестируем?SECON
Тестирование заказов в ecommerce международного масштаба/ Order Lifecycle - Жизненный цикл заказа vs QA / Lazada. Азиатская кухня ecommerce тестирования.
2. ПРО ЧТО ДОКЛАД
• Как выбирали новый веб-фреймворк
– Немного о компании
– Бекграунд
– Задача
– Исследование существующего кода
– Выбор на что смотреть
– Техническая оценка вариантов
– Переделка одного из вариантов «под себя»
– Сравнение пилотных проектов
– Оценка затрат на внедрение
2
5. МАСШТАБ
• 5 000 000 пользователей
• 500 000 из них — корпоративные
• 700 сотрудников в 17 разных офисах
• Выпускаем много разного софта:
– коробочный под Windows,
– корпоративный с веб-интерфейсами,
– cloud-продукты с веб-интерфейсом.
5
8. ПРОБЛЕМА
• Много разных технологий для веб-части
• Фронтенд пишут не только JS-разработчики
• Нет возможности подключить к работе верстальщика
• Качество кода сильно отличается
• Текущие технологии устарели
8
10. КУРС
• Толстый клиент на JS/HTML/CSS
• Единая технология во всей компании
• Библиотека UI-компонентов
• Возможность работать разработчикам разных уровней
• Код должен быть понятен backend-разработчикам
10
26. ПОЛЕЗЛИ В КОД ПРИЛОЖЕНИЯ
• Мало комментариев
• Жесткая связность
• Нет границы между Controller и View
26
27. State, BizLogicState, BizLogic State, BizLogic, Ui logic
Model
View
Child View
SubController
SubController2
Child
View
Controller
Server API
М С V
M+CV
27
28. ПОЛЕЗЛИ В КОД ПРИЛОЖЕНИЯ
• Мало комментариев
• Жесткая связность
• Нет границы между Controller и View
• Publish/Subscribe — вроде как правильный паттерн,
но не работает.
28
35. НАСТОЯЩИЕ ВЫВОДЫ
• Очень сложный фреймворк
• Запутаный получившийся код
• Мегабайты кода
• Нельзя подключить обычных верстальщиков
• Виноват ли фреймворк? — частично
35
36. КУДА НАПРАВИТЬ УСИЛИЯ?
• нужен проще UI слой
• менее связная архитектура
• четкое разделение зон отвественности (языков,
технологий)
• больше границ и правил для программистов
• и код, в котором просто разобраться
среднестатистическому разработчику.
36
47. <CUT />: ЧТО НЕ ПОДОШЛО
• Backbone
• Ember
• Knockout
• Dojo
• ExtJS 6
47
48. • Версия 1.*
• Хорошая модульность
• Нет единого стиля разработки
• Трудно дебажить
• Многовато «магии»
• Сложно интегрировать с новыми технологиями
• Код будет несовместим с версией 2.*
48
49. Посмотрели 2.*
• Аж три языка — TypeScript, Javascript и Dart.
• Вот это выглядит как то, что надо.
• Сильно лучше версии 1.*
• Окей, надо разбираться…
49
50. + Понятный data flow
+ Структурность, понятный data flow,
изолированность компонент
+ Когда-то в будущем будет популярным мейн-
стримом
- Собственные шаблоны с кодом
- Все приложение работает как дерево
компонентов, как таковых Controller’ов нет
- Непонятно, когда же оно зарелизится
50
51. + Не фреймворк, а UI-библиотека
+ структурность
+ понятный data flow, изолированность компонент
+ нет какого-то магического синтаксиса (кастомных атрибутов,
фильтров)
+ понятная и простая возможность тюнинга производительности
? и даже серверный рендеринг
51
52. + Архитектура, но не фреймворк
+ one-way data flow, синхронная обработка
+ Как приложение делится на независимые блоки с помощью
денормализации — понятно
+ Единый Event Bus (Dispatcher) и уникальные события — круто.
- Как обеспечивается динамика — непонятно
- Смешение концепций — Store’ы и хранят данные и реализуют
бизнес-логику…
52
53. • Кода от самого Facebook считай, почти нет.
• Посмотрели реальные фреймворки — fluxxor, DeLorean,
ReFlux.js, Este.js:
– уже лучше, но все еще нет динамики
– видно общий прогресс стандартизации в виде ES6, npm-
модулей, изоморфности и т. д.
– с разработкой веб-приложений беда… невозможно,
например, создать два instance’а одного Store’а, чтобы
они не воевали друг с другом.
– нет интернационализации
– нет примеров тестов
53
61. ВЕРНЕМСЯ К ЗАДАЧЕ
• JS-кодеры должны писать код, верстальщики — делать
шаблоны
• Нужен проще UI слой, понятнее архитектура, четкое
разделение (языков, технологий), больше границ, правил и
стандартов.
• На Typescript
• Не являющийся монолитным монстром все-в-одном
61
62. ПОРТИРУЕМ FLUX
• Взяли за основу Flux+React фреймворк Este.js, как наиболее
инновационный.
• Плавно переписывали, пока за три захода от него не осталось
ничего, кроме конфига сборщика.
62
64. 1. STORE’Ы
• Разные зоны ответственности
• Store -> область хранения данных (Store) и отдельно логика
(Controller) (сообразно тому, куда идет развитие Flux)
64
65. State, BizLogicState, BizLogic State, BizLogic, Ui logic
Model
View
Child View
SubController
SubController2
Child
View
Controller
Server API
М С V
Примерно как было
65
66. 66
Ui logicData BizLogic
Isolated block
Isolated block
Isolated block
Child View
Child View
View
Server API
Store
Store
Store
М С V
ViewView
Child View
Child View
Dispatcher
Controller
SubController2
SubController
Action
Примерно как станет
67. 2. JSX
• JSX — это опять мешанина кода и HTML.
• Обратили внимание на wix-react-templates
• Написали свой похожий
67
71. 2. JSX
• Появился TSX
• Второй вариант — ограничить применение кода в шаблонах,
создав свои теги в TSX (это JSX в Typesript)
71
72. 3. ДИНАМИКА
• Нет динамического создания Store’ов и View-компонент.
• Как организовать независимую работу двух одинаковых блоков
на одной странице?
72
74. ПОЛУЧИЛОСЬ:
• Хороший ООП с интерфейсами и дженериками
• С dependency injection
• Только две внешние библиотеки — React и lodash
• Можно поменять что угодно
• С нормальной сборкой
74
76. БИТВА «ПИЛОТОВ»
• Обрезанная копия существующей админки «с нуля»:
– ExtJS 6 + TypeScript
– Flux + React + Typescript
• Сложности:
– анимации
– кастомный скроллбар
– интерфейс меняется для узких экранов
– мобильная версия
– JSON-REST API с авторизацией
76
77. ЦИФРЫ*
ExtJS6 demo Flux+React demo
PRODUCTION BUILD
JS CODE SIZE
1,45 MB 336 KB
PRODUCTION BUILD
CSS CODE SIZE
345 KB 19.9 kB
# OF HTML DOM NODES 841 301
LOAD TIME
(PRODUCTION, NO CACHE)
1.54 s 0,59 s
LOAD TIME
(PRODUCTION, CACHE)
1.42 s 0,58 s
TIME UNTIL FIRST API REQUEST 0,405 s 0,168 s
JS INIT TIME (GOOGLE CHROME) 0,345 s 0,158 s
PRODUCTION BUILD MEMORY USAGE
(GOOGLE CHROME)
24.2 Mb 11.8 Mb
* В реальном проекте разница в объемах кода и скорости
инициализации будет меньше
77
78. ПЛАНЫ
• Изучаем 2.0 beta
• Запиливаем первый боевой мини-проект, выбираем, что
лучше
78
80. ТЕХНОЛОГИЯ МИГРАЦИИ
• Варианты:
– Новые проекты пишем на новом стеке.
– Старый код не трогаем, новый встраиваем целыми
страницами, как iframe.
– При модификации старого кода — или правь, как есть,
или портируй.
80