Русский
Русский
English
Статистика
Реклама

Доклады

Как создатель node.js сам разочаровался в нем

24.03.2021 12:04:07 | Автор: admin

Несколько лет назад на JSConf 2018 выступил Райан Даль, создатель Node.js. Его доклад вызвал сенсацию, он затронул много актуальных проблем и поднял громкий хайп, не оставив равнодушным практически никого, кто связан с серверным программированием. В его обсуждении бэкэнд программисты разделились на два лагеря: одни отстаивали Node.js, другие прочили ему скорую смерть.

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

Немного про Node.js


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

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

Первоначально среда называлась web.js, но ее возможности применения оказались намного шире, чем обычный веб-сервер, и потому платформу переименовали в Node.js. Готовый проект был представлен Райаном на JSConf 2009, 45-минутное выступление сорвало аплодисменты:


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

Не обошлось без проблем, в частности было не просто найти разработчиков с подходящим бэкграундом. Чаще всего причины: I HATE NODE.JS!!!1111oneone, они проистекают как раз из того, что кажущаяся простота языка привлекает программистов, которые ранее не занимались разработкой для серверов. На JS обычно писали фронтэнд, а там решаются совсем другие задачи. С проблемами сталкивались и разработчики на Java, потому что у них было предубеждение: На языке называющемся JavaScript, я программировать смогу без проблем!, что на деле было совсем не так просто. Оказалось, что легче других с задачей программирования на JS под Node справляются программисты, работавшие на платформе .Net. Более того, в момент развития Node дотнетчики испытывали некоторые трудности с востребованностью, а программистам JS для бэкэнда хорошо платили.

Сам же Райан через некоторое время после завершения разработки, примерно в 2012-13 годах, увлекся языком Go и надолго отошел от всего, связанного с Node.js, потому что этот язык полностью устраивал его по возможностям и быстродействию, а позже он увлекся нейронными сетями.

Критика Node.js его создателем


Примерно за полгода до конференции JSConf 2018 Райан Даль решил попробовать работать со своим детищем, спустя почти 10 лет с момента его создания. Нельзя сказать, что он был доволен тем, что увидел. Несомненно, проект сильно развился, но во время разработки Node.js Райан был слишком зациклен на решении проблем ввода/вывода, потому допустил некоторые ошибки, которые потом превратились в системные проблемы. Поскольку платформа стала чрезвычайно популярной, то уже поздно было что-то глобально менять, не поломав все зависимости и совместимость.

Райан и раньше очень критично отзывался о всем программном обеспечении, не только о Node.js. В 2011 году он устроил небольшую пятиминутку ненависти на Google+. Сама соцсеть давно закрыта, но интернет все помнит. Перевод его слов можно прочитать здесь: Я ненавижу почти всё ПО. А за год до выступления в 2018 рассказывал о том, что: Для серверов я не могу представить другой язык кроме Go. Забегая вперед, он действительно начинал писать на Go, убийце node.js, но потом перешел на Rust.

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


10 Things I Regret About Node.js


Давайте вспомним основные тезисы, которые были в нем рассмотрены, а потом сравним с тем, как обстоят дела на данный момент.

1.


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

2.


Проблема с безопасностью. Приложение на Node.js получает доступ к локальному диску, сети и вообще ко всей системе сразу.

3.


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

4.


Излишне громоздкий package.json.

5.


Семантика платформы несовместима с браузерами

6.


Централизованный репозиторий для модулей.

7.


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

8.


Использование index.js, по аналогии с index.html, привело к усложнению загрузки модулей и перестало быть необходимым после поддержки package.json.

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

Анонс Deno


После перечисления недостатков Node.js Райан представил свой собственный проект среды выполнения JS на сервере, последовательно перечисляя его преимущества, в сравнении с Node:

1.


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

2.


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

3.


Полная поддержка TypeScript.

4.


Единственный исполняемый файл без лишних связей

5.


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

6.


Падение приложений при Uncaught Errors, асинхронные операции будут возвращать Promise, большая совместимость с браузерами.

Кроме перечисленного Deno будет использовать ES Modules, которых тогда тоже не было в поддержке Node.

Что изменилось в Node.js



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

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

Упомянутые в докладе проблемы с выполнением асинхронного кода, на данный момент более-менее решены. Конечно, было бы лучше, если бы Райан не удалил Promises в 2010 году, посчитав, что они слишком все усложняют, но сейчас многие системные библиотеки уже предоставляют этот функционал, не говоря уже про сторонние. Появилась возможность запускать скрипты параллельно с помощью workers, большие компании, такие как Microsoft и Alibaba, разрабатывают свои версии Node с многопоточностью.

От GYP так и не избавились, это наследие будет с Node еще долго. Ссылки url, совместимые с браузером, уже не засунуть, зато, с некоторых пор Node поддерживает ES-модули.

Разрешение зависимостей сложное и работает не так как в браузере, но работает, что самое главное, хоть и не без некоторых проблем. А появление механизма package-lock.json сводит их к минимуму.

NPM сильно эволюционировал с 2012 года. Хотя, надо заметить, эволюция была болезненная и подталкивали ее проблемы типа набившего оскомину left-pad. Но пакеты уже не исчезают просто так, есть несколько уровней аудита безопасности и возможность ставить пакеты из разных источников. Хотя до сих пор ничего не мешает разработчику залить на github правильный код, а в npm код с эксплойтом.

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

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

Справедливости ради надо заметить, что активно развитие Node сильно сдерживается энтерпрайзом, в котором такое огромное количество легаси-кода, что избавиться от него слишком дорого. Это давно вызывает серьезные проблемы, когда Linux надо обновлять, а под новую систему не удается собрать все модули и рано или поздно приходится переписывать огромное количество кода, тратя на это много времени и денег. Большие корпорации могут позволить себе выделить на это ресурсы, но небольшой хоббийный OpenSource проект будет брошен, если у разработчика не будет времени на его обновление.

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

Развитие Deno



Вскоре после доклада, сообщество быстро разгадало анаграмму Node-Deno. Даже прозвучали шутки, что когда-то будет написан проект под названием Done. Но шутки шутками, а к чему же пришло развитие Deno?

Во время доклада Райан честно сказал, что на данный момент Deno экспериментальный прототип и не предлагается как альтернатива Node


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

Как уже упоминалось выше, проект начинался на Go, но потом был переделан на Rust. Проект хоть и перестал тормозить, как в начале, но так и не показал преимуществ по скорости. Работа с TypeScript стала быстрее, сказались оптимизации, которые внесла команда, потому что в момент презентации запуск транслятора TS занимал целую секунду. Решено это было, как Райан и предполагал в своем докладе 2018 года, с помощью снимков состояния движка.

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

На данный момент Deno состоит из следующих частей: обертка из Typescript/ Javascript, над движком V8, который является песочницей, обеспечивающий интерфейс между слоем TS/JS и Rust Backend (серверная часть имеющая доступ к файловой системе). Многопоточная работа обеспечивается с помощью Tokio асинхронной среды исполнения Rust, отвечающая за создание и обработку событий, с помощью конструкций Rust Future, аналога Promise в JavaScript.

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

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

***


На данный момент уже вышла версия релиза под номером 1.7. Но все еще не слышно, чтобы какая-то крупная компания отказалась от Node.js в пользу Deno. Мы даже сделали в маркетплейсе для node.js



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

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

Хотя Даль начал работать над Deno задолго до выступления на конференции в 2018 году, первоначальная тема для нее была совсем другая. Он планировал выступить с докладом по машинному обучению, которым занимался последние несколько лет. Но не успел вовремя подготовиться и тема его выступления была снята буквально за пару дней до конференции. А поскольку он понимал свой вес в сообществе и то, как зрители будут ждать его выступления, то за день или два ему пришлось очень сильно постараться, чтобы найти новую достойную тему, оправдывающую ожидания публики.

Так что может он и не задумывал провозгласить убийцу Node.js, а просто поторопился с подготовкой нового доклада. Хотя ему таки удалось поднять очень изрядный шум, возможно куда больший, чем темой про глубокое обучение.

Подробнее..

TeamLead Conf 2021 последствия коронавируса, удаленка и доклады не только про IT

02.03.2021 10:09:04 | Автор: admin

До единственной профессиональной конференции только для тимлидова TeamLead Conf 2021 осталось совсем немного 29 и 30 апреля она распахнет свои двери для всех, кто хочет повысить скилл в сфере управления. В этой статье мы приоткроем завесу тайны и расскажем о том, что вас ждет.

О самых выдающихся и полезных докладах, о вариантах участия в конференции, мерах защиты от коронавируса (куда уж без них в наше время?) и о том, как тимлидам справиться с условиями удаленной работы рассказал руководитель программного комитета TeamLead Conf 2021 Роман Ивлиев.

Расскажи о себе: кто ты, чем занимаешься и как принял решение присоединиться к программному комитету?

На текущий момент я являюсь техническим директором портала Mos.ru. Я с самого начала участвовал в создании TeamLead Conf, а со второй конференции стал руководителем программного комитета.

Мне интересна эта сфера. Она не совсем техническая, на TeamLead речь идет об управлении. А конференций об управлении на таком уровне в 2018 году России не было. Сейчас это модная тема: есть обучающие курсы, куча школ. Но началось все после нас. Современные курсы для тимлидов в Geekbrains и Skillbox появились буквально полтора года назад.

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

Первая конференция, как мне кажется, была совсем небольшой: в ней приняли участие около 400 человек. А дальше шло по нарастающей. На пике популярности в Москве к нам приходили 1200 или 1300 слушателей. И даже сейчас, когда многие сидят по домам, интерес к этой сфере есть.

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

В чем особенность конференции в этом году? Ходят слухи о том, что ее будет интересно посетить не только тем, кто работает в IT.

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

У нас была идея попробовать такой формат, поскольку появилась конференция TechLead, которая утащила на себя всю технологическую составляющую.

В свое время мы пытались собирать на TeamLead Conf, в том числе, и технологии. У нас была попытка сделать технологичный трек. Но оказалось, что тем, кому интересны технологии, не интересно управление, а тем, кому интересно управление, плевать на технологии, в той или иной степени. Раз уж такое разделение произошло, мы подумали: если мы уже отпилили всю технологическую составляющую, есть ли принципиальная разница между людьми, которые управляют айтишниками, и людьми, которые управляют, допустим, маркетологами или дизайнерами? Методы и подходы одинаковые, люди тоже. Единственная специфика это сам производственный процесс.

Поэтому конференция в этом отношении более гуманитарная, чем все предыдущие версии.

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

Как сказалась на проведении пандемия? И какие меры будут предприняты для того, чтобы обезопасить участников?

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

Максимальная вместимость площадки: около 1200 человек. А мы можем позвать не более 50%.

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

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

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

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

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

А дальше уже помогает литература, общение с живыми людьми, применение всего этого на сотрудниках, с которыми ты работаешь.

Как таковой, тусовки на конференции нет. Это не HighLoad, куда приезжают из года в год, чтобы просто пообщаться друг с другом, выпить пива и обсудить актуальные вопросы. Мы создали чат Боль тимлида, который должен был стать этой точкой притяжения. Но если говорить объективно, там есть актив в 30-50 человек, которые постоянно мутят воду, поднимают какие-то вопросы, отвечают на них, ругаются друг с другом и т.д. А еще есть 4 тысячи человек, которые просто это читают.

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

Все IT сообщество соскучилось по оффлайновым мероприятиям. Каков настрой у спикеров, рвутся ли они в бой? И как быть тем участникам, кто все-таки не сможет прийти? Есть онлайн-альтернатива очному посещению?

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

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

У нас будет гибридный формат конференции: участников ждет свой контент и свои активности и онлайн, и оффлайн.

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

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

И у онлайн, и у оффлайн аудиторий будут уникальные активности. Например, мы никогда не транслируем онлайн происходящее на митапах. Это довольно сложно сделать, ведь их формат общение с залом. Мы пробовали, получается так себе. А в онлайн появится возможность поговорить с экспертами. Все секреты раскрывать не буду: откроем их на конференции.

Думаю, онлайн с нами надолго. И это очень перспективное направление, если правильно к нему подойти. Например, компаниям, которые работают за Уралом, очень дорого везти своих сотрудников в Москву. Теоретически, если оффлайн нормально состыкуется с онлайном, аудитория вырастет.

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

Расскажи подробнее о докладах, принятых в программу конференции. Что полезного из них могут вынести гости TeamLead Conf?

Неинтересные доклады мы просто не принимаем. У нас достаточно злобный программный комитет в том плане, что мы очень требовательны к докладам, и всегда стараемся выбирать лучшее. В этот раз, например, к нам придут ребята из НовосибирскЭнергосбыт. И интересно даже просто послушать, что люди, работающие в другой области, живут примерно по тем же правилам. Они расскажут о том, как они сокращали Time To Market.

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

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

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

Есть более приземленные доклады. Например о том, как правильно работать с совещаниями. Удаленные совещания вещь специфическая, и не все их нормально посещают.

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

Будет нетрадиционный для нас докладчик из X5 Retail Group (это компания, управляющая продуктовыми торговыми сетями Пятерочка, Перекресток, Карусель и Чижик). Он расскажет про карьерные уровни. Интерес в том, что это карьерные уровни в необычной для нас сфере. Мы привыкли к тому, что IT это Яндекс, Mail, Badoo, Авито, еще 10 известных компаний. В стране это 5% айтишников, а остальные 95% люди, которые работают совершенно в другом мире.

Только представьте, сколько людей работают на налоговую, чтобы сделать сервис Налог.ру, или все личные кабинеты МосЭнергоСбытов. Даже у человека, который собирает в маленьком городке показания для домофонов есть свой персональный кабинет, и кто-то его программировал.

Мы привыкли, что интернет это всякие публичные сайты и магазинчики. А есть еще огромная гора приватного интернета, про которую редко кто-то рассказывает. И наконец-то появился шанс об этом послушать.

Есть доклады от представителей известных компаний: Kaspersky Lab, Тинькофф банк, Evrone это наши постоянные докладчики.

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

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

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

Один из докладов конференции называется Команда мира. Счастливая удаленка и инструменты, которые сработают. А как вообще удаленная работа сказалась на деятельности тимлидов? Стало проще, или сложнее выстраивать работу с сотрудниками? И как настроиться на то, что теперь (хотя бы на какое-то время) удаленка часть жизни?

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

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

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

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

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

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

Почему ты сам посещаешь конференции? Часто ли выступаешь как спикер?

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

Иногда просто езжу послушать интересные доклады. Чаще всего, посещаю те мероприятия, где выступаю. Все остальные могу посмотреть в записи, особенно это касается непрофильных для меня конференций. Я могу послушать доклад маркетологов просто потому, что стало интересно. Если по работе меня интересует какой-то вопрос, или я понял, что не понимаю, как мыслят продакт-менеджеры, пойду на условный ProductSense. Пообщаюсь, посмотрю, что читают его зрители (схожу на ближайший книжный лоток, который обычно есть на всех конференциях) и пойму, что творится у них в головах.

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

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

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

Что обычно советуешь своим подопечным, чтобы их выступления стали лучше? Есть ли лайфхаки, которыми можно поделиться в открытую?

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

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

Поэтому очень важно не врать. В моменте, когда ты врешь, ты можешь сам себе поверить. Это когнитивное искажение 1. Ты рассказываешь, как все офигенно, и веришь в это, в моменте. А на самом деле все не так, и ты бессмысленно тратишь время.

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

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

Последний вопрос. Если бы тебе нужно было посоветовать своему другу пойти в этом году на TeamLead Conf, какие слова бы ты подобрал? Почему он должен посетить ее именно в 2021 году?

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

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

Придя на оффлан конференцию, ты выделяешь время на обучение. Ты не можешь никуда уйти. Максимум, что можно сделать это сесть поработать в коридоре. Но я считаю, что это не слишком умный поступок.

Я всегда рад, когда ребята из моей компании просятся на какую-нибудь конференцию. Как минимум, это говорит о том, что люди хотят развиваться. Для специалиста любое проявление интереса очень важный критерий того, что он профи. Если человек не проявляет интереса, даже не почитывает Хабр, это уже не специалист.

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

На конференциях все радостно идут на контакт. Можно поболтать за обедом, или в коридоре.

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

Московская конференцияTeamLeadConf 2021 в этом году пройдет 29 и 30 апреля вRadisson Slavyanskaya. Расписаниеконференции уже готово.Билетыв продаже. Присоединяйтесь!

А если вы хотите еще и выступить, спешите подать доклад на питерскую конференциюSaint TeamLead Conf 2021.Выходите на свет рампы вместе с нами!

Хотите бесплатно получить материалы предыдущей конференции для тимлидов? Подписывайтесь на нашу рассылку.

Подробнее..

Как работать тестировщику выстраиваем планирование, общаемся с командой разработки и проверяем сайты на безопасность

03.03.2021 14:04:54 | Автор: admin

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

Современные паттерны тестирования

Рассказывает директор по развитию бизнеса в IT-компании @BSL_Dev и ex-руководитель отдела обеспечения качества Redmadrobot Марина Куликова @Marishunya_QA.

Коротко в чем суть.

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

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

Основная цель тестирования своевременно оповещать команду о реальном состоянии системы или продукта

Основные точки опоры для построения тестирования

  1. Анализ требований или технического задания.

  2. Инфраструктура важно настроить окружение, выбрать целевые устройства, какие тестовые данные потребуются.

  3. Процесс коммуникации нужно договориться, в каком формате мы выстраиваем обратную связь с командой (например, делаем отчеты о тестировании в Jira).

  4. Разбираемся, как именно организовываем тестирование: какие виды тестирования, на каких этапах применяем, как распределяем ресурсы, планирование и так далее.

  5. Уделяем время написанию отчетности и договариваемся, какая отчетность и в каком виде нужна.

  6. Постоянно внедряем улучшения и анализируем изменения.

О чем тестировщик должен сообщать команде

  • Что нужно автоматизировать. В процессе коммуникации с разработчиками и менеджерами тестировщику нужно определить и рассказать, какие тесты должны быть автоматизированы и на каком уровне.

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

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

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

Тестирование это как круговая оборона. Весь продукт охранять очень сложно, поэтому тестировщики создают датчики (некие красные флажки), которые в нужный момент сообщают: alarm! И подобные датчики это метрики, а также автотесты, различные приемы и т.д. Задача команды тестирования выстроить многослойную систему защиты, состоящую из нужных датчиков. Также стоит помнить, что помимо того, что QA тестирует, команда ещё сообщает реальное состояние системы, где все окей, где начинает рваться, а где все плохо и нужно срочно исправлять.

Как тестировщику обеспечивать обратную связь для команды

  1. С помощью парного тестирования или программирования. Автоматизацию тестирования полезно делать при поддержке разработчиков. На этом этапе должно происходить взаимное ревью, это помогает тестировщику глубже узнать систему и уже на этом этапе обнаружить какие-то проблемы.

  2. С помощью Code Reviews. Это не совсем работа тестировщика, но в проекте через Code Reviews можно получить обратную связь. Например, если у нас фича автоматизации типовая, и она долго ревьюится на разных проектах, то нужно выяснить причину.

  3. Через модульные тесты (Unit tests).

  4. С помощью автоматизированных интеграционных тестов (Automated Integration Test).

  5. С помощью автоматизированных Acceptance Tests. Эту активность можно разделить с продакт-менеджерами.

  6. По возможности следует автоматизировать Regression Test.

  7. Постоянный Exploratory Testing.

  8. Обратная связь от пользователей или бизнес-юзеров.

  9. Постоянное UAT-тестирование + DEMO-сессии.

Через что тестировщик может организовать обратную связь с командой

  • С помощью работы с дефектами (багами) нужно определить формат их заведения и оповещения о них, например, делать это в Jira или другом удобном инструменте. Разработчикам не всегда хватает информации в дефекте, чтобы приступить к фиксу, поэтому иногда требуется дополнительная коммуникация с багрепортером.

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

  • Кросс-обучение внутри тестирования. Все специалисты разные, они могут учиться друг у друга, поэтому важно иногда собираться и обсуждать результаты работы и делиться лайфхаками и знаниями продукта. Это некий knowledge transfer.

  • Тест-документация собирать отчетность по фичам, сборкам и по приемке. Для составления отчетности поможет изучение ГОСТов: в них описаны градации дефектов, как с ними быть и так далее. Для проектов, связанных с государственным подрядом, поможет изучение ГОСТ 34.603-92.

Как тестировщикам работать с Google-таблицами (и зачем)

Руководитель отдела тестирования Redmadrobot Саша Строкин собрал собственные Google-таблицы, с помощью которых он выстраивает работу, начиная от планирования и заканчивая аналитикой для тестировщиков.

На нескольких примерах Саша рассказал об инструментах и формулах, которые он использует в работе.

Google-таблицы при планировании подготовка к процессу тестирования

В тестировании есть четыре главных процесса:

  1. Планирование подготовка к самим работам по тестированию,

  2. Test development крафтинг артефактов, разработка сценариев тестирования,

  3. Test execution само выполнение тестирования,

  4. Test analysis оценка результатов тестирования, выделение процессов, которые нужно улучшать или, наоборот, не стоит менять.

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

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

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

Интеграция Google-таблиц с Jira

Интеграция Excel c рабочим инструментом большинства команд разработки и тестирования Jira возможна через специальный плагин Jira Cloud of Sheets.

C помощью этого плагина можно вытаскивать любые данные из бэклога Jira по тому же фильтру, по которому обычно тестировщики фильтруют дефекты, только с переводом не на графическое изображение, а на JQL.

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

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

Для формирования такой статистики нужно воспользоваться вкладкой MounthStat (она вытягивает данные о дате создания из общей выгрузки, где мы можем выбрать дату создания дефекта). С помощью функции Trim даты можно рассортировать по месяцам.

Все готовые таблицы для работы из презентации Саши.

Тестирование и безопасность web-сайтов для начинающих тестировщиков

Рассказала и показала QA-инженер Redmadrobot Вика Бегенчева @vikusti.

Основные уловки мошенников, как они могут навредить пользователям или системам:

С помощью cookies

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

Эта информация нужна для удобства пользователя, чтобы сайт запоминал определенные данные и нам не приходилось постоянно их указывать. Cookies бывают двух видов: временные (cookies-сессии) и постоянные. Cookies-сессии хранятся определенное ограниченное время и могут меняться, когда пользователь перелогинился. Постоянные сookies хранятся всегда, пока вы их не сотрете.

Как хакеры могут использовать cookies

Хакер может угнать ваши cookies и с помощью этого доказать системе, что он это вы. Тогда он сможет переиспользовать их и продолжить сессию. Это происходит так:

Через протоколы: HTTP и HTTPS

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

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

Подбор пароля Brute force

Это атака перебора мошенник может знать логин и с помощью специального скрипта подбирать пароль. Обычно подбор пароля с помощью скрипта занимает около 10 часов.

Как проверять сайты на безопасность

  1. Посмотреть, как устроена безопасность хранения cookies: открываем Инспектор в браузере, заходим в вкладку application и видим свои cookies для сайта. Для проверки безопасности нужно обратить внимание на столбцы под названием httpOnly и secure. Если галочки стоят, то на сайте предусмотрена защита от угона cookies.

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

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

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

Полезные ссылки

  • Telegram-канал Google Таблицы: много информации о фишках Google Sheets;

  • YouTube STM Solutions: видеоуроки Google Docs, Google Sheets, Google Apps Script;

  • Jira Cloud for Sheets: плагин для интеграции Google Sheets с основным рабочим инструментом большинства команд Jira;

  • owasp.org: некоммерческий фонд, который работает над повышением уровня безопасности ПО;

  • hackthebox.eu: тренировочная онлайн-платформа, на которой можно проверить навыки тестирования в сфере безопасности сайтов;

  • xss-game.appspot.com: тренировочная игра для обнаружения и устранения ошибок XSS.

Подробнее..

Практики хорошего code review, или что такое code review за 15 минут. Доклад Никиты Соболева на DUMP в Казани

16.07.2020 22:12:04 | Автор: admin

В 2019 году на DUMP в Казани выступал Никита Соболев технический директор компании Мы делаем сервисы. И Никита на протяжении почти 40 минут пытался вскипятить мозги слушателей секции Backend, рассуждая о code review. Сегодня хотим привести расшифровку этого взрывного доклада, чтобы если уж мозги бурлили, то у всех сразу :)


А вот, кстати, и сам Никита Соболев во время своего выступления.




Для удобства вот ссылка на презентацию.
Доклад начался с постановки того, о чем же он будет. И внезапно прозвучала фраза: Я не буду рассказывать о code review. Доклад будет про хардкорные технические инструменты и методы автоматизации. Главный тезис если вы делаете code review, то вы уже проиграли. Интригующе звучит? :) Давайте вместе с Никитой разбираться, что же за этим стоит.


За основу были взяты понятия, которые предложил американский писатель Карлос Кастанеда, делание и неделание. Что же это значит? Делание это привычка, внутри которой мы существуем. Эдакое хомячье колесо. А неделание взгляд на те же самые вещи, но под другим углом. Никита ловко наложил эти понятия на просмотр кода. И получилось, что мы имеем делание code review и, соответственно, неделание code review. Вот как раз последнему и посвящен доклад.


Делание становится рутиной, чем-то сложным, где нужно применить свои коммуникативные навыки, быть эмпатичным. И встает вопрос: а нафига я буду смотреть какой-то код? Неделание же это гармония. Ты смотришь на код и восхищаешься им. Ты понимаешь, что вот этот вот код станет частью продукта и принесет новые деньги. И конечная цель, к которой подводит нас Никита всеми этими речами в том, чтобы делать code review за 15 минут. И даже есть живой пример.


Но для начала нужно разобраться, почему же все так плохо с code review?


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


  • многие люди контролируют выполнение какой-то задачи при помощи code review;
  • контроль качества кода;
  • чтобы новички не повторяли грабли, на которые уже сто раз наступали;
  • многие делают code review для архитектурного review;
  • многие через code review обучают людей.

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


Обучение людей с помощью code review.


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


Решение: маленькие задачи. Вы можете дать новичку сразу что-то важное, но при этом небольшое. Это ускоряет обратную связь, увеличивает вероятность найти косяк в коде. Ведь чем массивнее код, тем сложнее поиск ошибок говорит статистика. Под маленькими подразумеваются задачи от 15 минут до 2х, максимум 4х часов. Соответственно, это все предполагает наличие онбординга и хорошей документации. За примером хорошего онбординга (без нудного code review по неделям) идем на Open-Source. Что у них есть? Чек-лист:


  • Contributing.md документ, в котором описаны самые верхнеуровневые шаги;
  • Developer Docs документы с описанием всех api-методов и вообще всего;
  • Architecture Decision Records история решений, принятых по поводу архитектуры. Очень помогает въезжать в процесс новичкам;
  • Wiki с ответами на популярные вопросы;
  • База данных задач и pull requests;
  • И главное понятные для людей тесты.

Если ваш онбординг построен как-то не так, то вам есть куда расти, потому что на Open-Source люди стремятся вот к этому.


Для вдохновения Никита предлагает ряд хороших мест:


  1. Gatsby.js одна из лучших и самых быстрорастущих по количеству контрибьюторов систем, которая описала вообще все;
  2. Dev.to сайт со статьями, документцией, видосами и т.д. У них тоже все прекрасно;
  3. Wemake-python-styleguide творение, к которому сам Никита относится, и по его словам большое количество новых контрибьюторов и довольно мало ошибок.

Перейдем к обсуждению следующей проблемы review архитектуры. Обычно оно корявое. Какие с ним могут быть проблемы?


  • Долго. Когда мы говорим о том, что у нас есть review архитектуры, то это значит, что человек должен пойти и подумать, написать, все перерефакторить и через месяц прислать нам pull request. И как мы будем его ревьюить? Естественно, никак.
  • Дорого переделывать.
  • Участвует один человек.

Решение: проектировать и прототипировать design до review. Design до review это когда вы делаете не саму архитектуру, а ее скелет. Текстом или фиксируете в каком-нибудь файлике. Человек по скелету сможет сказать нравится\не нравится. Это намного быстрее и эффективнее, чем code review в данном смысле.


И, конечно, автоматизация! Никита рассказал о том, как можно автоматизировать архитектурные проверки.


В каждом приложении есть слои (тут, кстати, Никита проводил аналогию с офигенным бургером). И чтобы проверять их есть все возможности. Далее примеры пойдут на языке python.


  • Есть такая штука называется importlinter. Она умеет проверять вашу архитектуру на основе ваших импортов. Когда вы делаете импорт, значит, эти два модуля связаны между собой. Эта связанность и проверяется. Как это делается? Указываете название вашего пакета, после этого вы определяете тип контракта. Все абсолютно декларативно, без кода. Это все текстовый файл. У нас есть такое то имя, вот такой-то тип контракта, который называется layers. И мы будем проверять пакет django_project. У него есть слои: urls, views, forms, models, logic. Соответственно, logic может импортировать ничего. Models могут импортировать logics. Forms могут импортировать models и logic и так далее.



  • Мы можем проверять независимость наших модулей. Часто нам не просто важно определить, что пакеты лежат по разным слоям, но что они лежат на одном уровне. Делается все то же самое, что и в случае со связанностью.



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



  • Для более сложных случаев, когда вот здесь можно, а здесь нельзя, а сверху еще требуются дополнительные проверки напишите свой контракт. Есть api, вы пишите свой контракт готово!

Таким образом можно ревьюить архитектуру автоматически.


Следующая проблема неповторение грабель.


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


В понимании нашего чудесного докладчика, хорошая документация это когда вот так.




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




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




И теперь другая автоматизация! Часто люди делают ошибки не только в коде. Для решения этой проблемы есть замечательный проект Danger. С ним схема будет выглядеть вот так:




На 2020 год danger-правило можно написать на следующих языках: JS, Swift, Ruby, Kotlin и Python. Никита в своем докладе привел примеры на JS.


Валим CI проверки:


  • Pull request не в мастере, а надо в мастер.
  • Pull request не мерджится из-за конфликтов.



Предупреждающие проверки:


  • Pull request без описания.
  • Забыли указать номер issue в теле.



Так это выглядит в итоге. Здесь исключено человеческое взаимодействие, все автоматизировано.




И еще одна фишечка утилита bellybutton. Она есть для всех языков (проверено Никитой). Допустим, у вас есть некая deprecated_fn(), которую не надо вызывать. Она старая и странная, и существует просто потому что так надо. Вы говорите человеку, чтоб не трогал ее, но он все равно трогает. Когда-нибудь надоест это повторять, и тогда вы берете декларативный файл формата yaml и пишите:




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


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




Почему все так? Во-первых, люди не умеют писать код. Загвоздка в том, что человек должен писать понятно и для другого человека, и для компьютера, а последние два говорят на разных языках. Отсюда и большая сложность. Во-вторых, эта сложность быть понятным для всех и сразу постепенно накапливается. В-третьих, скрытость метрик. Чтобы проверить качество кода, нужно сначала вывести метрики куда-то на экран, посмотреть все это дело, а затем еще долго исправлять. Именно поэтому проблема качества кода это очень и очень серьезная проблема, и к ней нужно подходить с самого начала проекта. Решение: самый жесткий линтер из доступных. Чаще придется писать свой: под разные языки + существующий может быть недостаточно строг. Как говорит Никита: чем больше вы ненавидите линтер, тем он лучше.


Проблема баланса кода и архитектуры. Тут могут возникать такие ситуации:


  • При слишком сложной архитектуре приложения перестаешь понимать, что происходит и куда писать наш код;
  • Архитектуры много, а кода 20 строчек;
  • Наоборот, кода много отсюда сложность работы с ним.

Решение: Architecture on Demand. Оно позволит писать ровно столько архитектуры, сколько нужно. Простая архитектура и простой код под текущую ситуацию. Подробнее Никита этот способ разобрал здесь.


И last but not least проблема контроля выполнения. Обычно говорят, что контроль выполнения это, когда code review, прогон всех тестов, запуск на компьютере, но нет. Перед нами встают проблемы:


  • Я не умею запускать код в мозгу;
  • Я не знаю что, нужно клиенту;
  • Не все нюансы понятны из кода.

Решение: BDD (эффективный способ общения и с заказчиком, и с программистами, и с кем угодно) и Review Apps. Последнее нужно для посмотреть глазками, потому что мало просто прогнать тест. При таком подходе вы сможете сделать ревью уже задеплоенного приложения. Например, использовать ZEIT для GitLab. Так появляется возможность получить на каждый pull request версию приложения.


Только тогда, когда вы прошли все тесты, клиент посмотрел и сказал, что это то, что нужно, вы сами посмотрели, что это работает, можно сказать, что задача выполнена. В итоге получается, что это все не про code review. Код еще даже никто не смотрел.


А теперь подведем итоги. Были разобраны все обозначенные проблемы. Как можно увидеть, ни одна из них к code review отношения не имеет. Для каждой из проблем есть свое целевое решение. Зачем тогда нужно code review? Code review нужно для контроля корректности автоматики. Автоматики у нас полно. Она, естественно, сбоит. И нам нужно глазами проверять, что человек при ней сделал неправильно.


Инструменты, о которых мы говорили:


  1. маленькие задачи (от 15 мин до 2ч., max 4ч.);
  2. review apps чтоб контролировать исполнение;
  3. суровый статический анализ, чтоб проверять качество кода и вообще все, что с ним связано;
  4. строгие архитектурные правила, которые будут декларативно описаны, чтобы четко понимать, где и что мы делаем;
  5. глаза человека как самый последний рубеж. То есть пока не пройдет вся автоматика, на review код даже не попадает.

А нужно ли тогда код вообще смотреть, спросите вы? Ответ конечно, ведь нужен контроль некоторых нюансов:


  • корректность имен;
  • проверка гипотез;
  • проверка общей адекватности.

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


Заревьюить доклад своими глазками можно тут :)


А вы что думаете по поводу философского взгляда на code review?


P.S. Как организаторы DUMP`а хотим выразить благодарность Никите Соболеву за классный доклад :) Надеемся увидеться с ним, и с нашими участниками на DUMP 2020 в Екатеринбурге 20 ноября.


Подробнее..

Как я не съездил в Лондон, но поучаствовал в London DevOps Enterprise Summit

08.07.2020 10:20:45 | Автор: admin


С 23 по 25 июня 2020 года в Лондоне прошла очередная DevOps Enterprise Summit. В Лондоне можно написать в кавычках, так как пандемия сделала свое дело и конференция прошла в онлайн-формате. В нём здесь есть и плохое (нетворкинг всё-таки очень сильно страдает), и хорошее: ты можешь передохнуть между докладами вдали от всех людей, ты можешь выделить целиком несколько дней на изучение докладов, которые тебя интересуют, и сфокусироваться эхто вот очень полезно. Буквально недавно я был на митапе в Челябинске, на следующий день в Новосибирске, а еще через несколько дней в Калифорнии: физически сделать это было бы крайне затруднительно. Конечно, существуют записи, но само ощущение выделения времени для обучения, кажется, помогает учиться.

Форматы отчётов о конференциях уже прижились на Хабре, а желание развиваться в условиях, когда сидишь дома, стало особенно сильным (надо же чем-то заниматься) и тут возникает вопрос: конференций много как посмотреть всё, что хочется посмотреть?

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


Что такое DevOps Enterprise Summit? Чем она отличается от других конференций?


Любая статья про DevOps-конференцию, конечно же, должна начаться с рассуждения о том, что такое DevOps, и, конечно же, от этого устали все. Поэтому я постараюсь быть лаконичным!

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

Рискну навлечь на себя гнев за упрощение, но по сути: для разработки привнесение админских методов и возможностей видоизменило процесс самой разработки идеологически и превратило DevOps в новый Agile когда мы слышим о менеджерских конференциях про DevOps, мы слышим об изменениях в методологии разработки. А DevOps Enterprise Summit одна из тех конференций, что имеют полезность для админов: здесь были и доклады ближе к техническим.

Итак, DevOps Enterprise Summit проводится с 2014-го года, и ее организатором является компания IT Revolution с основателем Gene Kim, известного очень многим по книге Проект Феникс. IT Revolution это как раз издательство, запустившее целую серию книг по DevOps и его связи с гибкими методологиями. Почему именно Enterprise? Это особенно важный момент.

Ввести гибкие методологии в небольшой компании просто: в компаниях, состоящих из нескольких человек, они, скорее всего, и так существуют с самого начала просто надо их таким образом назвать. С компаниями в тысячи, десятки тысяч человек всё сильно сложнее. В них существует огромное количество процессов, выстроенных для того, чтобы эта махина продолжала движение, и это можно сравнить с большим кораблем. Когда корабль идёт через океан от одного материка на другой, он выполняет свою роль, но корабль не может в кратчайшие сроки изменить маршрут и сменить курс на этого требуется время, особенно в технологических бизнесах. Молодая компания из нескольких человек может за несколько дней построить прототип того, что компания из тысяч человек будет строить годы если не изменится. Поэтому большие компании хотят меняться и использовать методики молодняка, однако им надо понять, как не порушить свои процессы. Я уже приводил пример в другой своей статье: в Excel 1900-й год считается високосным, и сделано это для обратной совместимости с версиями Lotus 1-2-3, в которых был такой баг. Эти версии были выпущены в 80-х годах и вопрос: нужно ли сохранять эту совместимость? Насколько можно допускать баги в подходе потом исправим, когда ты ставишь ПО в банках на серверы, которые вообще отключены от интернета? Как при этом сохранить ту самую гибкость? Про это и была конференция.

Формат


Каждая конференция пытается выдумывать как перевести себя в онлайн, и это интересно. В DOES можно отметить следующее:

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


Выжимка


  • Конференция фокусируется на практике компаний-Horses, а не компаний-Unicorns говоря по-русски, фокус идет на практику рабочих лошадок, не надутых капитализацией на бирже, а доказавших свою пригодность за годы долгой работы дальше в примерах будут страховая компания, которой сотня лет, крупнейшая в Европе служба доставки и т.д. Можно сказать, что в какой-то мере это анти-хипстерный тренд, когда рассказ идет о том, как новые методологии (и новые технологии) применяются в реальной жизни (вводный доклад от Gene Kim).
  • Важнейшей частью DevOps как методологии является создание коллективной гениальности scenius. Scenius в данном случае противопоставляется единичной гениальности genius, и задача объединения ранее противопоставляющихся друг другу команд, задача организации взаимодействия как раз в том, чтобы, сформировав scenius, выйти на новый уровень решения проблем (вводный доклад от Gene Kim). (см. также medium.com/@stevesargon/steal-like-devops-artist-1-you-dont-have-to-be-a-genius-or-googler-6e9f17c14fb5 и в целом гуглить по слову Scenius.)
  • Каждый второй докладчик говорил о положительном опыте формирования платформенной команды и в целом Platform Engineering, когда гибкая микросервисная архитектура опирается на платформу, предоставляющую основные инфраструктурные сервисы (DevOps Journey at Adidas III, Exploring Data in the Cloud Fernando Cornago VP, Platform Engineering, Daniel Eichten VP, Enterprise Architecture, Adidas и другие). (см. также softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering и в целом гуглить по platform engineering и platform team). Вообще, интересно наблюдать, как методики, которые были приняты довольно давно, вводятся как новые открытия. Платформенная команда это не только инженеры, которые создают платформу, но и консультации и советы по использованию. И команда, которая обладает видением, как платформа будет развиваться (platform advisory/community management/platform operation/platform evolution).


Каждый третий докладчик говорил про формирование DevOps Dojo. На этом стоит остановиться подробнее. Для небольших компаний и отдельных сотрудников кажется очевидной полезность митапов и воркшопов, где люди обмениваются своим опытом. Мы в таком формате создали для SRE-специалистов Uptime community, однако как быть в компании где тысячи, десятки тысяч сотрудников? Dojo слово, пришедшее из японского и в конечном итоге означающее зал, где обучаются боевым искусствам. В DevOps-методологии практику начал использовать огромный американский ретейлер Target, организуя систематически внутри компании воркшопы, митапы, конференции, где сотрудники могут обмениваться между собой набитыми шишками и опытом, и создавая безопасное пространство, где можно заниматься практикой, не боясь ошибиться. См. youtu.be/1FMktLCYukQ


  • Докладчики из Swiss Re швейцарской страховой компании, существующей 156 лет, рассказывали об успешном переходе к DevOps-методологиям на примере их нового сервиса. Трансформацию запускали на трёх конкретных продуктах, во внутреннем стартапе. Отношения к головной компании были как к инвестору у стартапа был собственный CEO, руководящая команда, своя платформа и т.п. Вообще, надо отметить, что, согласно Gartner-у, 76% запущенных DevOps-трансформаций компании оценивают как меньше, чем полпути. И к запуску таких процессов надо относиться с пониманием рисков. Во многих компаниях реалистичные сроки внедрения около пяти лет, и к этому моменту многие практики устаревают или оказываются неактуальными. Главная проблема в том, что к самому процессу внедрения гибкой методологии DevOps-а большие компании приступают с водопадным подходом и с этого начинаются проблемы. В трансформации стоит предполагать итеративность. Другим моментом, приводящим к трансформации, являлась смена визионерской технологической команды: докладчики из Hermes Germany GmbH сказали, что инициативу запустил новый CIO, при этом они как раз выступали против идеи внутренних стартапов, поскольку такой стартап остаётся изолированным и головная компания не меняется.
  • В почти всех успешных кейсах трансформации говорили о важности метрик, по которым определяется эффективность трансформации см. метрики в State of Devops, книге Gene Kim Accelerate.
  • Отдельно мне, как техническому гику, запомнился доклад DevOps And Modernization 2.0 (CSG) от Scott Prugh про историю внедрения методологий DevOps на мейнфреймах. Посмотрите подробнее в детальном описании, но лучше дождитесь появления видео, это потрясающе: миграция и ускорение деплоев кода на Cobol-е, переписывание 3,7 миллиона строк кода на IBM High Level Assembler на Java и еще очень много информации! Вывод: даже в очень сложных инфраструктурах с огромнейшим наследием трансформацию организовать возможно.


Упоминаемые книги, которые стоит прочитать:
Team Topologies in Action, Accelerate: Building and Scaling High-Performing Technology Organizations.

А ещё я чуть более регулярно, чем блог здесь, веду свой телеграм-канал, подписывайтесь :-)
Подробнее..

IT на YouTube что посмотреть в рабочий перерыв

15.09.2020 08:18:15 | Автор: admin


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


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


А сегодня мы в JUG Ru Group запускаем новый сезон разговорных YouTube-шоу, привязанных с нашим IT-конференциям и это как раз соответствует запросу. Поэтому я решил сделать общий пост: и о том, что оказалось с разными форматами IT-видеоконтента, и конкретно о наших передачах. Смело дополняйте в комментариях своими YouTube-рекомендациями, наверняка я не знаю многого крутого.


Околоайтишное


На YouTube всё меряют просмотрами, поэтому я попробовал понять, у каких IT-роликов их больше всего. Это ведь будут самые важные и нашумевшие видео, которые надо посмотреть в первую очередь, так?


Нет, не так. Обнаружил, что в случае с IT лучше всего собирают просмотры такие ролики:


  1. Потребительские: рассчитанные не на айтишников, а на любых пользователей IT-продуктов. Например, выпуски гаджет-каналов, от англоязычного Unbox Therapy до русскоязычного Rozetked.
  2. О программировании, но для тех, кто никогда не программировал. Иногда с кликбейтными заголовками вроде Учим Python за один час!, иногда с корректными вроде HTML для начинающих #1. Показательно, что у ролика HTML для начинающих #2 вдвое меньше просмотров, а у третьего ещё в два раза меньше прямо видно, как зрители забрасывают дело.
  3. Опережая в разы всё остальное: выпуск Дудя про Кремниевую Долину.

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


Но это не значит популярные ролики плохие. Думаю, многим айтишникам интересен канал Linus Tech Tips: он подходит тем, кому нравится не просто покупать гаджеты, а собирать компьютер самостоятельно. А мой личный фаворит в гаджет-сегменте MKBHD, который не вскрывает каких-то неочевидных глубин, но сделан хорошо и радует качеством продакшна (тут 4K-разрешение в роликах реально ощущается).


Видеокурсы, туториалы и тому подобное


Видеокурсов по всем популярным языкам и технологиям на YouTube хоть отбавляй и на английском, и на русском. А для тех, кто хочет не освоить язык/технологию, а столкнулся с каким-то конкретным вопросом формата как пропатчить KDE2 под FreeBSD?, есть короткие ролики, наглядно показывающие процесс.


Насколько такие видео качественные? Судя по виденным мной, всё очень различается ну, неудивительно для площадки, где может публиковаться кто угодно. Что-то сделано случайным человеком на коленке, а что-то очень неслучайным: например, по Java есть вводный курс от Якова Файна, входящим в число Java Champions (ссылки на курс: на русском и на английском). Если знаете особенно крутые каналы рекомендуйте в комментариях, можете кому-то помочь.


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


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


Видеозаписи докладов


Поскольку мы в JUG Ru Group делаем IT-конференции, таких записей видел много. И казалось бы, вот оно: полезный контент, рассчитан на айтишников, не предполагает у зрителя открыта IDE, длится не три минуты Но хотя мне вроде как выгодно расхваливать доклады, честно предупрежу: по-моему, под еду подходит только часть из них.


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



А вот с остальными докладами сложнее по следующей причине: чем они глубже и хардкорнее, тем хуже подходят для обеденного потребления. Когда знаток JVM Андрей Паньгин рассказывает, как Java-разработчики могут создавать плагины для виртуальной машины, уже к пятой минуте от джавистов требуется врубаться в код на C++, и слушать вполуха не получится.


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


YouTube-шоу


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


JS-разработчик MPJ (Мэттиас Петтер Йоханнсон) недавно приостановил свой канал Fun Fun Function. Но в качестве первого примера мне всё равно хочется привести его: он интересен тем, что пробовал самые разные форматы. На этом канале есть сеансы парного программирования, монологи MPJ по разным поводам, обсуждения с гостями вопросов вроде Как нам улучшить процесс code review, десятиминутные объяснения IT-концепций вроде предпочитайте композицию наследованию. Часть контента связана конкретна с JS, часть применима везде.


Ещё из англоязычных IT-каналов вспоминается Computerphile: он о компьютерах, но не в духе разберёмся, как что-то закодить, а в духе разберёмся, как что-то устроено (от SSH до протокола Диффи-Хеллмана). Кроме целых каналов, бывают и небольшие серии видеороликов, рассчитанные на примерно такой же просмотр когда и сколько удобно: например, ролики Себастиана Дашнера о продуктивности разработчика.


А на русском языке популярны, например, АйТиБорода, loftblog и ProgBlog. И вот что объединяет все три этих канала: все они публикуют интервью с айтишниками различных профилей.


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


Наши шоу


Мы в JUG Ru Group делали видеоинтервью на YouTube ещё до того, как это стало модным: за пару лет до появления вДудя наш директор Алексей Федоров начал расспрашивать крутых айтишников на своём канале Без слайдов.


Но Алексей один, а задач у него много, так что часто выпускать Без слайдов невозможно. И в этом году мы зашли с другой стороны: затеяли на YouTube целый ряд разговорных шоу с разными ведущими.


Зачем целый ряд передач, почему было не сделать одну? Проводя конференции для разных областей IT (от C++ до тестирования), мы видим, что везде кипит своя жизнь: у дотнетчиков одни темы и герои, у фронтендеров другие. Поэтому у разных наших конференций разные шоу, и у каждого в гостях те люди, которые известны в соответствующем профессиональном сообществе.


Если для вас это звучит интересно, можете посмотреть записи прошлого сезона, я выбрал для разных направлений по одному примеру:



Формат интервью у нас основной, но не единственный. В случае с JS гостям предлагали не только поговорить про IT, но и покодить прямо в эфире (а то и рассказать про косметику, всякое бывает). Ещё среди нашей деятельности передача о тестировании Ошибка выжившего, где ведущие тоже горазды в прямом эфире запилить тулзу. А для джавистов мы устраивали онлайн-митап с Евгением Борисовым (Spring-построитель).


Новый сезон наших шоу


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


Вот три выпуска открывающего дня:


  • Для JS-разработчиков: в 10:00 вернётся шоу Тяжёлое утро с HolyJS. Первый выпуск нового сезона будет о самой конференции HolyJS: вспомнят июньскую, поговорят о том, чего ждать от ноябрьской, и пройдутся по новостям индустрии.
  • Для тестировщиков и не только: в 13:30 гостями выпуска Heisenbug Show станут Виталий Брагилевский и Иван Пономарёв, чтобы поговорить о высшем образовании в IT. В этот раз тема выпуска получилась довольно универсальной, так что интересно должно быть не только зрителям конференции Heisenbug.
  • Для .NET-разработчиков: в 19:00 в новом выпуске шоу Барная стойка будет Дмитрий Сошников, известный дотнетчикам своими докладами про F#, ML и всё вокруг этого.

А впереди другие передачи: по средам будет Java, по четвергам C++, по пятницам devops. Чтобы не пропускать интересные выпуски по вашей теме и заранее знать их темы, можно подписаться на соответствующую рассылку: Java, C++, тестирование, .NET, JS, devops.

Подробнее..

Тестирование со всех сторон о чём расскажут на Heisenbug

08.10.2020 18:22:32 | Автор: admin


Программа конференции Heisenbug готова, настало время представить её Хабру. Понятно, что там расскажут о тестировании, но как именно? Среди блоков программы инструменты тестирования, нагрузочное тестирование, тестирование веба и мобильных приложений, даже ИИ. А кроме докладов, будет ряд воркшопов так что можно будет не только слушать, но и практиковаться.


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


  • чем интересна тема,
  • чем ценен спикер,
  • кому будет полезно,
  • почему стоит слушать это здесь и сейчас.

А вот блоки, на которые можно поделить программу:


AI
Инструменты
Нагрузочное тестирование
Визуальное тестирование
Web
Бэкенд
Мобильные приложения
Не только тестирование: вокруг Heisenbug


AI


Конечно, ИИ далеко не самое частое, с чем сталкиваются люди в тестировании. Но начнём с этой темы, потому что по ней выскажутся два особенно заметных спикера:


The role of testing in the age of AI, James Whittaker


Джеймс известен прежде всего как автор книг и визионер в тестировании. Одна из самых известных его книг Как тестируют в Google. Помимо Google, он работал в других гигантах вроде Microsoft, где получил титул Distinguished Engineer. В общем, этого человека интересно послушать, о чём именно он бы ни говорил.


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




Искусственный Интеллект и Справедливость: как ловить баги мироустройства?, Иван Ямщиков


Иван раньше выступал на Heisenbug с докладом Что общего между тестированием и анализом данных, и тогда получил отличные отзывы. Теперь он вернётся: как и Джеймс Уиттакер, выступит с обзорным докладом по теме ИИ, но с другого ракурса. Какими должны быть законы, которыми подчиняется ИИ?


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




Инструменты


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


TMS в Agile команде. Твой верный друг, Игорь Голдшмидт


У вас уже несколько проектов в Agile-команде, вы быстро растете, а QA-процессы не успевают за вами? У вас уже несколько команд и вы работаете над кросс-проектами? Старые инструменты не справляются, и вы чувствуете, что готовы к чему-то большему?


Тогда вам нужен инструмент для организации и автоматизации процесса тестирования. Самое время задуматься о системе управления тестированием (TMS). Но как ее успешно внедрить? Когда и как нужно интегрировать ее с автотестами? Какая функциональность критична, а какая нет? Нужна ли возможность взаимодействия с другими командами? На все эти вопросы Игорь постарается ответить вам в своем докладе. На примере своей истории и опыта работы с TestIT.


Чем интересна тема: Хранение тест-кейсов достаточно холиварная тема, TMS пользуются все, даже если она не нужна вообще.
Кому будет полезно: Тем, кто работает с системой хранения тест-кейсов, находится в процессе выбора ТМС или хочет понять: может ли быть что-то лучше, чем Excel.




Типы автоматического тестирования в IntelliJ IDEA, Юрий Артамонов


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




Ultimate end-to-end testing, Николай Голубев


Николай один из главных соавторов фреймворка webtau (сокращение от web test automation).


Цель этого фреймворка предоставить API (возможно REPL и runner) для тестирования на таких уровнях, как HTTP, Web UI, DB, CLI с согласованным API, отчетностью об охвате и расширяемостью.


Фреймворк имеет DSL, чтобы помогать вам писать кратко и надежно.


В этом докладе Николай хочет показать, как использовать webtau для тестирования приложения магазина игр, которое имеет веб-интерфейс, REST API, GraphQL и CLI-интерфейс. У webtau также есть новая (недавно выпущенная) концепция Persona для упрощения сценариев авторизации при тестировании. Еще его можно использовать для управления несколькими браузерами одновременно для тестирования веб-сокетов.


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


Чем интересна тема: Целостный и лаконичный тестовый фреймворк это всегда интересно. Особенно если он бесплатный и с продуманным подходом написания браузерных тестов.
Кому будет полезно: Тем, кто страдает от написания Selenium-тестов (например, из-за того, что тест невозможно начать выполнять со второй половины).




Автоматизация CI/CD. Управление ордой Jenkins-джобов, Вячеслав Лукашевич


Чем интересна тема: За годы своего существования Jenkins оброс большим количеством возможностей, из-за чего правильно готовить его для нетривиальных задач не всегда просто. Вячеслав в своём докладе покажет, как это делается в организации с десятками проектов и сотнями Jenkins-пайплайнов.
Чем ценен спикер: Работая на должности QA Architect в компании Evolution Gaming, Вячеслав имеет дело с крупной инсталляцией Jenkins, большой командой разработчиков, создающих десятки merge requests в день, и успешно справился с задачей перехода от двухнедельного релизного цикла к ежедневному.
Кому будет полезно: Тестировщикам и разработчикам, которые имеют дело с Jenkins и хотят прокачать свои знания.




System testing of RabbitMQ: Tooling + Practices + Lessons Learned, Jack Vanlightly


Чем интересна тема: Тестирование распределённых систем это высший пилотаж. А когда речь заходит о тестировании такого известного продукта, как RabbitMQ, это становится интересно вдвойне.
Чем ценен спикер: Джек специалист в области распределённых и messaging-систем.
В 2019 году на Heisenbug Джек рассказывал, как с помощью методов формальной верификации он находил баги в протоколе репликации Kafka, а теперь будет делиться своим опытом тестирования и оптимизации RabbitMQ.
Кому будет полезно: Тестировщикам и разработчикам, которые хотят развиваться в сторону распределенных систем.
Почему здесь и сейчас: Джек делает доклад специально для Heisenbug, чтобы рассказать о своем опыте последних полутора лет работы в RabbitMQ core team в Pivotal.




Артём Ерошенко тема уточняется



Артём (слева) и Всеволод Брекелов


Тут случай, когда достаточно назвать фамилию человека, чтобы многим уже стало интересно. Кто-то знает Артёма как автора Allure Framework. Кто-то как спикера с отличными докладами (и про тот же Allure), и не только). Кто-то как ведущего нашего YouTube-шоу Ошибка выжившего.


В общем, мы ещё уточняем, о чём Артём расскажет в этот раз, но уже уверены, что зрители у этого доклада будут.




Воркшоп: Как начать свой проект автоматизации с нуля (с божьей помощью и Selenide), Андрей Солнцев


Андрей расскажет, как создать свой проект с нуля и завести несколько базовых тестов.


Чем интересна тема: Практически каждый проект нуждается в автоматизации, но многие обходятся без нее из-за нехватки знаний. При этом каждый автоматизатор написал как минимум один проект с автоматизацией тестирования, но сделал ли он это правильно?
Чем ценен спикер: Андрей автор Selenide, приверженец TTD, поэтому он идеальный кандидат для рассказа о построении фреймворка на Selenide.
Кому будет полезно: Воркшоп отлично подойдёт для тех, кто сомневается о переходе с Selenium на Selenide, а также для тех, у кого нет автоматизации на проекте.
Начинающие научатся легко за несколько часов делать основу для дальнейшего написания тестов, уже умеющие узнают нюансы используемых технологий.
Почему здесь и сейчас: В воркшопе надо было участвовать несколько лет назад, чтобы сейчас у всех была автоматизация. Вышли новые версии JUnit, Selenide, Allure, которые сделали этот процесс простым как никогда, а с учётом увеличения скорости разработки нам надо уменьшать временные затраты на одни и те же действия руками. Пора учиться делать автоматизацию.




Воркшоп: Покрытие кода в JVM, Евгений Мандриков


Наверняка всем известна фраза нельзя управлять тем, что нельзя измерить. Но что же она означает, когда речь идет про измерение покрытия кода? Может быть речь идет про управление процессом разработки? А может про автоматическое (и не очень) тестирование? Или может вовсе не про тестирование?


Евгений поможет разобраться с тем, какие бывают метрики покрытия кода, зачем они нужны, когда и как их можно измерять. Вместе мы рассмотрим примеры использования одного из самых популярных на сегодняшний день инструментов сбора информации о покрытии кода в JVM JaCoCo. Вы узнаете о различных принципах использования от Java и Kotlin до экзотических JVM-языков, от интеграции с IDE (IntelliJ, Eclipse), различными системами сборки (Gradle, Maven, Ant), системами непрерывной интеграции и контроля качества (Jenkins CI, SonarQube), вплоть до JaCoCo APIs. А также научитесь избегать распространенные ошибки.


Чем интересна тема: Покрытие кода вечная тема. Особенно для разработчиков, особенно когда все стараются толкнуть тестирование влево (Shift-Left).
Чем ценен спикер: Женя съел целую стаю собак на тонкостях и нюансах покрытия кода, инструментах вокруг этого, и разрабатывает небезызвестный SonarQube.
Кому будет полезно: Разработчикам и тестировщикам, которые озаботились покрытием своего кода тестами и уже столкнулись с некоторыми интересными ситуациями.
Почему здесь и сейчас: Эволюция в JVM теперь идет намного быстрее, и сюрпризы появляются чаще и чаще.




Нагрузочное тестирование


Нагрузочное тестирование игрового сервера, Антон Поцюс


Нагрузочное тестирование в играх обширная и в то же время малоизученная тема. Цель доклада поделиться опытом создания собственного инструмента на основе Vert.x и Kotlin coroutines для нагрузочного тестирования бэкенда мобильных игр студии IT Territory.
Чем интересна тема: Многие (если не все мы) играем в игрушки, а тестирование игр вообще отдельная техножесть, и это всегда интересно.
Чем ценен спикер: IT Territory делает игры уже очень давно и знает в этом толк.
Кому будет полезно: Тем, кто тоже тестирует игры с клиент-серверной архитектурой, тем, кто играет в игры, и всем кому интересно, как устроены игры под капотом.




Воркшоп: Стартуем в тестировании производительности, Сергей Махетов


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


Создадим тест с нуля на Jmeter. Пошагово сделаем базовый запрос, рассмотрим способы задания профиля нагрузки, метрики тестирования, предоставление отчетов (консоль, графический интерфейс, HTML-отчет, отчет в Grafana). Потестируем HTTP, JDBC, JMS. Рассмотрим, какими способами можно формировать данные для запроса: статика, генерация, извлечение из предыдущего запроса, чтение из файла. Сделаем тест с использованием других приложений, допустим Gatling и Apache Benchmarking tool, поговорим в общем об утилитах тестирования производительности.




Воркшоп: Встраивание в CI тестирования производительности, Сергей Чепкасов


Сергей покажет, как встроить тестирование производительности в ваш CI на основе GitLab CI. Вместе напишем скрипты на Gatling по различным протоколам и поднимем всё необходимое для тестирование окружение (Vector, Loki и т.д.). Также произведем быстрый анализ результатов производительности и поиск узкого места в приложениях.
Чем интересна тема: Кто делает нагрузочное тестирование молодцы, а кто встраивает в CI сообще красавцы.
Чем ценен спикер: Сергей наладил CI + нагрузочное тестирование + анализ в Тинькофф банке.
Кому будет полезно: Тем, кто сходил (или собирается) на воркшоп Сергея Махетова. Тем, кто уже представляет, как делать нагрузку, и хочет поставить её на поток.




Визуальное тестирование


Advanced automated visual validation testing, Shweta Sharma


Чем интересна тема: без визуального тестирования приложений далеко не уедешь, ведь CSS может случайно поехать и всё, сайт развалился.
Кому будет полезно: тем, кто пишет веб-приложения. Научитесь использовать инструменты визуального тестирования и станете пропускать меньше багов.
Почему здесь и сейчас: в 2020 году недоступный сайт страшен как неизвестно что.




Знакомство с визуальным тестированием при помощи Visual Regression Tracker, Павел Стрункин


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




Чем ценен спикер: Павел создал свой инструмент для визуального тестирования, работающий в докере и выложил в open-source. Павел имеет богатый опыт выступлений.
Кому будет полезно: Тестировщикам, выбирающим инструмент для решение задачи visual testing и управления результатами.
Почему здесь и сейчас: Опенсорс-инструменты для визуального тестирования, с помощью которых можно работать на собственном сервере в intranet, не распространены широко. Tracker бесплатный и активно разрабатывается.




Web


Воркшоп: Изучаем WebdriverIO, Александр Хотемской


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




Чем интересна тема: Потребность в тестировщиках, умеющих в JS, растёт год от года, веб-приложения становятся всё сложнее. Материал от Александра поможет начать разбираться в тонкостях построения автоматизированного тестирования на JS.
Чем ценен спикер: Александр евангелист JavaScript-тестирования и один из самых активных участников JavaScript testing community.
Кому будет полезно: Тем, кто уже имеет опыт программирования на JS и других языках и кто хочет получить практический опыт в разворачивании современной тестовой инфраструктуры в экосистеме JS.




Flaky tests. Метод, Андрей Солнцев


Продолжение саги про моргающие тесты: в 2017 Андрей выступал на Heisenbug с докладом Flaky tests, можно почитать расшифровку на Хабре.


На этот раз будет меньше видео и больше логики: в каком порядке вещи должны случаться и что бывает, когда порядок нарушается. На десерт Андрей расскажет про общий метод решения flaky-тестов.




Чем интересна тема: Нестабильные UI-тесты это огромная проблема. Почти всегда непонятно, почему это происходит, а иногда это выглядит как магия. Эта версия доклада содержит демонстрации основных проблем и способы их решения.
Чем ценен спикер: Андрей автор Selenide и знает, как там всё работает. Также у Андрея большой опыт написания UI-тестов с его использованием, что позволяет ему определять, где проблема это технические ограничения фреймворка, а где особенности тестируемого продукта.
Кому будет полезно: Флаки-тесты появляются рано или поздно у всех, особенно когда мы используем ajax-запросы и динамическую подгрузку элементов.




Бэкенд


ORM-подход к тестированию микросервисов, Роман Романюк


На летней онлайн-конференции, в 15-минутном интервью, Роман уже рассказывал про проблемы тестирования большого количества микросервисов малыми силами и про отсутствие единого подхода. Он также затронул тему подходов внутреннего фреймворка Wargaming Arsenal Platform. В этот раз он продемонстрирует его в работе, и вы сможете опробовать его возможности.


Мы поговорим о:


  • необходимости построения модели/роли сущности, если это нужно;
  • построении связей между ролями/моделями сущностей через транспорты (HTTP, AMQP, DB, т.д.);
  • зачем вообще описывать модель данных и что дает преобразование полей модели;
  • как это будет выглядеть в тестах и как у вас будет появляться набор параметризованных смоук-тестов на лету;
  • как повлияет подобный подход на атомарность и гибкость в случае изменений бизнес-требований.

Технологический стек: Python, HTTP, AMQP, SQL, pytest. Доклад будет интересен, в первую очередь, тем людям, кто часто работает с тестированием микросервисов, и им кажется, что понять связь их тестов с проектом человек со стороны не сможет.




Серверный античит: Панацея или рудимент?, Евгений Ченцов, Евгений Крутских


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


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


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




Мобильные приложения


Практики автоматизации мобильных приложений, Дмитрий Макаренко


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


В докладе Дмитрий расскажет про опыт автоматизации мобильных приложений в Badoo. А также поделится практиками как ускорить создание, увеличить стабильность и облегчить поддержку тестов для разных платформ (iOS и Android). Доклад спикера актуален для тех, кто уже занимается автоматизацией мобильных приложений, и для тех, кто собирается заниматься ей в будущем.


Кому будет полезно: Тем, кто переводит тесты на мультиплатформенные рельсы.


Не только тестирование: вокруг Heisenbug


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



Мы проводим сезон из целых 8 конференций на разные темы от Java-разработки до DevOps. И хотя они рассчитаны на разную аудиторию, мы видим, что многим людям интересны некоторые доклады с соседних конференций: часто бывают смежные темы.


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


Если вам интересен Full Pass, можно перейти на сайт со ссылками на программы всех конференций.


А если только Heisenbug тут вся информация и билеты на его сайте.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru