С тех пор как JS пришел на сервер, мы фронты давно уже пишем собственные сервера под себя, используя тот или иной серверный фреймворк. Паттерн middleware де-факто стал стандартом для таких серверов. Кэп очевидность подсказывает, что слепое доверие может дорого обойтись в итоге.

Поговорим о нюансах работы middleware сервера с использованием одного из популярнейших фреймворков. К каким проблема мы можем придти. Как можем их выявить и решить.

Тезисы:
1. Обзор одежды как способ самовыражения программистов в разные времена: советские инженеры, силиконовая долина, индийский шик
2. Рассказ о проекте под кодовым названии Гардеробот и аналогов, которые используя машинное обучение подбирает индивидуальный стиль в одежде
3. Ревью модных домов, использующих IT технологии
4. Мода во мне - мешает или помогает вести бизнес синяя борода

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

В докладе я расскажу об SPA архитектуре на примере создания собственной административной панели, заработавшей на GitHub 2000 звезд. Мы разберем как расширить интерфейс и логику фронтенда за счет Web Components и создать визуальный конструктор интерфейса.

Также вы выступлении я расскажу о безопасности между веб-сервисом и пользователем. Вместе с участниками конференции разберем, как выполнять сложную бизнес-логику на стороне веб-сервиса.

Техническая сторона разработки проектов, решающих следующие бизнес задачи:
- Как с помощью технологий и виртуальной реальности решить проблемы обучения персонала?
- Повысить продажи и уровень лояльности к компании?
- Отточить навыки действий при ЧП на производстве?
- Сэкономить на презентационных материалах?
Специфика решения данных задач, подводные камни и пр.

Мы - студия дизайна MAX. Наш арт-директор Максим ведущим дизайнером в Яндексе перерисовал поисковую выдачу, Почту, Календарь и Яндекс Музыку, работал в Ленте.ру и тд. А полтора года назад основал свою студию, собрал людей, которым не все равно на дизайн, которые хотят всех заткнуть за пояс и могут создавать удобные и красивые сайты.

Мы расскажем в докладе про редизайн ВкусВилла с самого начала (как взяли заказ), про процесс (почему от нас хотели отказаться) и про запуск (почему запустили неполный комплект наработок, как их распилили на частички, чем руководствовались).

Что еще мы делаем прямо сейчас:

— для QIWI банка делаем пятый по счету проект;
— редизайним большой сайт + два приложения + печатку ВкусВиллу (уже выпустили бету https://new.vkusvill.ru);
— помогаем Яндекс.Драйву с рекламой;
— делаем фильтрам для воды Барьер приложение;
— работаем с Локалс;
— подписываем договор с Кофикс и Дождем;
— работаем с Америкой (стартами из «долины»);
— со Шведами и с другими менее известными ребятами.

Полтора года назад этих клиентов у нас не было:)


Портфолио можно посмотреть по ссылке:

https://medium.com/@maxdesign/%D0%BF%D0%BE%D1%80%D1%82%D1%84%D0%BE%D0%BB%D0%B8%D0%BE-85be083f224f (также есть видео-отзывы от Локалс, QIWI и ВкусВилл).

А тут отдельная подборка по приложениям: http://m-a-x.design/apps

Мажорный upgrade PostgreSQL, довольно часто эта фраза вызывает страх и боязнь предстоящей работы. На самом деле все не так страшно и мы с вами с этом убедимся в рамках мастер класса, сделав upgrade работающей базы данных под нагрузкой. Параллельно акцентируем внимание на проблемных местах, которые могут нам подпортить выполнение этой процедуры. Увидим, что получить новый функционал, которые несут свежие версии кода довольно просто. Оценим затраты времени на разные варианты мажорного upgrade, с простоем базы данных на запись и без простоя.

Расскажу о работе дизайнера в связке с фронтендером при создании приложения на React, в том числе затрону следующие темы:
- Подготовка дизайна мобильных приложений для "фронта" на ReactNative
- Трудности, которые возникают при общении между дизайнером и фронтендером
- Android и iOS – 2 разных дизайна?
- Как сделать так, чтобы фронтендер не "сжог" твой дизайн

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

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

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

в разработке

Участники выступления обсудят два блока тем:

1. О вопросах корпоративного оформления бизнес-проекта в России, иностранных юрисдикциях, экономических и налоговых выгодах и рисках расскажет партнер Международной юридической фирмы GRATA International, управляющий партнер Адвокатского бюро RBL Дмитрий Самигуллин.

2. Оформление интеллектуальных прав на ПО в России и в зарубежных юрисдикциях; как оформить отношения между компанией и ее сотрудниками для предотвращения краж создаваемых IT-решений и ПО; вопросы установления режима коммерческой тайны и оформления ноу-хау. Спикер - руководитель практики интеллектуальной собственности Адвокатского бюро RBL Владислав Симон.

Дмитрий Самигуллин - адвокат, к.ю.н., управляющий партнер Адвокатского бюро RBL, партнер международной юридической фирмы GRATA International. Аттестованный налоговый консультант, сертифицированный медиатор, член International Bar Association, член Российской Палаты налоговых консультантов, член Ассоциации юристов России.

Владислав Симон - руководитель практики интеллектуальной собственности Адвокатского бюро RBL, магистр права, член ассоциации юристов России. Прошел обучение в Российской государственной академии интеллектуальной собственности по направлению "Правовая охрана и защита интеллектуальной собственности". Спикер LF LIVE 2018 в рамках Петербургского Международного Юридического Форума, участник Патентной школы Skolkovo.

Слушатель получит практический гайд по приоритизации тест-кейсов на примере мобильного приложения.
Первичные факторы, влияющие на приоритет кейсов: критичность проверяемого функционала и то, насколько часто пользователь сталкивается с кейсом.

Дополнительно учитывается большое количество факторов, которые могут повысить или понизить приоритет кейса.

Пример фактора, повышающего приоритет кейса: насколько трагичны будут последствия для пользователя, если данный кейс не отработает корректно?
Пример фактора, понижающего приоритет: возможность совершить данное действие неочевидна для пользователя.

Прогрессивные веб-приложения уже получили действительно широкую известность и признание всеми вовлеченными сторонами: разработчиками браузеров (наконец, всеми!), разработчиками, пользователями. Разработчикам приложений на Angular повезло: существуют как минимум два отличных варианта для автоматизации основных функций PWA: "нативный" Angular Service Worker и библиотека Workbox.

Оба подхода надежны, удобны и по-своему уникальны! Давайте рассмотрим основные функции PWA, реализованные с использованием NGSW и Workbox, чтобы после доклада вы смогли сами выбрать вариант, с которого проще начать, который проще использовать и удобнее поддерживать.

Доклад состоит из набора рецептов по оптимизации вашего приложения, разделенных на две группы:

Работа с сетью
- Production mode
- Lazy loading
- Service worker
- Server-side rendering

Выполнение кода
- Использование pure pipes
- Стратегия обнаружения изменений OnPush
- Собственная стратегия обнаружения изменений
- Использование trackBy

Войти в АйТи хотят все, писать код могут многие, а вот писать хороший код - далеко не все. Давайте поговорим о качестве кода, как его писать, чтобы следующий разработчик тебя не проклял.
Качество кода, его масштабируемость и читабельность - это ключевые навыки разработчика, которые отличают его от обезьянки. Как достичь дзена и зачем всё это нужно.

В последнее время я и мои коллеги всё чаще сталкиваемся с этим синдромом. Это - коварная гадость, которая может пустить всё под откос. И хочется поговорить о том, как этого избежать или избавится от этого.

Есть распространённое мнение, что фронтендерам не нужно знать основ программирования (алгоритмы, структуры данных, паттерны проектирования и тд), потому что можно работать и так.
Я считаю, что это неверное мнение. Хорошему разработчику полезно обладать этими фундаментальными знаниями.

Докажу на примерах, что знание основ помогают разработчику. Это позволяет осознанно выбирать инструменты для работы, писать хороший код, делать программы более эффективными, а ещё это позволяет значительно расширить карьерные возможности.

Новички боятся, что это не их сфера, вдруг что-то не получится. Но правда в том, что научиться программировать может каждый. Дам советы, как это делать эффективно: как изучать новые темы, как разбираться в куче информации.
Расскажу, почему допускать ошибки нормально, расскажу, как учатся нейросети (спойлер, так же как люди, через ошибки), дам советы, как извлекать опыт из ошибок и прокачиваться.
На примере игры, покажу как придумывать план решения, когда встречаешься со сложной задачей.
Дам советы, как придумывать задачи для практики самостоятельно и как оборачивать свои страхи в практику и пользу

Новичкам хорошо, их много учат, им дают много материала. Но почему после обучения не все из них не становятся разработчиками? Даже те, кто показывает неплохой уровень вёрстки. Они не умеют работать в команде, в режиме дедалйнов, не переваривают правки. Они никогда не работали в среде, которая прокачивает все эти необходимые навыки. Как и зачем мы это делаем, и почему для новичков это необходимо?