Яркая звезда в сообществе JavaScript, Адди Османи завоевал известность не только благодаря своим потрясающим статьям о JavaScript и вкладам с открытым исходным кодом, но и тому, что стал одним из самых дружелюбных и доступных разработчиков.
Его блог — сокровищница передовых знаний и стоит посещения. В этом посте мы поговорим с Эдди о том, как он начал работать в JS, и затронем некоторые сложные темы, касающиеся его работы в отношениях с разработчиками в Google.
Q Вы приняли JavaScript, как рыба, чтобы поливать. Как ты попал в мир JS?
JavaScript должен был сыграть большую роль в этом.
Я написал свой первый JavaScript-код, когда Netscape Navigator был доминирующим браузером. Динамическая внешняя разработка только начинала становиться все более популярной в то время, но идея иметь возможность писать что-то только с помощью HTML / CSS / JS и работать везде, была мощной. Я увлекся этой идеей и с тех пор. Некоторые из моих первых творений были мелочами, над которыми вы бы смеялись сегодня — калькуляторы, генераторы паролей, ничего особенного.
Как энтузиасту языка, мне понравилось, что JavaScript основан на прототипах и слабо типизирован, поэтому я решил продолжить его изучение наряду с другими языками, такими как C ++. Еще в начале 2000-х я пытался связать языки, написав небольшой интерпретатор поверх SpiderMonkey (движка JavaScript Mozilla), который позволил мне написать логику для моих настольных приложений в JS и определить компоненты пользовательского интерфейса с помощью C ++. Это была глупая идея, но я многое узнал о внутренностях движка JavaScript в процессе.
Я потратил много времени на создание небольших сайтов для хобби, но когда я учился на последнем курсе в старшей школе, я решил по-настоящему застрять в мире браузерного оборудования. Я написал облегченный движок рендеринга, базовые парсеры HTML 4.01 / CSS 2.1 и обернул все эти части в свой маленький браузер. Надежность работы над проектом была кошмаром, отчасти из-за того, что слабые веб-разработчики придерживались стандартов на своих страницах — теперь забавно находиться на другой стороне забора! Более сложными задачами были соответствие спецификациям, рендеринг больших таблиц и поддержание производительности при загрузке видео-плагинов (кто-нибудь помнит хороший старый ActiveX?).
В колледже я продолжал изучать и использовать JavaScript как внештатный веб-разработчик, постепенно создавая более сложные сайты и играя с Dojo. Однако до 2006 года, когда я получил приглашение в GMail, мне пришло в голову, что браузер станет следующей платформой для создания многофункциональных приложений. JavaScript должен был сыграть большую роль в этом, и я решил навсегда отказаться от разработки настольных приложений.
С тех пор я пытался продолжить обучение и, где смогу, подтолкнуть интерфейсное сообщество вперед через мои статьи и материалы для открытого исходного кода. JavaScript сегодня практически везде, и это одна из причин, почему я люблю этот язык. Если я хочу научить одного из моих детей писать JavaScript, я могу просто открыть браузер DevTools и показать их. Никаких дополнительных шагов компиляции не требуется — в этом есть что-то действительно особенное.
Q Вы производите много контента; Я уверен, что люди задаются вопросом, как вы это делаете. Можете ли вы поделиться своими секретами не только для создания этого контента, но и для понимания того, о чем вы пишете?
Если вы перейдете к какой-либо нетривиальной теме с таким мышлением, необходимо разбить ее на простые, более легко усваиваемые шаги
Секрет в том, что я считаю себя несколько глупым. В самом деле. Если вы перейдете к какой-либо нетривиальной теме с таким мышлением, необходимо разбить ее на простые, более легко усваиваемые шаги, чтобы она имела какое-то подобие смысла.
Я думаю, что именно эта перспектива делает мое письмо доступным — я пытаюсь разобраться в тех концепциях или инструментах, которые изначально могут показаться довольно сложными для среднего разработчика. Важно иметь возможность применять это к статьям и особенно к документации. Так что будь проще. Это помогает сделать статьи более целенаправленными. Как я могу генерировать так много контента, понимая материал? Ну, я делаю понимание обязательным условием.
Сначала сделайте это, затем сделайте это правильно, затем сделайте это лучше.
У Эйнштейна есть замечательная цитата: «Если вы не можете объяснить это просто, вы не понимаете это достаточно хорошо», и это правда. Вы не можете учить или требовать основы, инструмента или передовой практики, если вы действительно не нашли время, чтобы использовать его самостоятельно. Найти это время легче в моей нынешней роли, но в те дни, когда я работал инженером 9-5 лет, я активно проводил время за завтраком и обедом, используя то, о чем позже напишу на выходных.
Найти время, чтобы сделать все, всегда непросто. Последние несколько лет у меня есть эта мантра, которую я пытаюсь применить к каждому заданию —
Затем вы можете поделиться этой первой итерацией со своими коллегами и почувствовать, идете ли вы в правильном направлении, или идею стоит реализовать. Для меня это имеет гораздо больше смысла, чем потратить недели на черновик или прототип, прежде чем просить ввода.
Q Вы были в AOL раньше. Каковы отличия культуры от Google и как это повлияло на ваши взгляды на разработку программного обеспечения?
Есть что-то особенное в том, чтобы быть частью компании с такими высокими стандартами.
И AOL, и Google — это компании с потрясающими инженерными командами, и любое из моих представлений о культуре касается не каких-то конкретных групп, а общего наблюдения.
Инженерная культура в Google такова, что мы очень заботимся о том, чтобы отшлифовать и доставить вещи, когда чувствуем, что они просто правы. Есть что-то особенное в том, чтобы быть частью компании с такими высокими стандартами.
В AOL я гордился любыми продуктами или приложениями, которые мы завершили, но из-за быстро меняющегося характера бизнеса и конкуренции задержка запусков или выпусков для полировки не всегда была осуществима. Я думаю, что это реальность для многих предприятий, несмотря на любое желание, которое они могут изменить эту культуру.
Когда есть возможность отложить релизы, чтобы, как говорят в Google, сделать это «правильно», я думаю, что это может изменить мир ваших пользователей к первым впечатлениям о вашем продукте.
В: Что вы думаете о состоянии сообщества JavaScript и о направлении группы TC39 в отношении ES6?
Я доволен тем направлением, в котором TC39 следовал последние несколько лет.
Я доволен тем направлением, в котором TC39 следовал в течение последних нескольких лет, чему частично помогли Рик Уолдрон и Йехуда Кац из проекта jQuery. Они уделили пристальное внимание шаблонам и библиотекам, на которые в значительной степени полагались разработчики, и изучали, как их можно лучше решить с помощью примитивов платформы. Я не буду комментировать конкретно ES6, но я с нетерпением жду, чтобы модули, классы, let и Object.observe() более доступными.
Что касается сообщества JavaScript: мы находимся в хорошем месте, но единственное, что я хотел бы сделать коллективно, это тратить меньше времени на создание новых фреймворков и больше времени вкладывать в усилия по улучшению существующих решений. Я думаю, это здорово, что разработчики тратят время на то, чтобы научиться решать проблемы самостоятельно — это один из лучших способов узнать что-то новое, но если это эксперимент, проясните это, чтобы другие разработчики не ожидали, что вы будете поддерживать проект. Такие вещи только добавляют шума, поэтому, пожалуйста, имейте в виду поддержку при выпуске вещей !.
Q Многие люди считают, что Google раздувает WebKit как игру, позволяющую им встраивать Dart в Chrome. Видите ли вы, что Dart — идеал Google над JavaScript?
Один из самых больших мифов заключается в том, что он существует, чтобы заменить JavaScript.
Мне было очень любопытно узнать больше о целях, которые ставил Дарт, когда я впервые присоединился к Google. Один из больших мифов заключается в том, что он существует для замены JavaScript, но оказывается, что это не совсем так. Dart ориентирован на разработчиков, более знакомых с Java, C ++, C #, которые пытаются создавать высокопроизводительные веб-приложения; и так далее, имейте определенные ожидания относительно их инструментов и языка. Я думаю, что это законная причина существования чего-то вроде Дартса.
Как компания, JavaScript и Dart — это технологии, в которые мы верим и инвестируем. Мы участвуем в TC39, работаем над будущим JavaScript, а также продолжаем работу над V8, быстрым движком JavaScript. Инженеры Chrome продолжают работу по продвижению Интернета с помощью новых спецификаций, таких как веб-компоненты. Тем временем, команда, которая изначально создавала V8, сейчас создает Dart VM.
Возвращаясь к вашему первоначальному вопросу — я считаю, что разветвление WebKit было гораздо больше связано с расхождением многопроцессорной архитектуры между обоими проектами, чем с попыткой встроить Dart в Chrome. Dart — это отдельный проект с открытым исходным кодом, имеющий свои собственные цели, и вы все еще можете получить Dartium сегодня (сборка Chromium с использованием Dart VM).
В: Теперь, когда Blink находится в разработке, как вы думаете, как это поможет сети, и какие, по вашему мнению, некоторые новые вызовы, с которыми веб-разработчики столкнутся с еще одним движком рендеринга, о котором стоит подумать?
Когда я впервые услышал новости о Blink, я был обеспокоен тем, что теперь у нас будет еще один браузер для поддержки.
Однако реальность такова, что уже было так много различий между различными портами WebKit, что это не окажет негативного влияния на то, как вы разрабатываете и тестируете.
Фактически, Blink позволяет нам предоставлять разработчикам больше инструментов, функций и совместимости, которые им необходимы для максимально эффективного использования Интернета в качестве платформы. В долгосрочной перспективе это позволит нам расставить приоритеты по функциям, которые облегчат создание следующего поколения веб-приложений, и точно так же, как V8 дал нам возможность ускорить JavaScript, я думаю, что Blink позволит нам внедрять инновации способами, которые принесут пользу вся платформа.
Вопрос: Google находится в интересной ситуации, когда им в значительной степени принадлежат как собственные приложения (Android), так и веб-приложения. Когда вы поддерживаете отношения с разработчиками в Google, как вы балансируете бизнес-директивы и приоритеты для обеих экосистем?
В наши дни мы довольно часто попадаем в дебаты о нативных и веб-ресурсах, но не слишком много говорим о необходимости ставить наших пользователей на первое место. Они в центре внимания. Есть много случаев, когда вы можете предоставить убедительные возможности для Интернета на настольных компьютерах и мобильных устройствах, и это будет работать фантастически. Тем не менее, есть и другие, где платформе или мобильным браузерам все еще нужно работать. Как бизнес, вам часто нужно звонить о том, что наиболее важно для ваших пользователей. Я думаю, что в настоящее время имеет смысл предложить разработчикам лучшие платформы для звонков в нативной и веб-среде, и это то, что мы делаем, через Android и Chrome для мобильных устройств.
Q Отбрасывая конкретные веб-технологии, о чем должны думать разработчики на более высоком уровне, когда речь заходит о будущем Интернета?
Многоразовые компоненты.
Многоразовые компоненты. Традиционно многие из нас разрабатывали приложения достаточно вертикально, распространяя единую концепцию (будь то логика или пользовательский интерфейс) на несколько разных частей проекта. Это не только затрудняет поддержание идеи, но также затрудняет извлечение и повторное использование идеи в будущих приложениях без особых усилий. Это также снижает наши шансы на то, чтобы поделиться этим компонентом с другими.
Не обращаясь к конкретным технологиям, мы работаем над тем, чтобы упростить определение и упаковку компонентов на стороне веб-платформы, и сейчас самое время начать думать о том, как могут быть написаны ваши собственные приложения, если они будут разбиты на конкретные компоненты.
В Находясь на этом пути, какие ключевые технологии, сквозные, на ваш взгляд, оказывают наибольшее влияние на продвижение Интернета? Почему?
Внешний интерфейс видит революцию в инструментальной оснастке в настоящее время с увеличением числа разработчиков, начинающих использовать Grunt и исследовать инструменты рабочего процесса вокруг него, как Yeoman . Разработчики уделяют больше внимания тому, что они могут автоматизировать, и я думаю, что это поможет сэкономить больше времени на создании лучших приложений и меньше времени на этих ручных процессах между ними.
Возвращаясь к идее компонентов, я думаю, что между веб-компонентами и интерфейсным управлением пакетами у нас есть огромная возможность по-настоящему изменить способ разработки для Интернета. AngularJS (и директивы Angular) проделали большую работу по повторному представлению идеи многократно используемых блоков функциональности, и вещи действительно смотрят на аспекты управления пакетами через Bower.
Написание приложения со списками, которые вы хотите сделать сортируемыми? Отлично. Несколько нажатий клавиш в командной строке, и вы получите это. Хотите, чтобы элементы в этом списке сохранялись, когда вы не в сети? Нет проблем. Еще несколько нажатий клавиш, и вы используете пакет, который один разработчик однажды должен был написать, чтобы получить такую возможность. Хотите превратить свой список в повторно используемый компонент, который может использовать кто-нибудь еще? Это легко. Это будущее, к которому мы стремимся.
Q Yeoman — ваш новый ребенок. Почему вы почувствовали необходимость активизировать такие амбициозные усилия, когда существующие проекты, казалось, удовлетворяли эту потребность?
Нам повезло иметь в нашем распоряжении множество полезных инструментов на переднем крае — инструменты, которые экономят наше время и делают нашу жизнь немного проще. Абстракции, такие как Sass и CoffeeScript , фреймворки, такие как Twitter Bootstrap , загрузчики модулей, такие как RequireJS , бесконечный список MVC и библиотек модульного тестирования. проект запущен.
Вы все еще обновляете свой браузер вручную, когда вносите изменения в свое приложение?
Поскольку эти инструменты работают исключительно хорошо сами по себе, это может быть утомительным процессом, заставляющим их работать вместе, особенно если вам нужно объединить рабочий процесс и процесс сборки, где все они компилируются и сокращаются кратко. Даже если вам удастся создать надежный процесс сборки, вам часто приходится тратить много времени на написание стандартного кода для вашего приложения.
Даже тогда вы должны спросить себя, насколько хорошо это вписывается в ваш повседневный рабочий процесс. Есть несколько маленьких шагов, которые мы периодически делаем при разработке, которые легче передать инструменту. Вы все еще обновляете свой браузер вручную, когда вносите изменения в свое приложение, чтобы просмотреть, как они выглядят? Все еще пытаетесь выяснить, используете ли вы последние версии всех ваших зависимостей? Хотите знать, есть ли что-то, что позволило бы вам заняться кодированием и забыть о многих тяжелых работах?
Мы тоже были, поэтому мы начали искать, можем ли мы дать разработчикам решение многих из этих распространенных проблем. Мы попытались решить их в бесплатном проекте с открытым исходным кодом, который мы недавно выпустили под названием Yeoman. Официальный слоган Yeoman заключается в том, что мы — «надежный и самоуверенный стек на стороне клиента, состоящий из инструментов и сред, которые могут помочь разработчикам быстро создавать привлекательные веб-приложения».
Практически, мы являемся набором инструментов и задач, которые помогут вам автоматизировать некоторые из наиболее утомительных задач в разработке переднего плана. Мы состоим из yo (инструмент скаффолдинга), grunt (инструмент сборки) и bower (для управления пакетами).
Если вы обнаружите, что все еще пишете стандартный код для своего приложения, вручную управляете зависимостями для своих приложений или собираете свою собственную систему сборки для работы с инструментами, которые вам нравятся, вы можете найти Yeoman хорошим способом избавить себя от головной боли.
В Когда вы запустили Yeoman, Windows изначально не поддерживалась. С какими проблемами вы столкнулись, поддерживая его, и как сообщество разработчиков Windows может помочь в этих обстоятельствах?
Сообщество разработчиков Windows может действительно помочь нам здесь.
Создание инструмента командной строки, который хорошо работает кроссплатформенно, может быть деликатным танцем. Одной из первых проблем с поддержкой Windows было то, что многие из нашей команды привыкли использовать систему * nix и иметь доступ к homebrew / apt-get. Тем не менее, мы не были так хорошо знакомы с PowerShell или Chocolatey (Windows PowerShell, эквивалентная apt-get), и нам нужно было время, чтобы понять, насколько хорошо эти решения по сравнению с инструментами, которые мы имели в других местах.
Затем потребовалось время, чтобы найти (или получить) все пакеты, которые нам требовались в Chocolately, так как нам были нужны git, фантомы, опции и многие другие. Ситуация там значительно улучшилась с момента нашего первого выпуска, и теперь Windows официально поддерживается Yeoman, используя инструкции на нашей домашней странице.
Сообщество разработчиков Windows может действительно помочь нам в этом, выступая за более широкое распространение таких инструментов, как Chocolately, и помогая нам достичь паритета с такими инструментами, как apt-get. Помимо этого, они были фантастическими, и мы очень ценим помощь и поддержку, которую сообщество разработчиков Windows предоставило нам на протяжении всего пути к совместимости.
Я должен позвонить Синдре Сорхусу, Микаэлю Дэниелсу и Полу Айришу, которые действительно помогли улучшить наши усилия по Windows в первые дни.
В связи с этим у меня есть вопрос, основанный на полностью эгоистичной мотивации, поскольку я использую Windows. Как * nix и разработчики Windows могут более эффективно сотрудничать, чтобы каждый мог внести свой вклад?
На данный момент написано много (фантастических) инструментов разработки, которые не просто * nix, но специфичны для Mac, потому что их кроссплатформенность требует собственных затрат на разработку и накладных расходов. Я хотел бы видеть больше открытых дискуссий и разработки инструментов, которые могут работать везде, но это не может быть сделано без помощи пользователей.
Если вам нужен инструмент для Windows, который вы просто видите на Mac, пожалуйста, о нем говорите — еще лучше, отправьте запрос на извлечение!
Попробуйте выяснить, что нужно сделать, чтобы перенести его в Windows (и в других местах), и кто знает? Возможно, совместных усилий нескольких сообществ будет достаточно, чтобы что-то произошло.
Q Вы написали отличные посты, опубликовали книги и внесли свой вклад в лучшие проекты OSS, такие как jQuery и Yeoman. Из всех ваших профессиональных достижений есть что-то, что действительно выделяется как гордый момент?
Выпуск моей первой книги « Изучение шаблонов проектирования JavaScript» (с О’Рейли), вероятно, был достижением, которое принесло мне наибольшее удовлетворение. Это был мой самый большой писательский проект, и я принял решение, чтобы он был полностью открытым исходным кодом — вызов, о котором я никогда не пожалею. Предоставление учебного материала каждому, где бы он ни мог себе позволить, может принести много пользы.
Это также может увеличить влияние вашей книги, поэтому, если вы автор — подумайте об этом. Вы не пожалеете об этом!
Огромное спасибо Адди за то, что сели с ней. Если у вас есть какие-либо вопросы к нему, я уверен, что он не возражает ответить ниже в комментариях!