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

Затронем ряд не связанных между собой тем, которые должен (или нет) решать fullstack разработчик:

- CORS политики безопасности и на чьей стороне их настраивать
- HTTP протокол, как бегают данные Frontend Backend, балансировка
- Кто и как определяет формат обмена данными Frontend Backend
- Свой CI/CD внутри команды или это к админам?
- Логирование в проекте (админы говорят писать все в stdout)
- Docker для локальной разработки (осознанный выбор или навязали?)
- Вглубь или вширь
- Планирование нагрузки на сервер
- Стоит ли разделять зоны отвественности

Как организовать тестирование, чтобы выпускать действительно качественные продукты.
1. Недооцененность тестирования
2. Минимальные стандарты и регламенты тестирования
3. Инструменты и системы управления
4. Документирование. Зачем и почему важно?
5. Почему тестирование должно быть независимым?

• Цифровое повышение организационной эффективности бизнеса
• Цифровая трансформация: Платформы и системы для организации удаленной работы сотрудников.
• Особенности сбора и управления гибкими распределенными командами
• human cloud решения для работы с фрилансерами в гибких командах.

Как получить первые заказы и деньги еще на этапе идеи, будь-то создание видеоигры, софта или железки. Разберемся, как в этом может помочь краудфандинг?

По шагам разберем неуспешные и успешные краудфандинговые кампании. Узнаем, почему у одних заказы льются бесконечным потоком, а у других - нет. И как так получается, что люди готовы давать деньги, когда у нас только голая идея?

На встрече узнаем о краудфандинг платформах здесь и за рубежом, а также разберемся в отличиях между ними. Узнаем и какие простые шаги требуется для подготовки и запуска кампании и повышения шансов на сбор. И что сделать, чтобы кампания завершилась успешно.

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

Будут не только кейсы техно-стартапов с миллионными сборами, но и классического бизнеса: кафе и ресторанов, книгоиздания, анимации, кино, музыки, настолок и образования.

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

Лучшие 3 идеи получат персональный бесплатный практический разбор от меня.

Поведаю на примере нашей команды, какими способами мы растили технологический стек и как это помогло ускорить время на разработку CPI/CTR прототипов в три раза.

Research&Development является неотъемлемой частью процесса создания компьютерных игр. Но каждой ли игровой студии нужна отдельная команда для такого рода деятельности, в отрыве от основной разработки?
Определив для себя "окупаемость" как один из главных критериев существования R&D отдела, мы собрали команду из пяти человек и приступили к прототипированию гиперказуальных игр.
В докладе я расскажу, как мы пришли к первому хиту за первые полгода и что представляем из себя спустя 30 прототипов за год существования.

Сейчас отовсюду говорят про BigData. И действительно, в компаниях много данных, но по-прежнему мало инсайтов. Инженерная сложность BI-решений ограничивает доступность данных: данные в сложных BI-системах доступны только “элите” – аналитикам и data-scientist’ам. И недоступны людям, которые должны принимать решения на основе данных – продакт-менеджерам, маркетологам, финансистам.

Зачастую люди, принимающие конкретные проектные решения, не знают, какие данные доступны в принципе и поэтому по-прежнему принимают бизнес-решения интуитивно.

В Эвоторе мы видим задачу команды аналитиков не только в том, чтобы готовить отчеты по запросу бизнеса, но и в том, чтобы создавать для бизнес-пользователей такую среду, в которой данные были бы доступны без необходимости писать sql, в которой с данными было бы легко работать – сама среда помогала бы отвечать на вопросы и получать бизнес-инсайты.

В докладе расскажу, как мы в течение года строили в Эвоторе аналитику, доступную для бизнес-пользователей:
– Как устроен технический стек (DWH, ETL-инструменты)
– Как концептуально структурирована работа с данными
– Как устроена подготовка отчетов и дашбордов для бизнес-пользователей
– Как бизнес-пользователи могут самостоятельно, не обращаясь к команде аналитиков, получать ответы на свои вопросы по данным.

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

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

Гиперказуальные игры это нечто большее чем просто "убить время на 5 минут". Вместе с тобой, мы разберем какие сильные стороны можно развить занимаясь ими и как они помогут тебе стать куда более крутым создателем игр и продуктов.

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

Больше 10 лет прошло с момента первой легендарной конференции DevOps Days в Генте. За это время в мире появилось с несколько дюжин различных коллабораций с Ops-спецами, начиная с класических DevSecOps-ов, заканчивая диковинными HugOps-ами.

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

Одним из центральных требований во время разработки Match-3 игры "Storyngton Hall" было создание детерминированного стабильного ядра с возможностью записи и воспроизведения сессий игроков. В докладе мы расскажем, как этого получилось добиться, какие были трудности и что получилось в итоге.

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

Шейдеры не так страшны как о них думают. В целом вообще не страшны. Ушла та эпоха когда мы не могли запустить Prince of Persia на старой видео карте. Теперь мир шейдеров открыт и прекрасен для разработчиков

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

"Подождите, с этими командами мы ещё не работали, общая культура организации ещё пока что, кхм, не максимально развитая – тогда почему ребята из этих команд так ускорились по сбору обратной связи, постоянно просят фидбэка и потом делают улучшения по мотивам? Перестали говорить про "соответствие ТЗ", говорят про цепочку поставки ценности? Переиспользуют лучшие практики из соседних команд и из индустрии? WTF?"

Некоторое время назад я столкнулся с такими "спонтанными" всходами инженерной культуры и тоже насторожился. Стал разбираться: выяснилось, что, да, влияние внешней среды; да, ребята молодцы; но было кое-что ещё.

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

Стал смотреть на кейсы из разных компаний и увидел тенденцию: активность в девреле коррелировала с развитием инженерной культуры. Были исключения, но они хорошо вписались в модель, подтвердили правило.

Как деврел влияет на инженерной культуры и как провернуть нечто подобное у себя в компании – расскажу в докладе.

Управление State'ом и State Manager'ы может показаться вам скучной и избитой темой. Столько докладов и статей уже вышло по данному направлению. Но, на мой взгляд, все эти доклады и статьи были разобраны на простых примерах. В рабочем проекте мне надо было решить задачу максимальной независимости модулей приложения и их максимальной кастомизации. Но при этом приложение не должно быть сложным и громоздким по кодовой базе. При решении этой задачи я понял, что сформулировал новое определение "Семантический составной ключ", а также методику использования таких ключей с минимальным написанием кода для простого управления и прогнозируемого поведения как каждого отдельного модуля, так и всего приложения в целом. Об этом я и хочу вам рассказать в своем докладе. P.S. доклад будет не о самих менеджерах состояний)

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

Расскажу про новый стек технологий от Unity — Data Oriented Technical Stack, и расскажу, как мы применяем это в реальном проекте. Вкратце расскажу про совмещение старого и нового подходов

Пандемия, увольнения, заморозка проектов. Фразы, которые приводят в ужас каждого. Доклад о личном опыте участия в технических интервью backend разработчиков с двух сторон баррикад.

В докладе будет:
- структуры интервью
- лучшие и нелепые вопросы
- подводные камни и фишки как их распознать

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

Как изменился рынок труда в 2020 году? Как изменился процесс найма сотрудников и что делать чтобы оставаться эффективными? Что допустимо делать на современном рынке, а что делать категорически нельзя?

Поговорим о том, как действовать в условиях высокой конкуренции и адаптировать процесс найма.

Система лояльности как способ удержания и вовлечения IT сотрудников.
Зачем компании нужны лояльные сотрудники? Основа процветания – это лояльные сотрудники в сочетании с грамотным менеджментом, правильной маркетинговой стратегией и достойными услугами.

2020 год был особым для всех, и Progressive Web Apps не исключение. Что касается инноваций в области PWA, 2020 год был самым ленивым за последние пять лет.
В рамках моего доклада мы обсудим такие вещи как: текущий статус, доля рынка, новинки, чего не хватает для полноценной работы, а также новые задачи и возможности.
Вспомним про Microsoft. Казалось бы, причём тут Тим Кук? Project Fugu - как “рыба твоей мечты”. Остановимся на больших игроках рынка, которые уже сейчас применяют PWA в своих продуктах. Новые возможности или секьюрность - когда не хочется выбирать. Разберемся в вышеупомянутом и поразмыслим, может ли PWA быть достойным конкурентом нативным приложениям.

● Что с обещанными магазинами приложений?
○ Какова рыночная доля PWA
○ А всё-таки, как насчет PWA в магазинах?
○ О чём говорят цифры
● Текущее совместимость с платформами
○ Совместимость в процентах
○ Изменения за 2020
● PWA уже в твоём телефоне прямо сейчас
○ Немного PWA которые появились в 2020
○ QR коды
● Новые возможности
○ Изменения свойства отображения
○ Обнаружение WebAPK
○ Инновация Microsoft Edge
○ Trusted Web Activity
○ Fugu Project
○ FaceID и TouchID
○ Доступ к камере на iOS и Side by Side на iPad

● Чего мы лишились за год
○ Триггеры установки PWA
○ Geolocation on iOS 14
○ Ленивый подход в WebKit
● Назревает раскол
● Чего ожидать в 2021
○ Новые возможные платформы
○ Эволюция PWA
○ Firefox снижает приоритетность PWA
○ Изменения при установке браузера PWA
○ Возможности
● Вызов перед платформой в 2021

Сердцем любой информационной системы является СУБД. Повышение требований безопасности почти всегда негативно отражается на её производительности. В нашем докладе на основе форка одной из самых популярных и открытых СУБД в мире мы посмотрим, на сколько происходит деградация производительности и сколько теряет Заказчик, вынужденный удовлетворять требованиям государственных и промышленных стандартов безопасности.

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

Занимаясь разработкой сложных информационных систем преимущественно для государственных структур в странах ЕАЭС, мы не раз сталкивались с трудностями в реализации CI/CD процессов. Вычислительные ресурсы, предоставляемые заказчиком для целей разработки и тестирования зачастую администрируются его штатными специалистами, что создает дополнительные сложности при развертывании программных компонентов. Если в процессе разработки у вас возникает необходимость обновлять версии программных модулей на серверах заказчика несколько раз в день, то это может стать реальной проблемой на пути ваших CI/CD процессов. Системные администраторы заказчика не горят желанием менять свои привычные методы работы, пытаются показать свою значимость и временами буквально саботируют жизненно важные активности. Все эти моменты привели нас в конечном счет к понимаю того, что эффективность наших CI/CD процессов не должна зависеть от сторонних исполнителей, которые не заинтересованы в сокращении временных издержек, возникающих при развертывании компонентов разрабатываемого ПО, а также тестовых сред. Мы создали простой и эффективный инструмент для наших разработчиков, и теперь CI/CD у нас работает как часы. С помощью контейнерной платформы Imagenarium можно легко и быстро развернуть любое количество сред в нужной конфигурации, и это не требует глубоких познаний в системном администрировании и управлении кластерными средами.
В докладе мы поделимся практическим опытом автоматизации CI/CD процессов, который мы приобрели в ходе выполнения наших проектов.

Разработка современных высоконагруженных информационных систем на основе микросервисов требует применения соответствующих технологий кластеризации, масштабирования и обеспечения отказоустойчивости. Однако, нередко в процессе создания и отладки кода разработчики сознательно идут на упрощение тестовых окружений, так как воспроизвести, так называемую, prod-like среду, в которой разрабатываемый код выполнялся бы в условиях приближенных к промышленной эксплуатации, довольно сложно и затратно. Для это требуются и дополнительные вычислительные мощности и помощь DevOps-инженеров, которые отвечают за процессы развертывания ПО в целевой среде. Однако, есть способ ускорить и автоматизировать процессы развертывания разрабатываемых программных компонентов в сложной кластерной среде. Более того, есть возможность дать разработчикам простой и понятный инструмент для управления процессами развертывания как в локальной тестовой среде, так и в различных технологических окружениях (dev, integration, pre-prod, hotfix). Что характерно, для этого необязательно выстраивать обескураживающие по своей сложности, системы на базе Kubernetes, а вполне можно обойтись средствами компактного оркестратора Docker Swarm с некоторыми доработками, существенно упрощающими жизнь разработчиков сложных кластерных систем.
В докладе мы расскажем о нашем собственном опыте использования Docker Swarm в процессах разработки, тестирования и эксплуатации систем. А также о том, как из простого оркестратора извлечь максимум пользы и научить его решать сложные задачи.

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

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

И в каждом таком случае неизбежно происходил момент, когда на продакшене появлялись самые первые баги от команды. Мы били тревогу, будили коллег ночью, откатывались, чинили.

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

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

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

Рассмотрим основные причины, которые влияют на "успеваемость" команды тестирования, разберемся почему можно не уложиться в заявленные сроки и/или почему команда вынуждена овертаймить, чтобы исправить ситуацию. Разберемся, какие риски чаще всего забывают учесть при планировании и как выстроить планирование, чтобы уложиться в сроки.

GraphQL — прекрасная технология, созданная для облегчения жизни наших разработчиков и ускорения работы проектов. Но, как и любая технология, её нужно "правильно готовить". К сожалению, многие разработчики, в формате Hypen Driven Development, подключают GraphQL в проект и сначала испытывают восторг.

Спустя некоторое время GraphQL может стать реальной головной болью проекта и в своем докладе я расскажу вам пару слов о хороших новостях, которые приходят с GraphQL, но больше мы поговорим о его слабых сторонах, предусмотрев которые, можно принять более взвешенное решение об использовании данной технологии в проекте.

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

В компании мы занимаемся разработкой продуктов и сервисов для мобильных операторов: от возникновения идеи до сопровождения. Каждый такой проект — результат работы людей из одной или нескольких автономных групп. Это разные люди из самых разных мест: наши офисы работают в трёх городах, а более 25% сотрудников — удалёнщики от Хабаровска до Барселоны.

С ростом штата мы заметили как важно уделять внимание внутренним коммуникациям. Если не обмениваться знаниями друг с другом, то порой страдают процессы и проекты. Например, нередки случаи, когда одна команда решает задачу, успешно решённую ранее соседней командой, но не даже подозревает об этом.

Для преодоления таких барьеров, мы с 2015 года проводим внутренние митапы. Слушателям они позволяют учиться новому и постоянно расширять свой кругозор. Спикерам помогают потренировать soft skills, делиться опытом, ещё лучше разобраться в теме или заявить о себе. Компании — снизить издержки из-за несогласованности внутри себя.

Сейчас мы регулярно проводим внутренние митапы и уже успели сделать несколько публичных. За пять лет мы собрали докладный комитет из инициативных ребят и помогаем спикерам с их выступлениями. Учим формулировать тему, помогаем со слайдами, рисуем дизайн, проводим редактуру текстов, составляем расписание, пишем анонсы, рисуем обложки, делаем трансляции, монтируем видео и даём обратную связь.

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

Надеюсь, что мой доклад поможет менеджерам, HR и руководителям применить наш опыт в своих компаниях.

В FunBox мы поддерживаем несколько сотен сервисов и находимся в постоянной борьбе с повторением одного и того же в разных проектах.

В докладе расскажу о двух типах причин появления бойлерплейта.

+ Прямое дублирование: дублирование служебного кода, стилей, элементов интерфейса, бизнес-логики.

+ Менее заметное косвенное дублирование: зависимость от конкретных интерфейсов внешних библиотек, метадействия с проектами.

Проведу сравнение разных подходов к борьбе с бойлерплейтом:

Скаффолдинг
Библиотеки
Сервисы
Предложу и объясню на примерах советы по правильному использованию этих подходов:

Следование принципам SOLID (конкретно, Interface Segregation и Inversion of Control).
Следование правилу зависимости от более абстрактных и менее конкретных компонентов.
Создание вспомогательной базы сервисов для борьбы с дублированием.

Как-то раз я написал тред про рекрутеров (https://twitter.com/M0rtyMerr/status/1226787133605711872?s=20). Кичливый и максималистский он выполнил свою задачу, привлёк внимание IT комьюнити к нерешенным проблемам найма. Ведь поиск новой работы в нашей области редко бывает приятным процессом, и это хочется исправить.
В докладе я рассматриваю частые ошибки рекрутеров, собранные за 26 пройденных собеседований, и предлагаю пути их решения. Про косяки разработчиков тоже не умолчу!

Немного о технологии Progressive Web Application, которое может помочь вашему бизнесу. Может помочь решить проблему с разработкой приложения под iOS, Android, Windows, Linux, MacOS и веб-сайта.

В докладе рассказывается об элементах комической техники, необходимых для полётов на Луну, и их использовании в лунных миссиях. Обсуждаются основные сложности построения лунной транспортной системы, следующие из физических принципов космического полёта. Рассказывается о современных подходах к организации лунных миссий и их отличии от подходов прошлого, включая планы по созданию новой постоянно обитаемой космической станции Gateway и разработке многоразовых систем посадки на Луну. В заключение обсуждаются перспективы добычи на Луне топлива для космических кораблей и использование лунной программы как «испытательного полигона» на пути к Марсу.

Фразы из нашей работы "это не баг а фича"и "это не ко мне" надежно вросли в айтишные анекдоты и отражают сложности взаимодействия в нашей молодой отрасли. Я работаю ручным тестировщиком, поэтому у меня не так много "ручек", чтобы принести пользу бизнесу. Я могу выбирать как и что тестировать, а затем выбирать как о найденном рассказать разработчикам -- которые, конечно же, не упустят возможности заявить, что это не баги, а фичи, и быстро закрыть все баг-репорты. Мой доклад о том, почему так происходит с точки зрения современной нейрофизиологии и что мы, как тестировщики, можем делать, чтобы и софт лучше становился, и отдел разработки не видел в нас смертельных врагов. Практические примеры будут из моей ежедневной работы в Evrone, а вот теоретическая часть о сознании и когнитивных искажениях универсальна и полезна всем, к кому заходит прокрастинация и "не лежит душа" к "скучной" работе.

-

Любой разработчик знает, сколько времени и сил уходит на поиск ошибки в коде, особенно когда это чужой код. Особенно когда он уже в мастере) Если слова "мерж реквест" и "ревью" вызывают у вас нервный тик, а завтрашний релиз - мысли о том, сколько придётся после него просидеть ночью, чтобы исправить все асапы - значит, в ваших процессах явно пора что-то поменять. Вот об этом мы и хотим поговорить. Ключевые слова, которые можно загулить до начала: Docker, SonarQube, Unit tests, Branching Strategies, Release policies

Подробнее в презентации: https://docs.google.com/presentation/d/1kLwfKHl-liKoOKDgbkrEK9zBbmvUR5Kp38Mrm9X6nTs/edit?usp=sharing

Мой доклад в первый день конференции про фундамент нашего сознания. Мы не знаем, как оно работает, но есть интересные гипотезы. Некоторые из которых даже обладают предсказательной силой! В этом докладе я использую предсказательную силу Attention Schema Theory чтобы объяснить механизм работы прокрастинации. Ну а понимание механизма дает возможность придумать разные способы борьбы. Приходите и узнайте что из "500 верных способов победить прокрастинация" может работать, а что - бесполезные благоглупости и труизмы.

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

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

Как развивались технологии в робототехнике, состояние рынка на сегодня и какие существуют тенденции на будущее

В крупных или быстро растущих компаниях доступ к «проду» есть далеко не у всех. Да и с доступом далеко не всегда и не все можно безболезненно проверить. Создание копии “боевой” базы часто занимает часы, и уже после нескольких экспериментов полученная такой ценой копия может стать не пригодной для дальнейшего использования.
Доклад посвящён опыту решения задачи быстрого получения копии полноразмерной БД и инструментам, которые помогут автоматизировать этот процесс.

В докладе расскажу, как предлагается строить хранилища данных «по учебнику», и почему такие предложения не всегда хорошее решение. Расскажу, как организовано DWH в нашем Банке, можно ли сказать, что оно сделано по учебнику. Какие проблемы у нас возникают по дороге к текущему виду нашего хранилища, и как мы их решали. К чему мы идём и какие проблемы возникают в этом походе.

Компилятор TypeScript предоставляет более 90 флагов. 7 из них известны как "strict". 1 предназначен для того, чтобы управлять ими всеми.
В рамках доклада мы пробежимся по всем 7 опциям, разберем, что они должны делать в теории. Рассмотрим код реальных приложений и случаи, когда "strict" режим может спасти нам множество нервных клеток. Поговорим о ковариантности и контрвариантности, как это относится к TypeScript, и почему null наш худший враг.

Как попасть в игр разработку не набрав по дороге микрокредитов. Что делать если не попал, или попал не туда, или вообще прогнали от туда куда попал.

AR/VR, а так же ML активно вторгаются во все сферы нашей жизни. Какие то, более явные, вы можете знать уже сейчас, но о некоторых, могли не слышать. Я хочу поговорить и попытаться раскрыть несколько тем:
- Какие тренды в xR технологиях уже сейчас видны.
- Как VR помогает делать киноиндустрию лучше.
- Почему роботы вряд ли нас смогу захватить.

Интеграция NodeJS в существующую инфраструктуру. Pack, deploy, debug, monitoring. Нюансы и трудности, с которыми мы столкнулись.
Как продать технологию бизнес командам и не бояться за свою жизнь.

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

Я расскажу про подход, который мы используем у себя в компании, ставший простым инструментом. В нём видны узкие места в документировании продуктов и в областях знаний членов команды, и теперь мы можем принимать правильные решения в наполнении пустот и развитии недостающих компетенций. Расскажу, как к этому пришли, и покажу, как пользоваться.

Я выступал на круглом столе Деловой России с 10-минутным докладом про гибкие подходы в финансовых сервисах, но времени раскрыть тему совсем не было, пробежал только по верхам: https://www.finam.ru/about/newsitem/finam-podelilsya-opytom-sozdaniya-it-produktov-20200220-194551/ Хочу развернуть практическую часть, про особенности в организации команд, про нюансы инфраструктуры, про автоматизацию развёртывания и масштабирования, и про любимого регулятора (ЦБ) с которым не скучно :)

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

60 минут — именно столько занимает типичное собеседование. Но часто во время интервью что-то идёт не так. В докладе рассмотрю это «что-то» и расскажу, как можно проводить собеседования, чтобы они не проходили «как-то»

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

В своем докладе я хочу поделиться историей того, как мы начали мигрировать сайт Одноклассников на Реакт, и какие стали появляться с этим проблемы. Покажу странные и порой дикие вещи, и то, как мы с ними начали справляться.

Ты разработчик в большом проекте, в котором много легаси. Но вот наступил счастливый момент, и ты можешь использовать самый современный стек, дня написания своих фич. И кажется, что теперь жизнь будет прекрасной и смузи польется рекой… Но реальность имеет другое мнение на этот счет!

В своем докладе я расскажу, как на примере простой формы авторизации мы огребли кучу проблем, когда переписали её на Реакт. Покажу места, которые привели к этим проблемам, и поделюсь опытом расследования этих проблем.

Эта история весьма поучительна, потому что в крупных системах не всегда так важно, что думает разработчик, потому что последнее слово всегда за пользователем. Об этом мы и поговорим подробно в докладе.

Мы выясним зачем учиться, как это эффективно делать, какие для этого есть методики и инструменты, приправив это все цитатами великих.

1. Количество информации в мире и ее рост
2. Влияние количества новых людей в IT и навыков на рост зарплаты
3. Способы обучения
3.1 В процессе работы
3.2 Университеты
3.3 Онлайн курсы
3.4 Профессиональные сертификации
3.5 Менторинг программы
3.6 Преподавание
4. Как работает обучение
4.1 Принципы работы мозга(Concentrated/Difusion modes)
4.2 Влияние сна на обучение
4.3 Прокрастинация
4.4 Практика
5. Summary

В последнее время, стали часто говорить, что тестировщик - это роль, а не должность, ручные тестировщики не нужны. Перед QA специалистами встаёт нелёгкая задача прокачать инженерные навыки, а перед компаниями как переквалифицировать текущих сотрудников. В докладе расскажу как мы в Авито прошли этот путь, какие факторы должны сложиться для того чтобы всё получилось.

Умеете писать unit тесты? А как на счёт E2E ?

Вэб эволюционирует, тестирование тоже. Быстрое, простое и надежное тестирование для всего, что работает в браузере. Е2Е совсем не страшно. Расскажу и покажу Cypress, как с ним работать, расскажу про плюсы, покажу как развернуть и начать писать тесты. (А потом попросить больше денег у работодателя)

В разработке

Состояние JS в 2020, новые тренды, пробитое дно. Что стоит попробовать, от чего стоит отказаться.
Большинство проектов это монстры застывшие после релиза. Когда вы оптимизировали свой код последний раз? Знаете что такое PWA/TWA? Ваше приложение работает в оффлайне?

Работая на аутсорс - ни разу не было такого что вся команда сидит в одном офисе. Начав лидить такие команды или же при приближении к управлению я взглянул на привычные вещи под новым углом, то - от чего бомбило когда я был рядовым разработчиком стал применять сам, придумывая велосипеды - понимал что всё уже придумано до нас. Стал объяснять это коллегам, решать конфликты иначе. Жалею что не знал этого раньше, надеюсь. Бонусом расскажу как не работать (не то что вы подумали) и как сделать команду эффективнее.

Способы и методики повышения скорости и качества разработки, выходим из каменного века и переходим к продвинутым практикам: storybook, smart/dumb component architecture, cypress и другие. С примерами, факапами и выводами.

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

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

4 года бакалавриата, 2 года магистратуры или 5 лет специалитета. Время потрачено, диплом на руках. Что делать дальше?
Краткое "инженер-программист" в дипломе на самом деле вовсе не обязывает быть именно программистом. Сейчас в IT существует и активно развивается ещё множество направлений, в каждом из которых нужны люди.
Расскажу, куда податься в IT, чтобы чувствовать себя на своём месте и любить свою работу.

Когда я перестал ездить в офис, у меня освободились 2 часа ежедневно. Я решил инвестировать их в студентов онлайн-курсов, изучающих программирование, и стал ментором. Меня затянуло — уже второй год я пишу код сам в основное время, а затем учу этому других. Хочу рассказать:
* Что нужно, чтобы стать ментором, и с чего начать, если вы тоже хотите делиться опытом с новичками
* В чем заключается роль ментора, какие шишки я набил на этом пути
* Сколько денег это проносит и сколько сил и времени требует взамен
* Как я стал ментором в компании и сделал из QA программиста за полгода
* Какие бонусы это дало мне и моим студентам

В апреле 2019 года Марк Цукерберг анонсирровал новый стек Facebook для Front End'а: React + GraphQL + Relay Modern. В этом докладе мы с вами разберем третью составляющую - Relay Modern, фреймворк для разработки высоконагруженных данными клиентских приложений на клиенте:
- возможности и задачи, решаемые фреймворком;
- базовую архитектуру приложения;
- основные строительные блоки.