Статьи

Взлеты и падения программного обеспечения с открытым исходным кодом, с Кеном Уилером

кен-Уилер-версий

В этом выпуске Showing Version к Тиму и Дэвиду присоединился Кен Уилер, программист на JavaScript, известный как проект с открытым исходным кодом, такой как Slick Carousel. Они обсуждают взлеты и падения создания и поддержки программного обеспечения с открытым исходным кодом, балансирование работы с открытым исходным кодом и коммерческой работы, проблемы отцовства и создания рэп-музыки.

Показать заметки

Версионное шоу с Кеном Уилером

Основные моменты разговора

Стоит упомянуть одну вещь: держать API небольшими … многие люди будут обращаться к вам с запросами о опциях, различных опциях и возможностях и тому подобном, основываясь на крайних случаях. И тогда угощение каждому не принесет ничего хорошего. Если вы учитываете каждый отдельный случай, если вы добавляете каждый предложенный вариант в интересах быть крутым парнем, который делает это, нет. Потому что то, что должно произойти, теперь у вас есть эта большая раздутая библиотека различных бинтов для разных крайних случаев, и вы ушли от первоначального видения чего-то, что является просто небольшим набором надежных API для 90-х. % вариант использования. Не позволяйте этому случиться с вашим проектом — пожалуйста!


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


Не просто тяните репо … где тысячи людей зависят от этого. Это не субтитр какой-либо конкретной вещи; Я просто говорю!

расшифровка

Тим:

Эй, как дела, все это Тим Эвко …

Дэвид:

… а это М. Дэвид Грин. И вы слушаете седьмой эпизод Showing Version. Это место, где мы собираемся, чтобы обсудить индустрию Интернета от разработки до дизайна — с некоторыми из людей, которые делают это сегодня и планируют, в каком направлении она будет в следующей версии.

Тим:

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

Дэвид:

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

Кен:

Я делаю прекрасно. Спасибо, что приняли меня.

Дэвид:

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

Тим:

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

Кен:

О, ты собираешься бросить что-то столь тяжелое на меня так рано?

Тим:

Мы всегда получаем этот ответ тоже — это здорово! [Смеется]

Кен:

Я не так хорошо справлялся с семантическими версиями в прошлом. Ну, я хотел бы сказать, что я, возможно, на уровне 0,19 альфа — или, по крайней мере, я хотел бы так думать.

Дэвид:

Приятно, что вы держите его в альфа-диапазоне. Это важно

Кен:

Это верно. Это еще не совсем бета. Это все еще немного грубо по краям. Не готов к 1.0.

Тим:

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

Кен:

Я много делал в детстве. Когда я был маленьким, я научился печатать очень быстро. Большинство компьютерных классов печатали в то время. Я, уже будучи опытным типографом и имевший привилегию иметь компьютер дома, был отчасти освобожден от части, связанной с набором текста компьютерных классов. Мне нужно возиться с другими вещами, такими как QBasic или Visual Basic.

И это очаровало меня, так что я бы поиграл с этим. Я действительно хорошо провел время, много занимался Visual Basic в детстве, а потом перестал программировать. Подождите, прежде чем я перестал программировать, я также сделал много раннего HTML — как, помните, что это? Как и GeoCities, и тому подобное, джаз, 3D-навыки каркасного прядения, кровавые баннеры и все такое забавное.

Дэвид:

Мы посмотрим, сможем ли мы найти заархивированную копию вашей страницы GeoCities для размещения с подкастом. [Примечание редактора: мы ничего не смогли найти, но дайте нам знать, если вам повезет найти что-нибудь!]

Кен:

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

Napster вышел, и это перестало быть моей карьерой. У меня была пара забавных карьер после этого. Возможно, «карьера» — не то слово. Может быть, смешная работа в промежуточный период. Я был свахой — высококлассным свахой. Это не похоже на спорт — как сватовство для состоятельных людей.

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

Итак, я помню первую работу, которую я получил, я соврал. Мы писали Flash — это было похоже на магазин Flash в то время. Я не знаю, парни ли вы помните это когда-то, но это было похоже на полный магазин Flash. Мы делали веб-сайты для ресторанов и местных компаний с очень интересным вступлением и прекрасными фотогалереями, писали ActionScript, ActionScript 2, а затем ActionScript 3, сохраняя при этом ECMA все время.

Дэвид:

Конечно.

Кен:

Но да, я сказал им, что знаю, как это сделать, и в то время я не знал, как это сделать, но я был уверен, что через короткое время я смогу это сделать. И вот, я смог это сделать, поэтому немного поработал. Я был разработчиком Flash, а затем вышел iPhone. Когда вышел iPhone, они вроде как убили Флэша. Видел текст на стене и возвращался ко всему HTML / CSS / JavaScript, где, я думаю, jQuery только начинает набирать популярность. И я отчасти взял это оттуда примерно год или два, написав то, что мы делаем сегодня. Не обязательно то, что мы делаем сегодня, но не Flash.

Давид [4:26] :

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

Кен:

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

Дэвид:

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

Кен:

Это правильно?

Дэвид:

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

Тим:

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

Кен:

Я уверен, что вы могли бы иметь.

Тим:

Да, может быть, позже я напишу пару треков под музыку.

Кен:

Мы могли бы сделать это вместе.

Тим:

Это было бы так хорошо. Мы могли бы использовать как Web Audio API или прочее. Звучит очень сложно, но я не в себе.

Кен:

Восточное побережье?

Тим:

Да, ты в Джерси, я в Квинсе — это прекрасно.

Кен:

Я чувствую, что Восточному побережью нужно немного постучать в эти дни, мой человек.

Тим:

Они делают. Итак, Кен, классные проекты, над которыми ты недавно работал. Вы хотите поговорить о некоторых последних парадигмах программирования, проблемах, классных проектах, о чем-нибудь подобном?

Кен:

Я бы сказал, что большая часть этой работы над React, которую я делаю в Walmart, очень интересна, потому что это как новая вещь, но она также в масштабе — в огромном масштабе; так что это было довольно интересно

Другие вещи имеют популярные проекты с открытым исходным кодом. Я написал Slick Carousel , и на самом деле написать это было не легко, но это было не очень сложно. Он занимается этим после того, что было интересно. Очень интересно попробовать и поддерживать такие вещи — и это относится ко всем открытым исходным кодом. У меня есть много библиотек, которые я не поддерживаю так хорошо, как следовало бы. Очень интересно наблюдать за тем, как что-то становится популярным, а затем за разными проектами, у некоторых возникают определенные проблемы, которых нет у других. Что-то вроде скользкой карусели похоже на низко висящий фрукт: кому не нужна карусель, верно?

Почти на каждом веб-сайте, который вы создаете для кого-то другого за деньги, им понадобится какой-то слайдер. Но у вас есть другие вещи, такие как библиотеки Flux и тому подобное. Это немного… я не собираюсь говорить «эксклюзив», но это меньшая аудитория; это более сфокусированная аудитория, поэтому у вас другие проблемы. К вам приходят люди со словами: «Я не такой уж и горячий в JavaScript. Как это работает? »Это больше похоже на:« Я очень горяч на JavaScript. Нам нужно оптимизировать это »или что-то в этом роде.

Разобраться со всем этим в пространстве с открытым исходным кодом было довольно интересно. Одной из самых интересных вещей, которыми я занимался в последнее время, является React Native , который безумен. Вы пишете настоящие нативные приложения на JavaScript, что для меня абсолютно безумно.

Дэвид:

Я немного слышал о React Native, и мне любопытно: с какими проблемами вы сталкиваетесь, когда пытаетесь развиваться в React Native?

Кен [7:30] :

Ну, у вас есть несколько разных преимуществ его использования. Прежде всего, вы получаете кроссплатформенность, то есть, как правило, пишете сразу, и вы получаете то же самое на Android и iOS — из единой базы кода. Если вы действительно отличный, вы даже можете поделиться некоторыми из Redux из Интернета с этим приложением, если они достаточно похожи. Далее, вы получаете классные вещи, такие как прыгать код Play, так что вы можете обойти процесс отправки в App Store (который на самом деле стал немного лучше в последнее время).

Одна вещь, которую я вижу в масштабе, что довольно круто, это то, что если у вас есть группа инженеров, знакомых с JavaScript или знакомых с React, вдруг вся ваша команда JavaScript сможет работать над вашими мобильными приложениями. И снова, это вообще говоря.

Я делаю React Native в Walmart, и это замечательно нетривиально. На родной стороне происходит много чего довольно сложного. Так что это не значит, что кто-то со стороны JavaScript может прийти и поиграться с этим.

React Native не является заменой определенных вещей. Это просто не имеет смысла для определенных вещей. По сути, если бы у вас было нативное приложение, и вы нашли место, где вы бы использовали WebView (это как гибридные приложения, верно?). Если у вас есть место в этом месте, где вы будете использовать веб-представление — как в Cordova, — но вы хотите, чтобы оно казалось естественным, React Native — отличный кандидат для этого.

Тим:

Что в React Native делает его более естественным, чем, скажем, ситуация PhoneGap / Cordova?

Кен:

Он буквально является родным. Что происходит, как именно это работает — может быть, не совсем так, но как я лично понимаю, как это работает после работы с ним и подробного изучения его — так это то, что у вас есть JavaScript, который интерпретируется в одном потоке, а затем вы иметь собственный код, который принимает интерпретируемый JavaScript и создает собственные представления с этим. По сути, вы говорите своей родной программе, как планировать и работать с JavaScript, но это не в браузере или WebView. Вы не используете JavaScript в контексте браузера. Вы не рендеринг в HTML. HTML ни разу не использовался. То, что вы делаете, указываете типы, такие как view text и тому подобное, и они представляют (если вы в iOS) такие вещи, как представления пользовательского интерфейса, текст пользовательского интерфейса, любой из этих элементов управления. Что делает его еще круче, так это то, что, вероятно, лучшая система мостов из всех, что я когда-либо видел, так что ваш опыт разработчика потрясающий.

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

Таким образом, вы можете связать это с вашим JavaScript-приложением. Вы можете сделать асинхронный вызов геокодеру — или классу геокодера, который вы установили в собственном классе модуля с обратным вызовом; это соединено Вы можете позвонить на него, и он отправит вам координаты в лат.

Это всего лишь один пример того, что вы могли бы сделать. Мало того, что вы можете соединять модули подобным образом, где вы можете написать класс Objective-C, где вы делаете что-нибудь под солнцем: вы также можете выставлять и визуализировать представления. Любое представление, которое вы можете себе представить — любой элемент управления, так сказать, — вы можете подключить его, соединить мостом, а затем представить его в теге с подпорками (которые по сути являются атрибутами HTML), а затем подключить их к элементу управления.

Дэвид:

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

Кен:

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

Для меня, будучи парнем из JavaScript, я хочу играть как можно лучше. [Смеется]. Так что это большая часть баланса. Я хочу использовать как можно больше нативов, оставаясь гибким на стороне JavaScript.

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

Так что внутри Walmart у нас есть платформа под названием Electrode , где у нас есть тонна общих элементов и общих компонентов — что у вас есть — что каждый может выбрать и которые поддерживаются в целом.

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

Тим [13:04] :

Это круто. Похоже, что Walmart имеет свою собственную внутреннюю среду с открытым исходным кодом, чтобы отслеживать все это. Есть ли какие-то уроки, которые вы можете извлечь из того, как Walmart выполняет своего рода работу с открытым исходным кодом, и переводить ее в реальное, гораздо более широкое сообщество open-source?

Кен:

Абсолютно. У нас есть конфиг ESLint . Я работаю на Грозный ; через них я работаю на Walmart. Мы используем конфиги Walmart Lint , весь процесс там. У нас также есть инструмент под названием Builder , который мы используем для управления несколькими репозиториями. Если у вас есть подобная Walmart ситуация, когда у вас есть куча репозиториев, мы используем Builder, чтобы по существу иметь одинаковые процессы сборки — все такое — для всех и иметь возможность обновлять их во всех этих.

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

Дэвид:

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

Кен:

Ну, на самом деле это забавно, потому что Formidable, компания, в которой я работаю, выставляет себя как компанию с открытым исходным кодом, которая работает по контракту, чтобы держать свет. Это не значит, что я хожу делать свою дневную работу, а затем делаю работу с открытым кодом. Большая часть моей дневной работы — работа с открытым исходным кодом. Мы официально санкционировали открытый исходный код, над которым мне дали время поработать в 9-5, где я здесь.

Когда я писал Slick Carousel, это было не так. Я работал в отличной компании, но занимался вопросами с открытым исходным кодом. Я работал бы с открытым исходным кодом ночью и возвращался и выполнял работу с клиентами в течение дня — большую часть времени, когда моя работа с клиентами выполнялась намного лучше, когда я работал с открытым исходным кодом ночью, или инструменты, которые позволили бы мне работать быстрее, быстрее, лучше, что у тебя.

Теперь, в Грозном, открытый исходный код поощряется. Нам дали время поработать над этим, и у нас есть тонна открытого кода, над которым мы работаем. Что касается моего личного открытого источника, мой личный открытый источник в настоящее время страдает. Для этого есть только одна причина — отцовство. Я приходил домой, моя жена надевала Бакалавра или что-то в этом роде (и кто хочет смотреть это?), Поэтому я тусуюсь и работаю с открытым исходным кодом, стучу по клавишам. Если бы у нее был большой рабочий день утром, она ложилась бы спать в 10:00, я бы оставался до 1:00 утра, играя в компьютеры.

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

Я пытаюсь управлять этим немного больше, тогда как раньше, чем бы я ни интересовался, я просто работал над этим. Теперь я пытаюсь сказать: «Хорошо, ну, это должно произойти на этом, и это должно произойти на этом». Я получаю много новых горячих вещей на GitHub — «реакции», или как там их называют. Я говорю: «А, ну, ты должен позаботиться об этом».

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

Вы пишете код бесплатно, но вы все равно обязаны им — но это не бесплатно, верно? Я сказал своей жене, что получил несколько абсурдных обращений на странице, на странице документации для Slick, и она сказала: «А что, если вы заплатите за это?»

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

Тим [17:11] :

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

Кен:

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

Но если они говорят что-то об этом, это возможность улучшить это. Я делал кое-что с Slick Carousel на раннем этапе, или я делал кое-что [с] другими библиотеками. Когда меня зовут на это, я говорю: «Ух ты, я никогда этого не знал. Я никогда не знал, что это было похоже на перфект. Огромное спасибо ». Они похожи:« Это похоже на уязвимость межсайтового скриптинга или что-то в этом роде? »Я сказал:« Ух ты, я понятия не имел, что такое возможно ». Это просто учеба.

Как будто в любое время кто-то звонит тебе, не чувствуй себя глупым. Вы можете чувствовать себя глупым, я чувствую себя глупым все время, но не принимайте это на свой счет. Если они беспокоятся о долгосрочном обслуживании, кого это волнует? Вы не должны этим людям ничего. Вы кладете что-то бесплатно, тратите время на поддержку, и этого должно быть достаточно. Если люди зависят от этого, если люди действительно зависят от этого, я думаю, что делегирование и уверенность, что это достаточно актуально, это хорошая вещь. Не просто сносите репо и дерьмо, где тысячи людей зависят от этого. Это не субтитр какой-либо конкретной вещи; Я просто говорю!

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

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

Стоит отметить, что API должны быть небольшими . Если есть одна вещь, с которой я столкнулся, очень лично, это то, что многие люди будут обращаться к вам с просьбами об опциях, различных опциях и возможностях и тому подобное, основываясь на крайних случаях. И тогда угощение каждому не принесет ничего хорошего. Если вы учитываете каждый отдельный случай, если вы добавляете каждый предложенный вариант в интересах быть крутым парнем, который делает это, нет. Потому что то, что должно произойти, теперь у вас есть эта большая раздутая библиотека различных бинтов для разных крайних случаев, и вы ушли от первоначального видения чего-то, что является просто небольшим набором надежных API для 90-х. % вариант использования. Не позволяйте этому случиться с вашим проектом — пожалуйста!

Тим [20:12] :

Да, я должен сказать, что один из лучших советов, которые я получил — и осознал сам, выпуская некоторые из ограниченных, очень скромных библиотек, которые у меня есть в открытом исходном коде — это просто держать его маленьким, но также и с Возможность продлить для тех, кому нужно. Я думаю, что я в основном поддерживаю выпуск небольших специализированных API, где документация достаточно хороша, так что кто-то может просто раскошелиться. А потом: «О, позвольте мне добавить эту вещь». Возможно, их версия получит больше признания, чем моя, но это определенно снижает нагрузку на обслуживание.

Кен:

Хорошо не просто закрывать сферу, но и дать людям возможность перебегать. Я думаю, что удивительным примером этого является Redux . Привет моему человеку Дану Абрамову .

Redux замечательно маленький. Это очень маленькая библиотека, которая делает очень маленькую вещь. Но это дает вам запасной люк промежуточного программного обеспечения. Теперь вокруг нее возникла целая экосистема, где все эти крайние случаи, которые нужны людям для всех различных проектов, теперь индивидуально управляются теми людьми и другими людьми, которые имеют эти крайние случаи в отдельных проектах через промежуточное ПО.

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

Тим:

Итак, Кен, что ты говоришь людям — и я думаю, что иногда я являюсь частью этого лагеря (мы с тобой время от времени возвращаемся). Но что вы говорите людям, которые говорят: «Я просто работаю над проектом, размер которого x. Зачем мне делать что-то вроде React или Redux для моего проекта? »

Кен:

Это зависит от вашего проекта. Трудно сказать, правда? Как будто я могу сидеть здесь и говорить, что я не буду использовать React для статического сайта, но на самом деле я бы это сделал из-за Гэтсби . Я бы не написал презентацию. Конечно, я написал спектакль , я пишу презентации в React. Для самого React — это не очень хорошо — но я думаю, что это, безусловно, ускоряет ход вещей, но в значительной степени зависит от ваших потребностей.

Если вы пишете приложение, я думаю, оно действительно может вам помочь. Я думаю, что если вы пишете как местная веб-страница гастронома, вам, вероятно, не нужны React или Redux. Большую часть времени вам даже не нужен Redux. Я разработал игры React Native без Redux. Redux — это то, что вы пересекаете этот мост, когда добираетесь до него.

Дэвид:

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

Кен:

Есть проекты, в которых, я думаю, вы можете заставить React действовать почти как веб-компоненты, где он будет монтировать их в маленькие кусочки обычной веб-страницы. Если вы просто хотите использовать виджет React или полнофункциональное приложение, вы отображаете всю страницу в React. Что вообще говорит о том, что я делаю. Или, если вы маньяк, вы визуализируете с ним все нативное приложение. Или, если вы еще более сумасшедший , вы используете React-blessed и React для рендеринга на ваши благословенные CLI-терминалы, где у вас есть инструментальные панели CLI, написанные на React.

Тим:

Я думаю, что мой мозг тает сейчас.

Кен:

Вы видели это?

Тим:

Нет, у меня нет.

Кен:

О человек, я должен показать тебе. Это довольно холодно. Я настроил GitHub webhook. Видишь этот телевизор позади меня прямо здесь?

Тим:

Да.

Кен:

К этому подключен Raspberry Pi.

Тим:

Конечно.

Кен:

Я страдаю от вины с открытым исходным кодом. У меня глубокая, глубокая вина с открытым исходным кодом, поэтому я хочу лучше работать помощником. Поэтому я решил, что хочу, чтобы это было у меня на лице в течение всего дня, каждый выпуск чего-то подобного. Так что у меня есть Raspberry Pi. На самом деле я не закончил его полностью, но у меня было настроено ngrok на Raspberry Pi, чтобы он был доступен снаружи, а затем я установил GitHub webhook, а затем сервер Express на Raspberry Pi, чтобы каждый раз что-то случилось на GitHub, оно отправило бы его на Raspberry Pi. Экспресс-сервер взял бы его, а затем обработал вывод терминала, используя Blessed, чтобы дать мне крутой хакерский обзор того, как я хреново поддерживаю открытый исходный код. Но если вы не видели Blessed, это действительно круто.

Тим [24:28] :

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

[Смех]

Кен:

Нет, я в порядке, я в порядке.

Дэвид:

О, давай Тим, у кого Raspberry Pi не подключен к телевизору? Пожалуйста!

Тим:

Я знаю, это смешно.

Кен:

Бросай первый камень, верно?

Дэвид:

Послушай, Кен, как люди могут найти тебя в Интернете?

Кен:

О вау — bodybuilding.com форумы.

[Смех]

Эвко получает это.

Итак, вы можете найти меня на github.com/kenwheeler . Вы можете найти меня на twitter.com/ken_wheeler . Вы можете перейти на formidable.com, чтобы увидеть, где я нахожусь там. Вы можете перейти на soundcloud.com/thekenwheeler, если хотите услышать что-то супер-свежее. Я не знаю, ты мог бы подружиться со мной на Facebook. Я думаю, что у меня есть настройки конфиденциальности с друзьями друзей, но мы все должны стать друзьями.

Дэвид:

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

Кен:

Большое спасибо за то, что приняли меня.

[Музыкальная интерлюдия]

Дэвид:

Похоже, ты знал Кена еще до этого.

Тим:

Да собственно Кен и я стали друзьями в Интернете, потому что мы оба написали статьи для сайта scotch.io . Это забавно, потому что здесь это не очень заметно, но Кен и я на самом деле дико расходимся во взглядах на фреймворки или очень популярные библиотеки. Одна из главных причин этого заключается в том, что Кен работает над гигантскими, масштабными проектами, такими как Walmart, и над тем, что он делает в Formidable Labs. Я работаю над гораздо меньшими проектами, о которых меньше беспокоиться о глобальном состоянии и везде. Но время от времени мы с ним будем ходить по кругу в Твиттере, рассказывая о том, почему мы кодируем так или иначе. Это всегда зрелище, чтобы увидеть, станешь ли ты свидетелем этого.

Дэвид:

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

Тим:

Да, определенно, и это то, что раньше в моей карьере я был — я думаю, как и все мы — очень сильно склонен к определенной методологии или кодированию определенным образом. Но чем больше я испытывал такие вещи, как «У нас 15 или 50 разработчиков в нашей команде», нам нужно стандартизировать вещи. Нам нужны конкретные методы. Мы не можем сейчас входить в проект и кодировать все с нуля, потому что проблем гораздо больше. Там гораздо больше масштабов, гораздо больше кода, чтобы подтолкнуть. Да, я определенно вижу почти все причины, по которым он использует подходы, которые он использует в определенных проектах.

Дэвид:

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

Тим:

Да, я однажды дал молниеносную беседу на встрече об этом. Я в основном просто с открытым исходным кодом это действительно очень маленький, это не было ничего великолепного. Это был просто небольшой API, который позволял вам легче работать с файлами cookie, потому что, как вы знаете, document.cookie — это всего лишь манипулирование строками. Там действительно нет функции там. Так что я просто абстрагировал это в объект с помощью некоторых методов и сделал его немного проще. Это было примерно 50 строк кода, и был очевидный потенциал для других функций.

Например, у вас может быть, что если мы сохраним некоторые манипуляции с файлами cookie в локальном хранилище, или добавим некоторые новые методы здесь, или дадим пользователю способ добавить безопасные файлы cookie? Я намеренно пропустил это и записал в хранилище в README: «Не отправляйте новые функции». Я сказал «пожалуйста». Я сказал: «Пожалуйста, не предоставляйте никакой функциональности этому. Скорее, разветвите его и сделайте то, что вам нужно, или отправьте запрос на извлечение, который сделает мой дрянной код лучше, чем он есть, но оставьте функциональность себе ».

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

Давид [29:15] :

Я вижу это и важность того, чтобы люди чему-то учились из кода, который вы пишете. Я думаю, что когда вы смотрите на то, как быстро движется только один JavaScript-ландшафт — сколько меняется, сколько существует новых фреймворков, сколько появляется парадигм — что люди говорят: «Теперь это, очевидно, правильный способ делать вещи». и ты больше не можешь так поступать ».

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

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

Тим:

Да, это был урок, который я очень быстро усвоил в своем первом крупном проекте с открытым исходным кодом, который на самом деле закончился не так давно, когда мы работали над WordPress Core, чтобы получить отзывчивые изображения в WordPress Core. Я написал версию 0.01 этого плагина, которая в конечном итоге попала в WordPress. Возможно, я не преувеличиваю, возможно, одна строка моего исходного кода дошла до последней итерации. Я был в порядке с этим, и на самом деле более чем счастлив, потому что из этого получилась удивительная вещь, которую я никогда не смог бы построить самостоятельно, потому что WordPress — это просто огромная база кода. Я постепенно понял, что, ладно, неплохо было бы выложить что-то ужасное, потому что начнется разговор. Люди присоединятся. Люди появились из ниоткуда.

Джо МакГилл, который в основном видел эту вещь до финиша, я никогда не встречал его раньше. Но однажды он увидел: «О, это происходит на WordPress», и через месяц или два он стал основным участником, удалив весь мой плохой код и записав эти новые замечательные вещи. В конце дня, когда этот проект был завершен, все мы были участниками WordPress Core. Я сразу понял, что не нужно сильно беспокоиться о том, что я выталкиваю, потому что то, что я открываю для всего мира, это для меня не только опыт обучения, но и польза для меня. кто-нибудь еще. Если это хорошо, отлично, кто-то другой будет использовать это, может быть, я когда-нибудь расскажу об этом. Если это плохо, я собираюсь узнать намного больше.

Дэвид [31:50] :

Это так же верно в средах с закрытым исходным кодом, как и в средах с открытым исходным кодом. Я работал во многих компаниях, где проекты, над которыми я работал, были командой людей. И в конце концов, один человек, возможно, активно участвовал в кодировании постоянно, и ни одна строка кода не могла быть включена в окончательный проект, но это участие и вовлеченность, обучение, которое продолжалось, разные перспективы, которые вступают в игру — это не то, что вы можете определить команду следующим образом: «Вы написали семь строк кода, и вы получили столько», и «Вы написали 12 строк кода, и вы получили столько». Это похоже на старая шутка в программировании. Вы не платите людям за строки кода, которые они в конечном итоге публикуют. Вы должны сосредоточиться на изучении и ценности, которую добавляет сотрудничество команды в целом.

Тим:

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

Дэвид:

Да, и тот факт, что есть так много людей, готовых поделиться своими знаниями и заинтересоваться этими вещами, поразительно. Когда люди начали говорить об этом изначально, это было что-то вроде: «Люди собираются бесплатно? Никто не собирается этого делать ».

О, да? Люди будут это делать, и люди будут учиться на этом, и они получат от этого пользу, а общество в целом получит от этого пользу.

Тим:

Да, определенно, и это одна из вещей, которые мне нравятся в open source. Я чувствую, что иногда люди могут видеть это как: «Это рабский труд, как будто вы делаете это бесплатно. Зачем тебе это делать? Вы просто отправляете свои секреты в мир, чтобы все могли их увидеть ».

И я был в тот момент, когда впервые занялся кодированием. Я сказал: «Зачем тебе всем показывать, что ты делаешь? Почему бы не оставить это себе? »И тогда я понял, что это очень противоречит интуитивному пониманию большинства существующих отраслей, но чем больше вы вкладываете в это дело, чем больше вы учите друг друга, тем больше вы лично получаете от этого выгоду. Это то, что я люблю в этой отрасли.

Дэвид:

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

Тим:

Да, я не мог бы сказать это лучше сам. И я бегал снова и снова. Код, который я абсолютно испуган, чтобы выложить туда, я выложу там, и иногда, к моему облегчению, это звучит так: «Никто не видел этого, это было сделано миллион раз раньше, круто, вот так».

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

Люди используют их все время, и тогда это становится своего рода надвигающимся стрессом, который вы должны не отставать от поддержания этой вещи. Люди могут стать папами, жениться, просто пойти в другие места в своей жизни. И об этом [говорили] раньше, но я думаю, что об этом мы должны поговорить. Люди с открытым исходным кодом нуждаются в таком психическом здоровье. Открытый исходный код не должен быть предметом, о котором людям приходится беспокоиться из-за необходимости поддерживать и переживать из-за стресса. Я думаю, что как сообщество мы должны приложить все усилия, чтобы не просто поблагодарить, но и помочь разработчикам ПО с открытым исходным кодом везде, где мы можем, потому что, эй, мы все используем их вещи.

Дэвид:

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

Тим:

Да, что бы вы сказали, чтобы мы помогли решить эту проблему?

Дэвид [36:00] :

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

Тим:

Да, я часто думаю об этом с точки зрения того, что я ловлю себя на том, что смотрю на кандидатов и спрашиваю себя: «Ну, я не могу найти что-то в их профиле GitHub. Я не могу найти для них профиль GitHub или CodePen »или что-то в этом роде, поэтому я не думаю, что этот человек — отличный программист. Я должен поймать себя, и потом я помню, что не у всех есть привилегия просто пойти домой и дурачиться на GitHub в течение часа. Некоторые люди должны поужинать для всей своей семьи или даже работать на дополнительной работе, чтобы свести концы с концами. Я хотел бы сказать кое-что, что я знаю лично, что я могу сделать лучше, это поймать себя, прежде чем я буду судить кого-то за отсутствие профиля GitHub.

Дэвид:

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

Тим:

Я думаю, что мы определенно должны сделать это. Да, это отличное предложение. Я думаю, что один из наших следующих эпизодов должен быть посвящен этому.

Дэвид:

Я думаю, что мы можем сделать это.


Ну, спасибо всем за внимание, все. Нам всегда нравится говорить со всеми вами о технологиях.

Тим:

Мы также хотели бы поблагодарить SitePoint.com и наших продюсеров, Адама Робертса и Офели Лехат. Пожалуйста, не стесняйтесь, присылайте нам свои комментарии в Twitter — @versioningshow — и дайте нам оценку на iTunes, чтобы сообщить нам, как мы делаем.

Дэвид:

Увидимся в следующий раз и надеемся, что вам понравилась эта версия.