През февруари 2019 г. екипът на общността на ApeeScape стартира съвсем нова инициатива: месечна възможност за взаимодействие с мрежовите експерти на ApeeScape в реално време. Сесиите „Попитай ме всичко“ (AMA) са отворени за всички членове на основния екип и мрежа от таланти на ApeeScape - всеки може да зададе въпрос. В тази статия подготвихме избрани въпроси и отговори от AMA с експерт по JavaScript и Redux Ерик Расмусен. Ерик обсъжда предизвикателствата на разработката на софтуер с отворен код, съвети за разработчици и колебливия свят на JavaScript, как се справя със синдрома на измамника и прегарянето като търсен разработчик, както и своите най-добри препоръки за подкасти.

Ерик е пълен стек JavaScript експерт с над 25 години опит в разработката, специализиран в React, Redux, формуляри в React и GraphQL. На GitHub - уеб базирана хостинг услуга за контрол на версиите с над 28 милиона потребители - той получи място в топ 100 с над 20 000 звезди. Освен това е автор на първата и третата най-популярна библиотека на формуляри в React: Редукс-форма и React-Final-Form .

Redux форма и състоянието на софтуера с отворен код

Защо решихте да създадете друга библиотека с формуляри след огромния успех зад вас Редукс форма ?

Научих много уроци по пътя с Redux Form и придобих представа за нуждите на разработчиците на React Form по целия свят. Някои от проблемите с React Form просто не можеха да бъдат решени, без да погледнете наново проблема. (Повече подробности тук .)

Много разработчици мечтаят да създадат масово популярен проект с отворен код. Какви са някои от неочакваните последици (добри и лоши) от успеха на проект като Redux Form?

Изключително възнаграждаващо е, когато можете да поправите грешка, която задържа разработчика или цял екип да завърши проект. Освен това е наистина страхотно, когато хората сами намират и отстраняват грешки. Досега хората бяха много мили и любезни, когато искат помощ; Все още не съм имал взаимодействие с праведен потребител, който смята, че му дължа поправка.

От предизвикателната страна изгарянето е истинско нещо и все още не сме открили начин да компенсираме разработчиците на OSS, че отделят своето време и енергия за проектите на OSS. Redux Form се използва от милиардни корпорации по целия свят за извършване на бизнес и съществуването му е спестило хиляди часове за разработка на екипи, които са го инсталирали, но няма добро решение да се даде дори частица от тези пари на авторите .

Има ли обещаващи решения в работата за компенсиране на разработчици с отворен код като вас?

Един мой приятел стартира тази компания, наречена CodeFund . Той имаше тази идея: „Ами ако можем да поставим реклами в документацията на библиотеката с кодове?“ Като разработчици прекарваме цял ден в разглеждане на документация и измисляне как да приложим каквото и да е нещо, което правим. Освен това разработчиците печелят много повече пари от средния ви уеб сърфист, така че ние сме потенциал за луксозен продукт.

CodeFund излезе с идеята, че документацията е наистина чудесно място за реклама. Бях един от първоначалните пилоти. Работи доста добре, но се сблъскаха с проблем с GitHub. Първоначално пускахме реклами в самото хранилище на GitHub, но GitHub и адвокатите се нахвърлиха и казаха „не“. Което е жалко. CodeFund преговаря с тях известно време, но в крайна сметка те отказаха.

С добре трафикирана библиотечна документация можете да получите може би 150 долара на месец, което не плаща за това, което си струва. Има някои редки библиотеки - като Babble или Webpack - където им се дават достатъчно пари, за да могат действително да подкрепят двама или трима програмисти на пълен работен ден, работещи за подобряване на това нещо. Babble и Webpack - компаниите на стойност милиарди и милиарди долари седят върху тяхната инфраструктура и със сигурност Redux Form ги подкрепя.

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

Защо да създавате нещо, което е с отворен код и безплатно? Какъв е стимулът за разработчици като вас?

Причината да го създадете е, защото ви е необходим за каквото и да е, върху което работите в момента. Когато го пуснете, идват други и го правят по-добър. Мечтата с отворен код е да кажете: „Построих малка количка, която ми помага да пренасям скалите си от тук натам“, а след това идва някой и те го правят по-добър. При следващия си проект се връщате назад и използвате същата библиотека и казвате: „Уау, това нещо се движи много по-бързо. Сега е по-добре. '

Също така е много полезно. Получавам допаминов удар, когато хората казват: „Това ни задържа в продължение на три седмици и тази малка корекция, която ви отне три часа, ни спести три седмици време.“ Има малко цикъл на пристрастяване с това, при който получавате положително подсилване и той просто се чувства добре.

С моята библиотека с втори формуляр хората не казваха толкова много: „Хей, искаме друга библиотека с форми“, просто измислих начин да го направя по-добър.

Това е нещо като мечтата защо го правите. Но със сигурност не е заради парите.

В идеалния свят колко компенсация бихте получили за създаване на софтуер с отворен код? Само малко черешка на тортата?

Не бих имал нищо против, ако някой ми плати шест цифри, за да работя само с отворен код по цял ден. Ако погледнете генерираната стойност спрямо разходите, съотношението за отворен код е толкова високо. Стигате до малки миниатюрни библиотеки, които правят едно нещо и едно наистина много, много добре.

Ако всяка компания в света трябваше да назначи собствен екип от разработчици, за да направи това, резултатите щяха да варират в много широки граници. Фактът, че имаме отворен код и можем да имаме едно решение за това - един балон на алгоритъма в горната част, който е най-добрият - означава, че всеки в света има тази вградена ефективност.

Друга ценност от отворен код е, че ако използвате нещо, което сте написали и само вашата компания го използва. . . сравнете това с нещо, което 1000 компании използват. Те са открили всяко малко кътче от мястото за грешки, което потенциално би могло да създаде проблем, а вие вземете това и го включите във вашето нещо - вие сте златни. Ще имате толкова повече доверие в това.

Динамичният свят на JavaScript

След като сте били толкова дълго в пространството на JavaScript, трябва да сте видели толкова много нови горещи рамки [за изграждане на приложения на JavaScript], които идват и си отиват. Как поддържате пулса на индустрията, за да можете да решите към какви рамки да се ангажирате?

Трябва да усетите ветровете на общността на разработчиците. Текущата битка между TypeScript и Flow е чудесен пример. Първоначално избрах грешния кон в това състезание, предполагайки, че Facebook ще бъде по-добър стопанин на рамката за писане. Но мисля, че TS почти спечели тази битка и сега бавно мигрирам нещата в тази посока.

Има ъгъл на Twitter, който е „разработчик Twitter“. Ако следвате достатъчно хора - може би се нуждаете от проба с размер около стотина - можете да усетите къде духат ветровете и какво става популярно. Ще получите много публикации като „Преди използвах библиотека А, но току-що научих за библиотека Б и всичко е много по-лесно.“ Получавате достатъчно от тях и казвате: „Е, може би трябва да проверя тази друга библиотека.“

Тенденциите идват и си отиват в пространството на JavaScript. Винаги ли ще бъде в движение?

Мисля (и се надявам) тя ще продължи да се развива. Стагнацията е смърт в технологиите. Дори Java в момента прави иновации значително: Нещата, които можете да правите в Java 10, не приличат на Java 6 на вашата баба.

Може да е изтощително най-накрая да създадете приложението си с Tech X, само за да видите, че всички страхотни деца вече използват Tech Y. Но това е индустрията, в която сме заети.

Според вас, кои концепции на JavaScript са особено важни, за да се разберат наистина, за да се овладее езикът?

Бих казал, че функционалното програмиране и идеята за предаване на функции наоколо е доста важна. Особено ако идвате от език като Java или C ++.

Смятате ли, че React трябва да се използва за изграждане на SPA [приложения на една страница] или само за компоненти на обикновена страница?

Това е красотата на React: Толкова е универсален. Бавно въвеждам React за всички нови функции в старо приложение Java / jQuery в ежедневната си работа. React работи добре, ако има DOM възел, по който да действа. Не е необходимо да контролира цялото приложение.

Когато стартирате ново приложение React, кои са инструментите и библиотеките, които редовно използвате от нулата?

Мисля create-react-app е явният победител в това сега. Преди четири години, когато нямаше нищо подобно, беше много по-трудно.

Как се справяте със състоянието на приложението във вашите реагиращи приложения?

Когато Redux излезе, това очевидно беше отговорът. Открих обаче, че голяма част от моето „състояние“ на Redux е нещо като loading и listOfObjects и наскоро използвах Apollo GraphQL за тези неща. Други неща като isSideNavOpen може да се управлява с контекстно базирани компоненти доста лесно. Въпреки това все още има някои легитимни случаи на употреба за Redux, но нито един, който да съм срещал в моите прости React приложения.

Кой е любимият ви редактор / IDE?

Ах, че въпрос!

Идвам от Java и съм много доволен от JetBrains IntelliJ от много години, но е малко бавен за JS. Първо отидох в Atom, но накрая се спрях на VS Code. Неговите интеграции за Jest и Flow и TypeScript са ненадминати.

Какво е вашето мнение за изоморфното развитие като opal което превежда ruby до JS и след това отваря пътя за Rubysts да пише React / Flux-структурирани приложения в Pure Ruby (без да пише JS)?

Фактът, че JavaScript направи скок към сървъра, мисля, че е голяма работа. Възможността да се изобразява с един и същ код както на клиента, така и на сървъра е огромен и по-вероятно пътя на бъдещето.

Кой според вас е най-големият проблем на настоящите ни най-популярни JS рамки?

Не съм напълно сигурен, но наистина харесвам посоката на css-in-js, без сървъри и SSR, която компании като Zeit преследват с Next.js.

За мен е наистина смешно, тъй като някой, който създава уебсайтове в края на 90-те години, се връщаме към статичните уебсайтове. Връщаме се към генерирането на всичко по време на компилация, а след това имате вашите статични неща на сървъра и след това можете да добавяте динамични неща чрез това, което те наричат ​​повторно хидратиране. След като рендирате цялата страница, можете да получите допълнителния JavaScript, за да направите нещата анимирани и да премествате компоненти.

Zeit, с тяхната рамка Now, също поддържа статично изграждане на вашия уебсайт, защото нищо не е по-бързо от изтеглянето на статичен HTML файл. Това е само текстов файл и след това бум, разбрахте го. Докато ако удряте сървър, той трябва да удари база данни може би четири или сто пъти, само за да изгради каквато и да е страницата, която трябва да покажете. Това е супер бавно.

Статичната идея набира популярност.

Смятате ли, че JavaScript може да поеме „зрели“ езици (като Java и C ++) и да се превърне в предпочитан език за предприятие?

Определено. Нещата, които хората правят сега с „безсървърния“ възел, са изключително мащабируеми и мисля, че корпоративните приложни програмни интерфейси [интерфейси за програмиране на приложения] могат и ще бъдат пренаписани в JavaScript, поне от по-гъвкавите и перспективни корпорации.

Какво трябва да търси разработчикът в клиент?

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

За синдром на измамника, изгаряне и премахване на стреса

Синдромът на Imposter изглежда не е необичайно явление сред разработчиците. Изпитвате ли го и ако да, как се справяте с него?

Абсолютно. Особено когато говорим на конференция. (Или правите AMA?)

Що се отнася до преподаването / наставничеството, трябва да осъзнаете, че знаете повече за това, което правите, отколкото миналия месец, който сте направили. Ерго, винаги има хора, които са се върнали там, където бяхте преди, които биха могли да се възползват от вашите знания.

Също така е важно да можете да кажете: „Не знам, нека да го разследваме заедно“ (също добър съвет за родителство).

Какъв е денят в живота ви? Как да планирате всичко, така че да не работите 100 часа седмично и да не изгаряте?

Когато наистина съм се задълбочил в отворения код, това отнема много повече време; понякога трябва да се отдръпна за около месец в продължение на месец. Водя децата си на училище и след това прекарвам време, разглеждайки какви проблеми имат хората. Ако те са наистина сериозни, тогава прекарвам малко усилия, опитвайки се да ги поправя или да отговоря по полезен начин.

Имам дневна работа, която изобщо не е свързана с отворен код, което отнема много от времето ми. През целия ден имам настроени известия, за да мога да видя дали има сериозен проблем с нещо. Ако е пусната нова функция или нещо подобно, тогава има по-голяма вероятност да има грешки по това време.

Научих, че който пише изискванията за даден проект, е сигурен, че „Това трябваше да бъде направено вчера, така че защо още не е направено?“ Толкова пъти съм имал, когато какъвто и да е екип, който получава моята работа, отнема около три седмици, за да я пусна в производство. И вие казвате: „Е, за какво беше целия този стрес?“

Ако дадена задача трябва да бъде изпълнена до петък, а това приключва до следващия петък, почти никога бизнесът не спира, защото сте се провалили. Когато си млад и не знаеш по-добре, се чувства като: „О, боже, трябва да извадим това от вратата.“ Но след като сте направили това достатъчно пъти и видите: „Чакай малко, това, което ни казваха, че не беше наистина вярно“, можеш да кажеш „Добре, да. Както и да е. Ще свърши, когато свърши. '

Бях малко изгорял миналия октомври, когато React обяви това нещо, наречено React Hooks. Ако бях там, готов да се захвана с каквото и да било ново нещо и да избягам с него, можех да измина доста километраж, тъй като бях един от първите хора, които влязоха в React Hooks. Някак си внимавам какво може да бъде следващото голямо нещо.

Какво правите през свободното си време, за да намалите стреса?

Разхождам се и слушам подкасти, които не са свързани с развитието.

Някой, който бихте могли да препоръчате?

Единствените истински технологични подкасти, които слушам, са Недефинираният подкаст , което касае само допирателно съвети за технологии и разработчици. Аз също слушам React Podcast —На който скоро ще се появя (надявам се да има някакъв смисъл, в зависимост от качеството на редактора им).

Гледайки избрания от мен ловец на шушулки, Облачно , моите най-приоритетни подкасти включват:

• Родерик на линия
• Има смисъл
• Случайна технологична подкаст
• Пътна работа
• Експонента
• Здравей Интернет
• Radiolab
• Отговори на всички

Наскоро всъщност сам стартирах два подкаста:

Първият се нарича Търсете справедливост , в който аз, умерено интелигентен човек, който не знае почти нищо за системата на наказателното правосъдие, интервюирам един мой приятел, който е прекарал цялата си кариера в проверка и работа по нейната реформа. Той работи директно с губернатори на няколко щати в САЩ за намаляване на популациите в затворите и рецидиви след освобождаването. Това не е тема, която някога съм се интересувала наистина, но моят съ-водещ ме завладява всеки епизод.

Второто е шоу на чиста глупост, т.нар Честит час с Денис и Ерик , в който със същия приятел си хапваме по няколко вечерни напитки, говорим за живота си и се разсмиваме. Търсете справедливост е за пътуването ви с работа с ярки очи, а Happy Hour - за размотаващото ви пътуване до дома.

За да го върна към разработчиците, усилията ми за подкасти ми помогнаха да разреша проблем, за който не можах да намеря решение в индустрията: лесен MP3 плейър с обложки на албуми, който също работеше като Twitter карта. Затова написах Аудиокарта .