Мастер-классы
На мастер-классе будет представлен доклад об основных (известных и не очень) угрозах информационной безопасности в веб-приложениях. Чтобы не растекаться мыслью по древу, мы изучим каждый из разделов на практике и разберем несколько реальных задач. Вы узнаете, на что необходимо обращать внимание при тестировании и реализации различной функциональности в веб-приложениях и что может произойти в случае несвоевременного использования тех или иных функций.
Почему стоит использовать пароли по умолчанию? Почему PreparedStatements только усложняют код, а возможность внедрения JavaScript-кода на сайте является фичей? В ходе практического мастер-класса вы узнаете ответы на все перечисленные вопросы.
На практике попробуем накрутить лайков в социальных сетях, украдем криптовалюту и получим доступ к самым большим секретам пользователей. Более того, вы узнаете, что нужно делать, чтобы не допустить подобных случаев в вашем веб-приложении.
Мастер-класс проведут технический директор образовательной платформы Hacktory Иван Юшкевич и ведущий разработчик Hacktory Илья Горячев.
Мастер-класс особенно полезен
Специалистам по информационным технологиям и ИБ, разработчикам, QA-специалистам и системным администраторам.
В программе:
* Современные угрозы: от забытых файлов до проблем с аутентификацией
* Сценарии защиты: что необходимо учитывать на этапе разработки веб-приложения, какие существуют фундаментальные принципы безопасности веб-приложений
* 20/80: теория и дальнейший разбор на конкретных примерах и решение множества задач на практике
Рассмотрим, как разворачивать приложения с помощью Forge на примере облачных серверов Linode. Настроим непрерывный деплой с помощью Envoyer.
По итогу слушатель сможет легко и без боли настроить непрерывный деплой своего PHP-приложения на Envoyer.
«Здравый смысл — это сумма предубеждений, приобретенных до восемнадцатилетнего возраста».
Целостный подход в управлении диктует нам закон, согласно которому изменения в организации не произойдут без изменения культуры, позиций и убеждений людей, а именно эти области меняются медленно, с высоким сопротивлением.
В каких случаях бизнесы сталкиваются с вызовами трансформации культуры:
• Вывод на рынок продуктов с новой бизнес-моделью (цифровых продуктов, сервисные, open source, массовая кастомизация и т.п.).
• Agile-трансформация.
• Цифровая трансформация.
• Управление знаниями.
• DevOps-трансформация.
• Реализация платформенных решений и бизнес-моделей.
Если сегодня у руководителя, отвечающего за трансформацию нет реального опыта работы в B2С, в agile-парадигме, то управлять изменениями, где требуется понимание, что такое agile-мышление, продуктологическое мышление, поток (не цепочка) создания ценности, крайне сложно. Отсюда крайне высокий уровень культа карго, неудач и разочарований.
Разберемся с этим вопросом на схемах, разберем lean-agile-фреймворк, поговорим о том, как системно ускорять изменения в людях, командах и культуре организации. Результатом схватывания новой парадигмы мышления может стать пересмотр своей деятельности, позиции, переход на новый системный уровень.
В недавнем ежегодном опросе State of Javascript 2019 Svelte получил самый высокий рейтинг интереса среди фронтенд-фреймворков, а также премию "Prediction Award" за новейшие технологии.
В рамках данного мастер-класса мы поговорим о новом тренде «исчезающих фреймворков» и о том, как Svelte работает "под капотом". Далее, по шагам, в формате воркшопа напишем небольшое веб-приложение, стараясь затронуть основные аспекты его разработки. К концу мастер-класса вы не только познакомитесь со Svelte, но и почувствуете себя уверенно, чтобы начать создавать приложения с его помощью.
У каждого основателя стартапа должен быть выучен наизусть одноминутный питч. Даже если вы не ищете инвестиции, крайне полезно уметь быстро "продавать" себя потенциальным партнерам, будущим сотрудникам, случайным знакомым в клубе. В идеале вам, конечно, нужны разные питчи для разных аудиторий, но и один универсальный — куда лучше, чем ничего.
На мастер-классе я попробую помочь нескольким проектам довести этот питч до совершенства.
В результате мастер-класса слушатели будут уметь строить карты Шухарта по имеющимся данным и знать, как их применить в своих собственных проектах.
Пирамида тестирования становится нарицательным выражением. Про нее слышали многие, а построить на своих проектах получается не у всех. А все потому, что большинство идет по стратегии "копи-паста" пирамиды, которую некогда популяризировал Мартин Фаулер. В 2012 году. Сейчас 2020. Технологии изменились, подходы к разработке — тоже. Но продолжаем мыслить 3-мя уровня пирамиды тестирования. А еще мы часто забываем о том, что Мартин Фаулер был и, вроде как, и есть бэкенд-разработчик. И автор пирамиды тестирования Майк Кон тоже. Когда они ее придумали, даже SPA еще не было.
В своем докладе я расскажу про то, как построить правильную пирамиду тестирования именно для вашего приложения. На основании расчета стоимости тестов и с учетом построения дерева требований.
Доклад будет адаптирован под фронтенд-разработку, для демонстрации примеров будет использовано тестовое react-приложение. В докладе будет много про построения дерева требований, про расчет, на каком уровне надо проектировать тест, и много про тест-дизайн для разработчиков фронтенда.
Мастер-класс по мотивам доклада с предыдущей FC — "Docker для фронтендера".
Разберёмся в Docker'e и проработаем случаи, в которых он может быть полезен фронтенд-разработчику.
Каждая культура имеет свои особенности, свои положительные стороны и те, которые требуют развития. Сильные IT-компании достигли выдающихся результатов благодаря тому, что постоянно удерживают фокус на профессионализме, так называемых hard skills. Сотрудники таких компаний достигают высокого мастерства, однако то, что называют soft skills, как правило, остается на втором плане, они развиваются медленнее и управлять их развитием сложно. Как следствие, образуются области, требующие внимания:
• повышенный уровень токсичности (как следствие разницы между техническими навыками и личностной зрелостью);
• размывание смыслов работы и потеря вовлеченности;
• искажения в развитии управленческих компетенций и формирование негативных управленческих паттернов.
На мастер-классе мы более детально рассмотрим вопросы Человека в корпоративной культуре, причины и фреймворки индивидуального личностного развития. Предложим технологию форматного коучинга (когда коуч не вникает в личную ситуацию, а только ведет процесс), системной работы со смыслами, уместные форматы психологии бизнеса.
Вы получите материалы рефлективного формата для анализа своей ситуации, собственных ограничивающих убеждений и схемы их преодоления. А также методологию проведения форматного коучинга, позволяющую без существенных затрат времени проводить встречу на развитие.
В теоретической части занятия мы рассмотрим способы сжатия информации, дадим определение префиксного кода, правила создания дерева для кода Хаффмана.
В практической части мы создадим полноценный архиватор, в котором будут написаны алгоритмы подсчёта и хранения частотного словаря, формирования кода Хаффмана и его использование для сжатия и распаковки массива байт.
В конце вебинара мы протестируем работу созданного архиватора на файлах разного типа и сделаем выводы о преимуществах и недостатках префиксного кода Хаффмана.
- В чем минусы классической многопоточности.
- Почему так важен неблокирующий ввод-вывод.
- Что нам даёт асинхронность.
- Какие есть реактивные библиотеки на Java.
- В каких ситуациях нужна реактивность и что она может дать.
- В чем недостатки реактивного подхода.
* Рассмотрим ключевые особенности создания Command Line Interface в Node.js CLI.
* Разберём теорию и аспекты использования NPM и package.json.
* А также посмотрим на реальные примеры CLI-программ на JavaScript и реализуем несколько примеров в разных фреймворках.
* Подведем итог и обзор других инструментов для создания CLI-программ.
Общие принципы:
- Почему Node.js (и другие технологии).
- Примеры — npm, git (package.json).
- Обзор фреймворков (примеры программ).
- Создание CLI с oclif (Конфигурации проекта / Команды, плагины / Аргументы и флаги / Эффекты).
Все мы сходимся на том, что документация — это хорошо и полезно.
Как написать документацию так, чтобы она на самом деле была хорошей и полезной — очень сложный и многогранный вопрос. Чтобы подойти к ответу на него, нужно задуматься о двух вещах: кому мы пишем документацию и зачем мы ее пишем. Другими словами, написание документации (как и любую другую проектную активность) нужно начать с ее целеполагания.
На этом мастер-классе мы поговорим вот о чем:
- С каких сторон нужно изучить вашу проектную ситуацию, чтобы понять, какая документация вам нужна?
- Как идентифицировать читателей документации и понять их нужды?
- Как писать документацию, чтобы она максимально хорошо решала задачи читателей?
- Как писать документацию, чтобы она максимально хорошо решала задачи бизнеса?
В первой части мастер-класса я расскажу, как мы отвечали на эти вопросы в проектах, в которых я участвовал в последние 8-9 лет.
Во второй части мастер-класса мы будем рассматривать проектные ситуации, случавшиеся у вас (т.е. участников мастер-класса) и отвечать на те же самые вопросы, но в ваших реалиях.
За годы своего существования (а это почти 30 лет) язык HTML зарекомендовал себя как исключительно дружелюбный язык, легко осваиваемый новичками. А в сочетании с CSS он позволяет достичь каких-то невероятных высот. Взять, к примеру, игру Mario Kart:CSS, написанную на чистом HTML и CSS.
Однако, есть задачи, с которыми HTML даже в сочетании с CSS пока справиться не может. Что, если бы мы могли писать веб-приложения на языке HTML без привлечения JavaScript? Что, если бы у нас был столь же дружелюбный и простой в изучении инструмент, который позволил расширить возможности HTML и при этом не потерять его сильные стороны чрезмерным усложнением?
И такой инструмент есть. Это Mavo — будущее HTML в настоящем!
Mavo разрабатывается в Массачусетском технологическом институте (MIT) под руководством Лии Веру (Lea Verou). В рамках мастер-класса мы познакомимся с Mavo и на нескольких примерах увидим красоту и мощь этого великолепного инструмента. А также разработаем полноценное интерактивное веб-приложение. Возможно, даже не одно. 😀
Лишь малый процент кандидатов задает встречные вопросы компании. Но ведь выбирают не только работодатели, верно? Рекрутеры умеют как собеседовать кандидатов, так и отбирать компании для себя.
Мы проведем мастер-класс совместно с представителями IT-сообществ (SPb IT Recruiter, SPb SPM, SPb Python, Piter JS и др.). Специалисты из разных специальностей в IT расскажут о своих успешных методах собеседований компаний.
Мы расскажем, что такое мотивация, где ее искать, и как достичь. Дадим инструменты, чтобы, несмотря ни на что, выявить компании:
* с высокими финансовыми с рисками (задержка з/п, распад, сокращения и пр.);
* с несовпадающими по факту задачами/стеком;
* с низким уровнем квалификации коллег и руководства;
* с высоким уровнем конфликтности/стресса;
* с несовпадающими ценностями/видением;
* с неподходящими процессами и др.
Какой вы руководитель? В чем ваша эффективность? Как вы поддерживаете баланс профессионального и личного? Хотите разобраться, где ваша "зона риска" потерять эффективность и как поддерживать баланс? Приходите на мастер-класс и получите набор конкретных техник и практик развития личной эффективности, которые помогут получать удовольствие от жизни и работы, заметить то, что ускользает в потоке быстрых перемен и неопределенности.
Это практический мастер-класс, цель которого — отработать практику и продемонстрировать участникам, как простой фреймворк работает, какие возникают ощущения и инсайты в отношении работы, ответственности и осознанности. Каким образом на системном уровне внедрять практики встреч на развитие ответственности, когда руководитель, не тратя много времени и эмоций на встречу, дает возможность сотруднику сделать индивидуальный шаг в развитии ответственности.
В фокусе — перформанс как сотрудника, так и руководителя. Вы получите алгоритм проведения такой встречи и личный опыт, чтобы снять опасения и увидеть, как это работает.
Мы даем фидбэк каждый день много раз: принимаем работу, которую просили выполнить, от людей, которых выбрали на эту задачу. Что и как вы обычно говорите исполнителю? Слушает ли он вас полностью, ждёт неизбежное "но..." или просит скипнуть булшит и перейти к критике?
Не будет "секретов, фишек и разборов сложных кейсов". Задача этого МК — проверить свой базовый навык фидбэка и убедиться, что эта мышца у вас уже прокачана, или отполировать это искусство до блеска, если что-то потерялось в пути.
Я считаю, что фидбэк должен быть конкретным, полезным, развивающим и мотивирующим. И для этого нужно уметь:
- задавать критерии оценки и говорить фактами;
- определять зоны ближайшего развития и держать баланс;
- развивать сильные стороны, замечать успехи, даже (особенно) если человек сам их игнорирует.
А также понимать, когда мы занимаемся развивающим фидбэком, а когда нужно "вот прям щас получить результат".
На примере приложения доставки продуктов пешими курьерами мы будем декомпозировать систему на микросервисы.
Что станет результатом:
Архитектурное решение в miro
Чему мы научимся:
* Перестанем любые небольшие приложения называть микросервисами.
* Перестанем SOA выдавать за микросервисы.
* Узнаем основной фактор успеха внедрения MSA.
* Определим, сколько сервисов должно быть у одной команды.
* Поймем, является ли фронтенд частью микросервиса.
Мы разберем темы:
* Понятия монолита, SOA, MSA.
* Что на самом деле значит "микро".
* Бизнес-цели и метрики успешного внедрения подхода микросервисов.
* Последствия неправильного разбиения.
* Оптимальный размер микросервиса.
* Разбиение на сервисы по бизнес-возможностям.
* Anti-pattern "распределенный монолит".
* Database per service pattern.
* Избыточность данных.
Краткое содержание:
1. Декомпозиция
Возьмём большую задачу и будем в лайв-режиме её декомпозировать все вместе.
2. Планирование
2а. Оценка задач
Будем оценивать задачи, полученные с помощью декомпозиции в сторипоинтах, используя Планнинг-покер.
2б. Приоритизация
Оценим приоритеты задач.
3. Завершение работы
Выработаем критерии приёмки оцененных и приоритизированных задач.
Ни для кого не секрет, что база данных является узким горлышком высоконагруженной системы. Поэтому большое внимание при проектировании следует уделить именно этой части системы, ведь известно — если вы хотите ускорить эскадру, необходимо ускорить самый медленный корабль. На мастер-классе поговорим про индексы как про инструмент для повышения скорости работы базы данных.
Поймем:
* устройство Btree — индекса в MySQL в движках InnoDB и MyISAM;
* принципы построения планов запросов в MySQL.
Изучим:
* предназначение и механизмы работы кластерных и покрывающих индексов.
Научимся:
* пользоваться командой explain в MySQL;
* строить индексы, позволяющие оптимизировать запросы;
* составлять запросы, позволяющие переиспользовать существующие индексы.
Наблюдаемость (observability) — одно из ключевых свойств современных приложений. Часто под наблюдаемостью понимают факт наличия логов, метрик и трейсинга. Однако, согласно определению, наблюдаемость — это мера того, насколько хорошо мы можем определить текущее состояние системы или любого её компонента. На этом мастер-классе мы поговорим о том, с какими частыми проблемами можно встретиться при разработке приложения, нацеленного на наблюдаемость. В примерах мастер-класса будет использован Go, но показанные практики могут быть применимы и к любому другому языку программирования.
Для кого этот мастер-класс: для начинающих. Идеально подойдет тем, кто уже слышал про логи, метрики и трейсинг, но еще не погрузился в лучшие практики использования этих техник.
Чему научимся:
- Выбирать формат сообщений логов.
- Правильно логировать ошибки, исключения и аварийные ситуации.
- Разбираться в разных типах метрик и принципах их агрегации .
- Понимать проблемы визуализации трейсинга.
Иногда в своей практике мы сталкиваемся с очень странными вопросами: "Найти все реки длиннее k км" или "Найти все города-миллионники"... И вроде где-то ответы должны быть, но как их получить в json?! Например, выгрузить из Wikipedia. У неё есть API, а также специальный язык запросов SPARQL, предназначенный для получения структурированной информации.
Многие быстрорастущие организации используют большие базы данных PostgreSQL. Важно помнить, что здоровье и стабильность production во многом обеспечивается развитыми dev- и test-окружениями. Зачастую качественная подготовка таких окружений требует значительных ресурсов.
К счастью, существует так называемое «тонкое клонирование», которое позволяет очень быстро подготавливать не-production-среды. Более того, такое клонирование не увеличивает бюджеты: на одном компьютере среднего размера с одной физической копией базы данных можно одновременно запускать десятки тонких клонов.
При использовании модели тонкого клонирования даже базы данных объемом в несколько терабайт не требует большого времени ожидания или дополнительных расходов. Такое клонирование занимает всего пару секунд, независимо от размера базы данных. Разработчики, DBA и QA-инженеры могут быстро получить полностью независимые копии, выполнить тестирование и проверку идеи, получая надежные (близкие к production) результаты. В итоге скорость и качество разработки значительно возрастают.
Расскажем о том, что лежит в основе модели тонких клонов и покажем на примерах, как применять тонкие клоны с PostgreSQL уже сейчас.
В результате мастер-класса слушатели будут уметь объяснять с точки зрения математики разные свойства языков программирования, чтобы писать адаптивный и верифицируемый код.
Разберём архитектурные шаблоны при разработке собственного фреймворка, какие архитектурные ошибки допускают автоматизаторы при проектировании и как их избежать. Применим к собственному фреймворку паттерны из стандартов разработки ПО.
Composition API будет основным изменением в 3-ей версии популярного фронтенд-фреймворка Vuejs. В докладе мы рассмотрим суть подхода Composition API и преимущества, которые даёт его использование для типовых задач разработки компонентов.
На сегодня эти дополнения уже можно использовать в виде отдельного пакета, v3 планирует выход из бета-версии во 2-ом квартале 2020.
Мы обсудим:
- Vuejs intro;
- Фичи Vuejs v3;
- Composition API;
- Практические примеры.
Мы расскажем про Event Storming — отличный способ проектировать, используя Domain Driven Design.
Поговорим про DDD и обсудим опыт использования. Попробуем спроектировать систему с помощью Event Storming.
Чем хорош Event Storming?
Простота: все, что надо, — это стикеры и несколько метров стены.
Общение: эксперты присутствуют на встрече и готовы ответить на все вопросы.
Визуализация: в итоге видно, как устроена система с точки зрения бизнеса.
Полезность: результаты можно использовать для детализации и планирования.
«Жизнь — как вождение велосипеда. Чтобы сохранить равновесие, ты должен двигаться».
Умение построить единственно верную коммуникацию с сотрудниками так, чтобы было сделано то, что нужно, является базовой компетенцией руководителя. Расширение коммуникационного диапазона актуально как для начинающих, так и для руководителей топ-уровня.
Мы разберем несколько координат, которые необходимо учитывать в выборе модели: особенности ситуации, сложность решения, зрелость и психотип сотрудников, шаг в деятельности. Рассмотрим техники коммуникаций, типовые ошибки и детали, которые упускаются из вида и дают возможность продвинуть свое мастерство в управленческих коммуникациях.
Вы получите практические рекомендации по ситуативному управлению с алгоритмами вопросов и разбором ошибок.
«Вот, когда тебе не хочется хотеть чего-то хотеть — вот это кризис...»
Все знают, что надо делать, чтобы «выйти на новый уровень», зарабатывать больше, быть счастливым: изменись, выйди из зоны комфорта, делай по-другому!
В реальности мы сталкиваемся с собственным сопротивлением, которое, как невидимая рука, останавливает нас от осознанных действий. Может быть все складывается хорошо, и вы считаете, что «лучшее — враг хорошего» или, наоборот, все плохо... Как бы то ни было, надеяться, что само как-то сложится,«потому что это жизнь, а ее хрен поймешь, особенно в море!», потому что, если я сам не управляю своим изменением, им будет управлять кто-то другой.
Мы рассмотрим 8 самых разных причин сопротивления изменениям — 8 разных ситуаций, в одной из которых вы сможете узнать себя. А если знаешь, то можешь!
Будем обсуждать, говорить, общаться в группах и находить свои затыки и затыки своих сотрудников, партнеров или заказчиков!
Краткое описание:
Принцип "Convention over Configuration (CoC)" лежит в основе многих API-решений. Вы наверняка уже много раз видели некоторые его проявления, просто не отдавали себе в этом отчёта и воспринимали, как некоторые стихийные то тут то там присутствующие интересные удобства в обращении с библиотеками, фреймворками и инструментами, которыми пользовались. Но этот принцип, если применять его не стихийно, как это часто делается, а действительно последовательно и стараться от него не отходить, способен до неузнаваемости изменить привычные нам API, сделав их радикально доступнее.
Мы вначале обсудим, посмотрим на примерах, а затем введём шкалу зрелости и попробуем сами реализовать продвижение простой функциональности по CoC'овской шкале, сделав решение действительно простым и удобным для любого программиста, а также обсудим некоторые краеугольные камни этого подхода и что с ними делать.
Что получат слушатели:
- Научатся видеть элементы CoC в Java-функционале, с которым работают и поймут, как и насколько это облегчает их ежедневную работу.
- Научатся оценивать уровень зрелости решений по моей авторской шкале глубины соответствия CoC'у.
- Приобретут навыки в продвижении по этой шкале вверх своего функционала на примере Java-микросервиса на технологии Spring Boot'е.
План:
1. Структура сложности в IT-проектах.
2. Классификация решений на "Простые" и "Лёгкие", понятие морфологии.
3. Понимание принципа "Convention over Configuration" — "клиповое мышление" и декларативный подход на службе разработки.
4. Элементы CoC'а в Maven'е и Spring Boot'е, примеры-иллюстрации в других областях.
5. 10 уровней модели зрелости решений по CoC'у.
6. Практикум.
7. Резюме — недостатки CoC-подхода и что можно с ними сделать.
Что делать, если мы оптимизировали всё, что могли, но API или внешние сервисы, СУБД отвечают пару секунд, и мы получаем низкий speed index в лайтхаус, несмотря на все наши усилия. Среди миллионов способов ускорить рендеринг страниц незаслуженно забыта возможность потоковой отправки HTML с сервера на клиент. Как можно использовать эту технологию, чтобы, к примеру, пользователь начал загружать наш бандл и стили, пока на сервере бэкенд готовит для нас данные и разметку.
Потоковый рендеринг — это отличная возможность уменьшить TTFB до минимально возможных значений и в целом сильно увеличить скорость загрузки страницы вне зависимости от того, как долго происходит первый запрос на сайт.
Что сделаем:
1. Узнаем что такое потоковый рендеринг
2. Сделаем простой потоковый сервер используя express
3. Узнаем, в чем минусы решения и как это внедрять
4. Сделаем решение для реакт