Привет, друзья! С вами @alexey_m_ukolov, я сейчас в Праге и завтра буду вести трансляцию с конференции @webexpo.
Половина докладов на чешском (я его не знаю, поэтому туда не пойду), половина на английском. Расписание здесь: webexpo.net
А вот архив видео прошлых лет (у меня сайт иногда подглючивает): webexpo.net/videos/
Этот анонс должен был выйти на несколько часов раньше, но бесплатное пиво и хорошая компания на Warm Up party сделали своё дело…
Вообще, у организаторов всё серьёзно — на конференции будет три вечеринки, все с разной программой и в разных местах.
Будет несколько потоков: дизайн, бизнес, разработка. Я буду перемещаться между ними, дев-докладов посещу три. Интересны ли вам смежные темы?
Я считаю, что стоит изучать смежные области — эти знания почти наверняка пригодятся в работе. Поэтому, на конф-ях в первую очередь иду туда.
@nazarov_tech Это сильно от области зависит — в некоторых кругозор не так важен. Но в вебе стоит разбираться во все… twitter.com/i/web/status/9…
@nazarov_tech В IBM есть понятие t-shaped people — люди, имеющие широкий кругозор, но при этом сфокусированные всё же на одной области.
@nazarov_tech Если понимать как работает бизнес, дизайн, да даже бухгалтерия компании, можно оптимизировать свой пр… twitter.com/i/web/status/9…
@nazarov_tech От типа компании тоже зависит — в больших и иерархических места для манёвра меньше, но даже там можно… twitter.com/i/web/status/9…
@nazarov_tech Я впитываю всё без разбора, потому что моя работа на стыке всего на свете. В каком-то смысле я сам её… twitter.com/i/web/status/9…
@nazarov_tech P.S. Со мной можно на «ты» :)
Вступительное слово через пять минут, все спешно доедают пончики, которые бесплатно раздают при входе. pic.twitter.com/RMPyrjJIeX
В коридорах здесь *очень* шумно.
На стендах раздают стикеры и мерч, как обычно, но почти каждая компания ещё и чем-то кормит. В России я такого не припомню.
Рояли бесплатной воды: pic.twitter.com/uR4I8H1lNe
Я зарегистрировался вчера на вечеринке, без очередей, поэтому разделяю чувства коня по отношению к опаздывающим. pic.twitter.com/inAHuCwBz9
Кстати, это юбилейная десятая #WebExpo.
Так выглядит главный зал pic.twitter.com/XERibbcKGo
Начинаем утро с хардкора: What if I told you that HTTP can be fast?
goo.gl/rx3v7H
@delvedor рассказывает как они сделали свой фреймворк (Fastify) для Node.js, ориентированный на увеличение RPC.
Показал flame chart обработки запроса при помощи Express pic.twitter.com/8UCuYV84wI
А вот их фреймворк: pic.twitter.com/nHczQ05rt9
Да, мне тоже на этих графиках ничего не видно, так что проверим на слово.
Вообще, с организацией есть проблемы: экран не настроен, найти входы в залы сложновато, залы далеко друг от друга. Зато конь вниз головой.
Говорит, callback hell не существует! pic.twitter.com/q7tJyVdbe7
А проблема с замыканиями в том, что они жрут память.
В их фреймворке вообще замыканий нет.
5 минут показывал демо. Вернее, показывал секунд 7, а остальное время объяснял стену кода, из ктрй оно состоит. Я заскучал и забыл сфотать.
Доклад закончен, а я так и не понял, что же они такого могучего сделали. Видимо, нужно поковырять github.com/fastify/fastify, чтобы разобраться
Пассаж, в котором проходит конфа, никто для нас не закрывал, поэтому по нему бродят ошалелые от количества людей с бэйджами туристы.
Далее в программе: Using Hacking as a Service (HaaS)
goo.gl/Z9a3ku
Пока сюда шёл дважды заблудился. На программке есть карта, но с местными лабиринтами она не очень помогает. pic.twitter.com/awYAcqgfRK
На бэйджах NFC-метки, которые сканируют при входе в каждый зал. Неужто кто-то контрафактил бэйджы и ходил нахаляву?
Перерыва на обед не будет, но последние 20 минут каждого часа свободные от докладов - нужно успевать что-то урвать.
Поскольку следующий доклад проходит в помещении кинотеатра, по залу ходят люди с попкорном. И пивом, конечно - мы всё-таки в Чехии.
Докладчик из стримингового сервиса рассказывает как они запустили программу hack bounty и что из этого получилось.
Пробовали аудит безопасности, но он их не устроил - слишком поверхностно и это разовые события, а их платформа всё время растёт и меняется.
В то время как независимые хакеры будут пробовать разные способы, у каждого свой стиль и специализация. Они используют HackerOne.
Первым делом нужно установить границы и определить вознаграждения. Границы нужны, чтобы хакеры понимали, что можно делать, а что нельзя.
Например, они запрещают хакерам использовать аккаунты реальных пользователей и как либо их изменять.
На то, что ещё находится в разработке, можно не назначать награду и не платить за детские проблемы.
Общаться с хакерами нужно оперативно: на каждый баг нужно сразу реагировать. Не обязательно сразу чинить, можно просто пингануть.
Причина в том, что для хакеров это всё деньги.
Ещё придётся торговаться - хакеры будут пытаться убедить, что их баг самый важный или что в другой компании за такой же заплатили больше.
Один из самых серьёзных багов, которые они поймали: можно было редактировать приватные плейлисты пользователей из другого аккаунта.
При старте программы будет много репортов и большинство критических багов будут пойманы в начале. pic.twitter.com/hh20xoDUCh
У HackerOne есть приватный и публичный режим. В приватном вы сами выбираете, кто участвует в вашей программе на основании репутации и т.п.
Далее: "Dark side of IoT"
goo.gl/hYS8uE
10 лет назад не было умных телевизоров, а сейчас есть куча умных устройств. А в США можно даже машину заказать через амазоновскую Алексу.
В умном доме можно взломать веб-камеру, через неё роутер, оттуда колонки и заставить Алексу открыть входную дверь. Pozor!
Теперь ещё и ботнеты появляются из умных устройств. Всё дело в том, что там слабые админские пароли, которые никто не меняет.
Говорит, все самые нашумевшие ботнеты последнего года состояли из IoT устройств.
Некоторые от взломов страдают сильнее, чем другие… pic.twitter.com/4AHyvmTPiA
Поменяйте пароль на своём телевизоре, а то вашу страну тоже сделают great again!
Известная история про Ashley Madison (dating-сайт для женатых) - их взломали. Ладно пользовательские данные, но ребята собирались на IPO!
Target (магазин) взломали при помощи компании, которая устанавливала там кондиционеры - у тех был доступ к сети Target и данные карт утекли.
Сам докладчик взломал приложение Таргета и про него рассказали в новостях (показывает выпуск).
Никакие данные при это не утекли, была только обнародована возможность уязвимости. Но капитализация компании упала на 1,5 миллиона долларов.
Для компании размером с Таргет это мелочь, а вот ваша компания может такого и не пережить.
Venue, конечно, очень красивое: pic.twitter.com/LYNQW1ZQ6a
Сейчас будут два доклада про доступность, но мы туда не пойдём - к сожалению, они на чешском. А было бы интересно послушать.
Если вы в программе (goo.gl/xdHLD2) видите что-то интересное для себя - пишите, возможно, я туда схожу :)
Сейчас будем учиться делать программы с использованием IBM Watson.
goo.gl/LZFKC1
Мне всегда казалось, что эта платформа только для особенно кровавого энтерпрайза. Посмотрим, насколько я ошибался.
Пока ждём начала, ещё кусочек культуры pic.twitter.com/mlvfpyU0V4
В IBM есть своя платформа для разработки и управления приложениями: Bluemix.
Главное преимущество - множество доступных API, включая Ватсона. Но и сторонних API тоже много, около сотни.
Для тех кто не знает, Watson победил в Jeopardy! Выиграл миллион долларов, но затраты на свою разработку (10 миллионов) не отбил.
"Now this computer cut in pieces". Я аж испугался - ничего себе строгие порядки в IBM. Оказалось, он говорил про то, что открыли API.
Вот что Watson умеет pic.twitter.com/drwogHgAd4
Аналогичные сервисы есть у Google и, кажется, в AWS. Видимо, стоит потестировать все и выбрать тот, что решает ваши задачи лучше.
Обещают, что можно делать очень умных чат-ботов без навыков программирования. Только интеграцию со Слаком нужно про… twitter.com/i/web/status/9…
Показывает демо: настоящий робот сделал плохенькую фотографию зала, проанализировал её и определил, что мы в ночном клубе.
Дело в неудачном освещении и плохой камере, самое API распознавания изображений работает хорошо.
Всем залом смотрим ролик с ютьюба. Присоединяйтесь: youtube.com/watch?v=gJEzuY…
Докладчик сделал лампу, которая показывает настроение Твиттера по отношению к конференции. Пока цвет фиолетово-сини… twitter.com/i/web/status/9…
А вот «код» этого приложения pic.twitter.com/Ntb7wLcpPk
Доклад закончен. Тем, кому интересна эта тема, рекомендую посмотреть доклад с Google I/O: youtube.com/watch?v=ETeeSY…
Почти всем докладчикам пошли бы на пользу пару дополнительных прогонов. Для конференции с десятилетней историей это удивительно.
Сейчас доклад про Elm, давно хотел с ним познакомиться.
goo.gl/45G18Z
Язык ориентирован на SPA, но можно писать и просто компоненты и интегрироваться с web components.
Когда говорят про функц. программирование, люди начинают думать в терминах математики, науки и т.д. Elm обещает упростить этот процесс.
В языке строгая типизация со стандартными примитивами, "записями" (что-то вроде json), перечислениями и базовыми структурами данных.
Все данные иммутабельны.
В ход пошли функторы и монады. А обещал, что всё будет просто...
Ну а если серьёзно, то погуглите Maybe monad, там ничего сложного.
Большинство ошибок отлавливаются на этапе компиляции за счёт строгой типизации.
Сообщения компилятора при этом очень полезные. Никаких undefined is not a function - если ошиблись в названии метода, компилятор подскажет.
На экране какой-то интересный код, но он мелкий и освещение плохое - прочитать ничего нельзя...
Runtime Exceptions can not happen. Вот так вот.
Но есть и исключения (смех в зале).
Если сильно постараться, то при интеграции с javascript можно словить ошибку в браузере.
Опять проблемы с экраном. Докладчик предлагает выключить и снова включить. Никогда столько заминок на одной конференции разом не видел.
В Elm есть error overlay, как в Реакте. Если забыли обработать какую-то ситуацию (case в switch, например) - компилятор предупредит.
Всё это позволяет рефакторить безболезненно.
В основе архитектуры elm-приложений паттерн Model-View-Update. Как в Redux, который был на Elm основан, по словам докладчика.
В инфраструктуре Elm есть свой unit test фреймворк, а недавно добавились fuzzy-тесты.
Вот так выглядит компонент pic.twitter.com/MXbvQQj9lr
Команды, сообщения и подписки знакомы по Marionette.js, модель обновлений по Реакту. Кажется, мне было бы не сложно перейти на Elm.
Для сборки можно использовать Webpack, но есть и встроенный сборщик - Elm Reactor.
Elm поддерживает npm, но намного серьёзнее относится к SemVer. Если в коде появляются несовместимые изменения, он заставляет менять версию.
Вместе с Elm мы бесплатно получаем Time Machine, по типу той, что есть в Redux.
Можно двигаться по состоянию приложения, экспортировать/импортировать его - очень помогает в отладке.
Обещает, что кривая обучения не очень крутая - начать легко и если следовать лучшим практикам (типа TDD), проблем не должно возникнуть.
Предсказуемое время разработки - ну это уж совсем из области фантастики.
Elm быстрее Реакта. Можно приблизить реакт-приложения по скорости, но для этого придётся менять архитектуру. А в Elm всё из коробки.
@visortelle Как конкретно они дружатся в докладе не было. А работает на основе всё той же типизации. Если сигнатура… twitter.com/i/web/status/9…
Сейчас я на "Building data-driven products at speed"
goo.gl/7FY8ay
Хотел задать вопрос докладчику про Elm, из-за этого опоздал на этот доклад. К счастью (?) спикер 10 минут рассказывал про свою компанию.
Впервые вижу такой подход, нужно почитать подробнее. pic.twitter.com/5BqUQjYZ1t
Рассказывает про бота, которого они создали. В Британии можно купить билет на поезд без фиксированного места. Они помогают людям находить...
...свободные места в конкретном поезде.
Обычно они начинают с версии под Android. В первой итерации просто брали информацию о зарезервированных местах от перевозчиков. No magic.
Провели много пользовательских тестов, но из-за особенностей предметной области они были не очень релевантны. pic.twitter.com/jKPot39npK
Разные маршруты имеют разную загрузку и т.п. Да и вообще, пользователи-тестировщики находились не на вокзале в час пик.
Но какие-то общие элементы юзабилити всё равно смогли проверить и исправить.
Прямо перед релизом product owner порезал часть функционала, а дизайнерам об этом не сказали, поэтому в приложении были мёртвые части.
Первая версия под Android,
вторая под iOS,
третья снова под Android.
И каждая лучше предыдущей, на основе полученных данных.
Собственно, об этом весь доклад pic.twitter.com/JeP9ImBpvb
"Если во что-то пользователь можно ткнуть, мы это замеряем"
Рассказывает про другие компании, где используется data science: Spotyfy, AirBnB, Google и т. п.
Если вы дизайнер и пока не планируете выходить на пенсию, следующий доклад для вас.
How to survive as a web designer beyond 2020
goo.gl/uZGFhu
1. Найдите свой стиль, не копируйте, не эмулируйте - это тупиковый путь.
2. Клиенты не всегда знают чего хотят. В таком случае им нужно помочь - вытащить из них информацию на интервью.
Просто поговорите с ним по душам, попросите рассказать о себе. Некоторые фразы будут повторяться - это и есть их сущность.
3. Создайте из того, что узнали, постер для фильма об этой компании. Это поможет понять, какую историю вы пытаетесь рассказать через дизайн.
Спикер показывает примеры своего дизайна. Люди выходят из зала, пойду и я. Простите, дизайнеры, не узнать вам как работать после 2020...
Я, конечно, не дизайнер, но мне кажется, что это было какое-то капитанство - если клиент не знает чего хочет, помогите ему разобраться.
Но, может, в мире дизайна это какая-то ground breaking idea...
Следующий доклад обещает быть интересным: Say yes to premature optimizations
goo.gl/3yfjM8
Это интересная тема. Основные проблемы преждевременной оптимизации:
- она вредит архитектуре,
- усложняет код,
- может не работать вообще.
Например, писать цикл for через i-- или сохранять длину массива для него в переменную уже давно нет смысла - V8 сам всё оптимизирует.
Но заменить несколько вызовов querySelector на один и использовать его результат - вполне нормально. Архитектура и читаемость не страдают.
Посмотрим, что скажет спикер.
Она работает в Slack, сильно шустрым я бы его не назвал :)
@badgercat В Праге можно это время на пиво потратить…
В этом зале тоже проблема с проектором, так что если в презентации будут интересные слайды — tough luck.
RT @webexpo: How to survive as a web designer beyond 2020? Be the blacksheep by @mikekus at #webexpo pic.twitter.com/QzSQWkDWpg
And now for something completely different: гендерным паритетом тут и не пахнет. Девушек процентов десять от силы.
Среди спикеров тоже. В одном из четырёх залов половина — женщины. А в остальных нет. twitter.com/Pavlina_speaks…
И не сказать, что ситуация улучшается. twitter.com/benAbraham/sta…
Возвращаемся к преждевременной оптимизации...
Когда Мод пришла в Слак, она ожидала, что раз это новая компания, то там и стек хайповый - Go или хотя бы RoR.
Оказалось, что там одно монолитное приложение на PHP в процедурном стиле.
1 микросервис на Go у них всё же есть на периферии.
Всё внутри Слака крутится вокруг команд - пользователи и каналы не имеют смысла вне команды. Поэтому каждый раз приходится регаться заново.
Окей, похоже, в основном речь пойдёт про бэкенд.
Совет №1: включите rate limits в вашем API. Таким образом оно не задохнётся, когда придёт какой-нибудь спамер или просто высокая нагрузка.
В Слаке лимитами закрыто всё - и внешнее API и сам код внутри.
Подобрать правильное значение для лимита сложно - потребуется немного поиграть с разными настройками, чтобы найти золотую середину.
Внедрить лимиты с самого начала намного проще, чем добавить их на ходу. Многие фреймворки поддерживают их из коробки, это реально просто.
Совет №2: если какая-то фича тормозит у конкретных пользователей, отключите её для них. Когда исправите проблемы - включите обратно.
Для этого можно использовать фичефлаги и в случае аварии - хардкод. В коде Слака есть хардкодные куски.
Но реализация такого отключения фич для конкретных пользователей скорее всего будет преждевременной, если вы не очень большая компания.
Совет №3: используйте кеш. Многослойные кеши. Много кеша.
Кешировать часто больно - инвалидировать сложно (цитата про 2 hard things), хранить дорого. Но всё равно полезно.
Совет №4: используйте очереди задач. В Слаке на них реализована, например, архивация канала - при этом нужно выполнить кучу разных задач.
Недавно их клиент случайно заархивировал канал с 17k пользователей. Это были тяжёлые пара дней.
Так что лучше разбивать одну большую задачу на несколько маленьких - тогда можно и распланировать их и отменить при необходимости.
Совет №5: мониторьте производительность своих приложений.
Когда эта система уже работает, добавлять новые замеры очень просто. Так что это хорошая инвестиция.
Но хранить все эти данные может быть дорого - скорее всего, придётся выбирать что именно мониторить.
Но больше мониторинга лучше, чем меньше мониторинга.
А ещё в Слаке по всей кодовой базе раскиданы разные прямые SQL-запросы. Так что иногда возникают неожиданные проблемы с производительностью.
Совет №6: используйте грамотные запросы, знайте как ваша СУБД их обрабатывает и избегайте проблемы N+1.
Совет №7: реализуйте в своём API пагинацию. Таким образом большие запросы не съедят всю вашу память.
Опять же, внедрять её с самого начала гораздо проще, чем на живом проекте.
Совет №5: приоритезируйте операции в вашем приложении. Без чего-то оно бессмысленно (сообщения в Слаке), а без чего-то можно часок обойтись.
Прекрасный доклад, отличное завершение дня.
Действительно, всё перечисленное не является преждевременными оптимизациями. Гораздо дешевле внедрять этот функционал с самого начала.
Завтра продолжим, а пока можете познакомиться с программой: webexpo.net/prague2017/tim…