дэн абрамов кто такой
Дэн Абрамов: что я выучил после почти двух лет работы в Facebook?
Хочешь больше книг по программированию?
Подпишись на наш канал и ознакамливайся бесплатно!
Сложно выделить что-то конкретное, поскольку я учусь каждый день. Но вот несколько вещей (порядок неважен).
1. Быть хорошей командой с хорошим менеджером важнее работы над конкретными проектами.
Проекты приходят и уходят, успешные или нет. А вот люди, с которыми ты работаешь, которые делают эти годы твоей жизни особенными, имеют большое значение. И показать все лучшее, на что ты способен в работе, ты можешь только в атмосфере честности, взаимной поддержки и уважения.
2. Большие переделки часто неудачны.
Если ты хочешь заменить какой-то старый код для решения определенных проблем, тебе для этого понадобится стратегия постепенной адаптации. Переписывая вслепую, на скорую руку, ты можешь создать гораздо больше проблем чем надеялся решить. Особенно если не сам писал оригинальную версию.
3. Большие переделки могут быть и успешными.
Предыдущий пункт часто повторяют как закон, но он таковым не является. Ты можешь полностью заменить большой кусок кода (как мы сделали с React 16), если у тебя есть хороший набор тестов по интегрированию, а также способ отправить новую реализацию для подмножества вида продукта подмножеству пользователей. Мы собираемся в скором времени опубликовать пост об этом в Facebook Engineering Blog.
4. Тесты для библиотек в идеале должны быть написаны поверх открытых API.
Это идет вразрез с распространенной мантрой о модульном тестировании. По нашему опыту это помогает убедиться как в том, что тестируются правильные вещи, так и в легкости замены базовой реализации. Но это также делает отказы программ во время отладочных тестирований более сложными.
5. Для очень сложного кода фаззинг может подойти лучше, чем модульное тестирование.
Если код, который ты тестируешь, должен справляться со многими неожиданными случаями, которые сложно предугадать, может быть лучше написать тесты в недетерминированной манере. Входные данные будут генерироваться случайным образом, а исходящие – проверяться на соответствие определенным условиям.
6. Думай о коде заблаговременно.
Думай о том его варианте, который существует сейчас, и о том, как он будет развиваться. Думай о том, что шаблон, который ты представляешь в базу кодов, может быть скопирован и вставлен в любом другом месте. И о том, что код, на совершенствование которого ты потратил столько времени, в любом случае будет удален. Думай о том, как добавленный тобой хак будет задерживать команду в долгосрочной перспективе, и как он же ускорит процесс в краткосрочной. Речь идет о компромиссах, а не о правилах. Мы все время идем на компромиссы и всегда должны думать, что делаем. Как чистый, так и грязный код могут помочь или помешать в достижении твоих целей.
7. Мы не обязаны быть супер умными.
Если, конечно, ты не строишь космический корабль, тогда да. Но что касается обычной веб-разработки, я думаю, это правда. Я волновался, когда не мог понять что-то в коде, и думал, что я тупой. Сейчас я тоже так думаю, но знаю, что это не моя вина. Это значит, что код структурирован неправильно, или покрытие теста недостаточно хорошее, или я не положил логи консоли в правильное место, чтобы визуализировать произошедшее. Мы не должны знать все. Но мы должны знать, когда нужно создать инструменты, позволяющие расширить наше понимание и научиться исследовать код, который мы не понимаем. Даже если это наш собственный код.
8. Используй двоичный поиск и научный метод.
Не буквально в коде, а в своем подходе к нему. Есть баг между точками А и В? Поставь лог между ними, посередине. Баг между А и серединной точкой? Поставь еще лог между ними. Что-то не то с входящими данными? Исключи половину из них. Работает? Попробуй другую половину. И так далее. Отладка может казаться очень прихотливой, но она проста, когда делаешь ее механически. Исследуй, сформулируй гипотезу, найди способ проверить ее, повтори. И обрезай вещи наполовину, когда их слишком много.
Хорошо, что создатель вашего любимого инструмента не слушал ослов, когда изобретал велосипед
Прошлым летом мы с пацанами рассказали про свою либу, которую наш заказчик не принял и выкинул на помойку. Мы бомбили, потому что верили в свое решение, и рассказали о нем сообществу — уж обычные-то разрабы точно заценят и не будут размениваться на всякую чушь.
Ну конечно. Нас буквально смыло волной критики. Там было много людей, которым не нравится мое самомнение и я лично — это ок, с ними у меня нет проблем. Меня взбесили вроде бы умные люди, которые даже не захотели смотреть в код и вникать в контекст, потому что с порога заявили: «Вы, парни, сделали велосипед». И все подхватили — изобретать велосипеды плохо, ужасно, кошмарно, недопустимо, позор, казнить их, линчевать. Ведь, только идиот будет разрабатывать новый инструмент для задачи, которую кто-то уже решил.
Меня поражает насколько быстро разрабы ведутся на эту уловку. Я спрашивал даже самых критичных и глубоко думающих людей — “изобретать велосипеды плохо?”. Они отвечают “да” меньше чем через секунду.
Ну нет, мужики, так не пойдет. Давайте-ка остановимся здесь, посмотрим вокруг и обстоятельно порассуждаем.
Однажды я довольно долго делал фронтенд приложение дома. Я использовал реакт, но не брал либы для управления состоянием — у меня не было такой проблемы. Потом проблема появилась, и я начал делать «свой велосипед». Умные дяди сказали мне, что я идиот, и надо брать Redux. Я взял.
Через два месяца большая часть кода проекта была адаптацией редакса к моей архитектуре. Этот инструмент создал мне намного больше проблем, чем решил. Не потому что редакс плохой — он просто не подходил.
Человек из большой корпорации сделал решение для работы с состоянием веб приложения большой корпорации. Редакс решает кучу проблем, которые стоят перед таким приложением, и делает это хорошо. И что делает индустрия? Индустрия говорит — Дэн Абрамов дал нам путь. Теперь мой сайтик на две формы будет использовать редакс для работы с состоянием.
Друг, редакс сделан для работы с состоянием — но не с твоим состоянием. Тебе блин не нужен персистентный чейн всех слайсов стейта приложения, ты не передаешь экшны по сети и не делаешь ещё много чего такого, что должен автоматизировать редакс. При этом, использовать редакс непросто. Тебе придется нагородить сто километров кода на то, чтобы объяснить редаксу, какое у тебя состояние, где и как оно обновляется, какие изменения значимые, а какие нет. Чтобы редакс автоматизировал тебе проблему, которой у тебя не было. Серьезно, вы видели хотя бы одну вакансию на реакт, но без редакса? Я нет.
Есть аналоги — но они такие же громоздкие. Иногда самый дешевый способ решить проблему — не взять инструмент для всего, а написать доменное решение, которое хорошо подходит именно тебе. Мой бог, typescript достаточно мощный ЯП, чтобы за пару часов написать себе базовый мввм, мвц, или вообще любой мв, который ты хочешь — так, чтобы он решал только те проблемы, которые у тебя есть. Сделать его выйдет дешевле и быстрее. И возможно, твое решение сработает круто, вырастет вместе с проектом, и станет стандартом.
Но это запрещено — потому что другие разрабы тебе сказали: “парень, не изобретай велосипед. Просто возьми самое популярное на рынке”.
В моем проекте, например, больше подходил MobX, но тоже не супер. Лучше всего у меня бы сработал именно изобретенный мной велосипед. Но у меня как будто отняли право принимать хорошее решение, ведь что бы я ни сделал — никто даже не стал бы слушать. Никто не готов поверить, что получится лучше и дешевле.
Это порождает замкнутый круг. Если все будут использовать только изобретенное до них, то прогресс в разработке остановится. Тебе скажут, хочешь сделать лучше, чем в готовом — делай дома в свободное время. Ты говоришь ок, начинаешь работать ночами, доделываешь, идешь рассказывать о своем решении людям, но никто не готов даже смотреть ему под капот — “это же велосипед”.
А на самом деле все, что мы делаем — это изобретаем велосипеды. “Велосипед” — это просто вредная риторическая уловка, чтобы оправдать свою лень или самоутвердится в споре с другим разрабом.
Создатели редакса, реакта и мобикса — они ведь тоже «делали свой велосипед». Ну а что, разве к моменту появления ангуляра у нас не было библиотеки для работы с браузерным UI? JQuery, Knockout? Это тоже велики, кстати. Ведь всегда был ванила js и браузерное API. Так зачем эти идиоты решали решённую проблему?
Дуглас Крокфорд изобрёл JSON. Некомпетентный болван похоже не знал, что у нас уже есть XML. Программисты задолго до него изобрели способ обмена данными, кем он там себя возомнил вообще?
Плохие примеры? Ну конечно. Ведь в ваших головах люди из больших корпораций имеют право изобретать велосипеды. Они имеют, а я и вы нет.
Самое энтерпрайзное ИТ в РФ — это банки. И если вы посмотрите на технические продукты всяких Сберов, Тиньковых или Альф, увидете — у них у всех одни и те же приложения с примерно одним и тем же дизайном. Это почти одинаковые системы. Одинаковые для пользователя, они сделаны по-разному, на разных стеках, разными людьми. У всех этих банков свои уникальные подходы к разработке. У мировых ИТ гигантов так же очень много одинаковых продуктов. Когда большие банкиры собираются и решают, что им нужны цифровые продукты, они нанимают армию разрабов и заставляют их делать все то же, что уже делали другие банки, в сотый раз — но по-новому.
Это всё — велосипеды.
В каждом проекте, над которым я работал были долгоживущие проблемы, потому что что-то не было автоматизировано. Потому что когда-то кому-то сказали — не изобретай велосипед, просто закрой тикет. Да, бизнес ждёт своих тикетов, и ему нужно их скармливать, но давайте по-честному — я отлично знаю, что у нас всегда больше бюджета, чем думает бизнес.
У меня все просто с деньгами бизнеса, которые я на это трачу. У большого бизнеса много денег, и он их вбухивает в разработку. Эту огромную кучу денег могут потратить разработчики, которые решают задачи, и при этом ведут какие-то исследования. А могут потратить менеджеры, но менеджеры потратят их чтобы оплатить наше бессмысленное сидение на миллионах никому не нужных совещаний. Бизнес уже потратил деньги на разработку, и если ты их не превратишь в программирование, то бизнесовые прихвостни потратят их на свои дурацкие процессы, которые не нужны никому кроме них самих.
Я достаточно насмотрелся на чуваков, которые «работают» по 18 часов в сутки. И я хорошо знаю, если ты просидел в офисе 18 часов, реально работать ты будешь столько же, как если бы сидел 8.
Наша коллективная манера обманывать бизнес объясняется очень просто — он не шарит. Бизнес не понимает, почемы мы должны две недели не делать фичи, а приводить в порядок легаси. Это нормально, и мы умеем это резолвить. Ты полдня работаешь на бизнес, а полдня работаешь на проект. Пришёл на работу, закрыл дневную норму — всё, у тебя картбланш на исследования.
Пока мы решаем практические, сиюминутные хотелки бизнеса — он готов нам оплачивать настоящую работу. На самом деле настоящая разработка начинается там, где есть программирование ради программирования. Когда ты упиваешься чистой механикой ради гребаного ничего, сиюминутного щелчка и инженерного восторга, потому что только так раздвигаются границы, появляются новые способы и инструменты, чтобы снова решать практические задачи, только лучше.
Когда я что-то разрабатываю, что-то такое, что уже сделано, я не перепридумываю это точь-в-точь как у них. Я придумываю свой подход. Он всегда чем-то лучше, всегда чем-то хуже. И это всегда изобретение. Подавляющее большинство моих изобретений отправиться на свалку истории, но всегда есть шанс, что я изобрету что-то действительно крутое. Пусть даже мимоходом, пусть я сам не придам этому значения — не важно. Кто-то увидит, заюзает где-то ещё, индустрия получит новый стандарт, который начнёт решать наши проблемы. Только эта идея двигает меня на написание кода.
В опенсорсе тоже много одинаковых проектов. Таких, которые решают одну и ту же проблему. Вы готовы сказать, что все кто их делает — дураки? Я не готов. Когда я хочу заюзать либу для сериализации, я получаю пять-шесть топовых решений, каждое из которых имеет уникальные преимущества. Иногда одно из этих преимуществ для меня критично, в такие моменты я полон благодарности парням, которые решили сделать этот «велосипед».
Когда мне говорят, что в разработке всё уже изобретено, я спрашиваю: «а что, разве у нас не осталось проблем?».
Разве не мы пишем бойлерплейт изо дня в день? Разве не мы раз за разом не вывозим автоматизацию, когда наполняем свои файлы однотипным кодом? Мы всё ещё делаем очень много того, что уже сейчас могла бы делать машина. И делаем это потому, что ещё не изобрели подходов, потому что вечно вставляем палки в колеса велосипедов.
Рубрика «Dan Abramov»
Новое API React: Suspense (ру субтитры, с выступления Дэна на JS Conf)
Дэн Абрамов рассказывает о «будущем» API — Suspense. По ходу презентации он описывает две проблемы:
которые позволяет решить новое API.
P.S. Видео под катом, не забудьте включить субтитры.
Идиоматичный Redux: Дао Redux’а, Часть 1 — Реализация и Замысел
Мысли о том, какие требования выдвигает Redux, как задумано использование Redux и что возможно с Redux.
Введение
Я потратил много времени, обсуждая онлайн паттерны использования Redux, была ли это помощь тем, кто изучает Redux в Reactiflux каналах, дискуссии о возможных изменениях в API библиотеки Redux на Github’е, или обсуждение различных аспектов Redux’а в комментариях к тредам на Reddit’е или HN (HackerNews). С течением времени, я выработал свое собственное мнение о том, что представляет собой хороший, идиоматичный Redux код, и я хотел бы поделиться некоторыми из этих мыслей. Несмотря на мой статус мейнтейнера Redux’а, это всего лишь мнения, но я предпочитаю думать, что они являются достаточно хорошими подходами 🙂
Redux, в своей сути, невероятно простой паттерн. Он сохраняет значение, выполняет одну функцию для обновления значения когда это необходимо, и уведомляет любых подписчиков о том, что что-то изменилось.
Несмотря на эту простоту, или, возможно, вследствие ее, существует широкий спектр походов, мнений и взглядов о том, как использовать Redux. Многие из этих подходов широко расходятся с концепциями и примерами из документации.
В то же время, продолжаются жалобы на то, как Redux «заставляет» вас делать вещи определенными способами. Многие из этих жалоб на самом деле включают концепции связанные с тем, как Redux обычно используется, а не фактическими ограничениями наложенными самой библиотекой Redux. (Например, только в одном недавнем HN треде я видел жалобы: «слишком много шаблонного кода», «константы action’ов и action creator’ы не нужны», «я вынужден редактировать слишком много файлов чтобы добавить одну фичу», «почему я должен переключаться между файлами чтобы добраться до своей логики?», «термины и названия слишком сложны для изучения или запутанны», и слишком много других.)
Развёрнутый комментарий Дэна Абрамова к статье «Вещи, о которых никто вам не расскажет про React»
Всем привет! Недавно Дэн Абрамов, создатель Redux, оставил довольно массивный комментарий к статье на Medium Things nobody will tell you about React.js, который очень быстро разошёлся популярностью и довольно скоро набрал раза в 3 больше рекомендаций, чем сама статья 🙂
Собственно, текущая статья является моим переводом его комментария, так как последняя содержит ценные замечания по поводу актуального и будущего состояния React / React Router.
Надеюсь, кому-то это будет полезным.
Привет, спасибо за обратную связь! 🙂
Я ценю, что вы поделились своим неприятным опытом работы с React.
Ваш пост содержит широко распространенные в React сообществе заблуждения, поэтому мне захотелось воспользоваться моментом и разъяснить их для любого, у кого имеются те же проблемы.
Это вовсе не означает, что React для всех работает одинаково хорошо, или что затронутые вами проблемы неактуальны. Но есть несколько моментов, которые, на мой взгляд, важно обозначить для правильного понимания этих проблем.Читать полностью »
Профессия Фронтенд-разработчик (frontend developer): Кто это? Чем занимается? Разбор профессии
В этой статье вы узнаете все подробности о профессии фронтенд-разработчика: что нужно знать, где и как обучаться, где можно работать и за какие деньги. Также в этой публикации мы подготовили для вас подборку онлайн, офлайн курсов и вузов, которые помогут добиться совершенства во фронтенде. А на десерт вас ждет большая подборка полезных бесплатных материалов.
Кто такой фронтенд-разработчик? Обязанности, чем занимается
Фронтенд-разработчик (frontend-developer) —программист, который занимается внешней, клиентской частью сайтов и приложений, отображающейся в браузере. То есть интерфейсом (users/usinginterface) и юзабилити: менюшками, фильтрами, кнопками, анимацией, формами, галереями, интерактивом, рекламными блоками и т.д. Он отвечает за корректную работу всех этих элементов веб-ресурса.
Результат работы этого специалиста играет одну из ключевых ролей в SEO продвижении сайтов и их популярности у ЦА. Он отвечает за верстку, реализацию функционала — все то, что напрямую влияет на пользовательский опыт и привлекательность площадки.
Иногда фронтенд-разработчик занимается и первичной структурой сайта. Результат его работы — удобный, быстрый сайт с тем самым интуитивным интерфейсом и ярким оформлением, соответствующим ожиданиям и потребностям пользователя.
Обязанности фронтенд-разработчика направлены на создание функционального интерфейса, который обеспечит положительный пользовательский опыт:
Фронтенд-разработчик закладывает костяк веб-ресурса по макетам веб-дизайнера, прорабатывает оформление, занимается организацией и отладкой программного кода, устраняет неточности и баги, автоматизирует проект. Он отвечает за соответствие результата задумке, за то, чтобы во всех браузерах ресурс выглядел одинаково презентабельно и работал как надо. В целом, фронтенд-разработчику нужно иметь представление о веб дизайне и верстке.
Что нужно знать
Условно выделяют два вида фронтенд-разработчиков:
Независимо от этой классификации, чтобы добиться успеха в этой отрасли, нужно уметь очень много:
Если прямо углубляться, желательно знать OOCSS / BEM / SMACSS, Python, пригодится работа с объектами DOM, API, AJAX и CORS, понимание SVG, HTML5 API, ECMAScript 6, инструментов дебаггинга в духе ChromeDevTools и Firebug, баз данных и языков запросов MongoDB, SQL, MySql и т.д.
Это в идеале. Основное, что должен знать фронтенд-разработчик — конечно, HTML, CSS и JavaScript. Дополнительные инструменты и сервисы, которые нужно изучить, зависят от ниши фронтенда, которую вы выбрали.
Если разбить требования к знаниям по уровням:
Зарплата и востребованность
Программист — одна из самых востребованных профессий. И фронтенд-разработчик — весьма популярная и хорошо оплачиваемая позиция.
Средняя зарплата фронтенд-девелопера на начало ноября 2020 года, по данным портала russia.trud.com, составляет около 92 тысяч рублей.
Средняя зарплата по уровням и скиллам:
Обращаем ваше внимание: требования от вакансии к вакансии разнятся и их спектр довольно широк. Может потребоваться умение работать в командной строке Unix-систем, быстро разбираться в чужом коде и много чего еще.Уровень зарплат варьируется в зависимости от региона, страны и, естественно, ваших навыков и специализации. В России выше всего заработок фронтенд-разработчика в Москве — от 40 тыс. руб. для джуниоров.
В среднем для этой профессии (в рублях):
В регионах — от 50 000 и выше, например, в Екатеринбурге можно найти зарплату от 50 до 100 тыс. руб., во Владивостоке — от 40 до 150 тыс. руб., в Краснодаре — от 50 до 150 тыс. руб.
В целом, в России ЗП фронтенда колеблется в пределах 40-150 тыс. руб., в Москве средняя зарплата — от 100 до 260 тыс. руб. По данным портала StackOverflow, основанным на опросах за 2019 год, годовая зарплата фронтедрера без опыта работы в РФ составляет от 510 тысяч рублей до 1 млн 300 тысяч рублей, то есть диапазон примерно такой же, как и по данным русских источников: от 42 до 108 тысяч рублей в месяц.
Джуниоры без опыта, как правило, могут рассчитывать в России на доход до 40 тысяч, спустя год — на 50-80 тысяч,миддлы— на 100-130 тысяч в месяц. А для лидов и синиоров зарплата в среднем от 150 тыс. рублей, но есть вакансии и на 350, и на 650 тысяч в месяц. Все зависит от региона, требований и компании, в которую вы устраиваетесь, и, конечно, от результатов собеседования.
Поднять свой доход можно, сотрудничая с зарубежными компаниями, в том числе и через иностранные биржи.
Востребованность профессии
На начало ноября 2020 года количество вакансий для фронтенд-разработчиков составляет:
Как всегда, чем больше вы умеете, тем выше вы ценитесь и получаете. К тому же, профессия фронтенд-разработчика — одна из тех, в которых без постоянного самообучения и освоения новых навыков не обойтись. Нужно прокачивать скиллы, следить за трендами, изменениями в требованиях к клиентской стороне сайтов, интерфейсу различных девайсов.
С чего начать и куда податься?
Где учиться на фронтендаи насколько успешным будет поиск работы,зависит от ваших целей и уже имеющихся знаний. Потому что, как и в случае со многими другими IT-профессиями, одних только курсов, самообучения или одной только вышки в вузе недостаточно. Нужен комплексный подход. Кроме того, в вузах РФ профессии фронтенд-разработчика почти не учат.
Если вы абсолютный новичок в программировании, в качестве базы и старта вам пригодится высшее техническое образование, связанное с информационными технологиями. Затем можно пройти пару онлайн или офлайн-курсов, связанных именно со фронтендом. Также важно постоянно заниматься самообучением, ведь эта сфера весьма динамична.
Где обучаться — на курсах онлайн, офлайн или осваивать профессию самостоятельно?
Для начала разберем офлайн и онлайн-обучение. Здесь особой разницы нет, так как и при очном посещении курсов, и при дистанционном в онлайн-режиме, вы будете учиться на практике, так что здесь все зависит от ваших предпочтений. Качественные программы есть в курсах обеих категорий. Но в онлайн-формате можно найти намного больше предложений от разных учебных заведений.
Теперь давайте оценим плюсы и минусы самостоятельного изучения профессии фронтенд-разработчика и занятий на курсах.
#27 Почему Дэн Абрамов не пользуется Firefox
19 ноя 2017 · Фронтенд Юность (18+)
Вступление (0:52)
Почему у библиотек такие тупые названия (5:42)
Podlodka Podcast (10:35)
Работа в СберТехе, ФБК и Mozilla Foundation (16:32)
Firefox Quantum (22:55)
Data-binding Revolutions with Object.observe() (30:45)
VS Code Live Share vs Atom Teletype (42:06)
String.prototype.replaceAll Proposal (53:44)
Dartup https://wriketeam.timepad.ru/event/612517/
Podlodka Podcast https://soundcloud.com/podlodka
Firefox Quantum https://www.mozilla.org/ru/firefox/Data-binding Revolutions with Object.observe() https://twitter.com/dan_abramov/status/931138895810580480
Promise – это не больно https://www.youtube.com/watch?v=S_j44BVijRE&t=1873s
Эпизоды
#211 Нейрофронтенд в космосе
Конференция и подкаст YaTalks (0:35)
DUMP облажался (3:20)
Дока (10:25)
Секретные заговоры Google (14:58)
Meta и Oculus (18:29)
VS Code в браузере и гид по React (22:26)
Photoshop приходит в веб (30:30)
Так ли плох Chrome (36:28)
Японский разблюриватель (43:53)
Космические лучи и ошибки в программах (51:33)
Конференция YaTalks https://yatalks.yandex.ru/
Подкаст YaTalks https://www.youtube.com/watch?v=aH1XoxCnjs4
Вопрос к IT People https://twitter.com/i/web/status/1451939628584427528
Мы на HolyJS https://holyjs-moscow.ru/talks/interviews-with-the-hosts-of-the-frontend-youth-podcast/
Выпуск с Антоном Назаровым про две работы https://soundcloud.com/frontend_u/e113
Дока https://doka.guide/
Why Facebook is rebranding to Meta https://www.theverge.com/22749919/mark-zuckerberg-facebook-meta-company-rebrand
Microsoft презентовал vscode.dev https://t.me/valya_reads_issue/213
Самый подробный гид про то, как Реакт работает внутри https://t.me/iamakulov_channel/652
Photoshop приходит в веб https://t.me/webnya/2321
Секретные заговоры Google https://t.me/nikitonsky_pub/217
В Японии задержали мужчину за разблюривание порнофильмов https://tjournal.ru/tech/458389-v-yaponii-zaderzhali-muzhchinu-kotoryy-razblyurival-pornofilmy-s-pomoshchyu-neyroseti
Бета React Docs https://t.me/valya_reads_issue/214
Космические лучи и ошибки в программах https://t.me/defront/1031
VideoTech Conf https://vtconf.com/
#210 HolyJS — зеркало общества
Сайт HolyJS: https://bit.ly/2Uz4jIp
Промокод на Personal Standard билет и Full Pass: frontendu2021JRGpc
В гостях:
Алексей Фёдоров (https://t.me/channel_23derevo)
Присылайте ваши темы!
github.com/frontendu/themes
Начало (00:00)
Почему Алексей называет себя продюсером (00:49)
Как юридически устроен Jug и новый бизнес вокруг онлайновых ивентов (03:00)
Про стримярд и сfu/mcu (05:25)
Respect RndTechConf (08:11 )
Яндекс.Телемост и продолжение про стримярд (08:48 )
Стримярд vs Zoom (11:40)
Веб-интерфейсы конференции. Когда предлагать оценивать доклад (14:23)
ICPC + international (21:56)
Ивент-бизнес в России: угрозы, откаты (33:42)
Планирование оффлайн конференций в ковидную эпоху (38:08)
Как Леха ходил в кино, а Алексей летал в Киев (48:14)
Про курение (52:31)
HolyJs и другие конференции (56:52)
Гендарный баланс на конференциях (01:02:41 )
Полезные ссылки (01:22:31)