‹H1› Алоха, мир ‹/h1›

Недавно мне посчастливилось побывать на JS Conf Hawai’i. (Я знаю, верно? Как мне это удалось?) Это было намного лучше, чем я ожидал по многим причинам. В частности, веселые ведущие, которые могли придумывать шутливые шутки разработчиков на лету во время технических трудностей, потрясающие презентации и, конечно же, все о Гавайях. 😍

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

да, королева - но не дерзай

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

"Это обратная сторона, но не навсегда". - Сэм Беллен

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

Да, в консоли есть ошибки, но не беспокойтесь об этом. - Чарли Джерард

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

favTalks («все?»);

Способность мыслить как коренной гавайец в области технологий

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

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

«Бесполезное не бесполезно. Я многому научился в процессе ». - Чарли Джерард

Для меня это не новость. Я научился этому в качестве стажера на моей теперь постоянной работе. Они научили нас терпеть неудачи и терпеть неудачи быстро. А когда вы терпите неудачу, вы повторяете. Повторяйте столько, сколько вам нужно. Но на самом деле эту концепцию итераций я усвоил задолго до того, как начал работать в технологической индустрии. Когда я учился в колледже в ROTC, мы узнали что-то под названием BAMCIS, что означает начало планирования, организацию разведки, выполнение разведки, завершение плана, выдачу приказов, контроль. Вся идея в том, что вы учитесь на разведке (оцениваете риск), и даже после завершения миссии вы учитесь. Вы узнаете, удалось ли вам это или нет, и каждый раз, продвигаясь вперед, вы узнаете что-то новое. Несмотря на то, что я знал эту концепцию итерации, это был первый раз, когда она была представлена ​​мне как идея быть негодяем или шутником, и мне это понравилось!

«Чтобы повлиять на мир, понадобится немного Колохе». - Тейлор Хо

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

«Возможно, настоящий JavaScript - это друзья, которых мы создаем в процессе». - Член комиссии TC39

Вашим тестам не хватает зрения: добавление глаз в вашу среду автоматизации

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

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

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

«Наши сценарии хуже, чем мы». - Энджи Джонс о слепоте из-за невнимательности

Искусство комментирования кода

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

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

Подводя итог, хорошие комментарии объясняют, почему вам нужны определенные строки кода. Они также разъясняют, что не читается людьми (например, регулярное выражение). Их можно использовать в качестве обучающего инструмента, например, для объяснения кода учебника, и мое самое любимое использование комментариев, они могут быть как главы в книге (отдельные комментарии). Это типы комментариев, которые я привык писать, но есть один тип хороших комментариев, который я раньше не рассматривал. Сара назвала их комментариями «это нормально для рефакторинга». Мне понравилась эта идея, потому что она автоматически дает людям разрешение изменить наш код, когда у них будет больше времени, потому что давайте посмотрим правде в глаза, иногда нам просто нужно уложиться в срок. Подобные комментарии не только сделают нас более ответственными, но также помогут нам отслеживать все наши технические долги.

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

"Здесь можно отучиться столько же, сколько и чему-то научиться". - Справочник Basecamp

Разработка еще более крупных (JavaScript) приложений

Хотя я, скажем, не работаю над приложением, доклад Malte Ubl был для меня очень интересен, потому что было много моментов, которые, как я думал, можно применить и к дизайн-системе. Что мне показалось наиболее интересным в его выступлении, так это то, что он поднял о постепенном усыновлении. Это показалось мне наиболее актуальным, потому что в прошлом году моя команда выпустила, пожалуй, самые важные критические изменения, которые у нас когда-либо будут после полного изменения внешнего вида нашей дизайн-системы. Наша самая большая проблема заключалась в том, как мы можем помочь людям перейти на эту совершенно другую вещь? И, вдобавок ко всему, как мы можем наилучшим образом продолжить работу с техническим долгом, на который пришлось пойти на компромисс в связи с нашим крайним сроком выпуска? В своем выступлении Мальте привел три идеи, которые, я думаю, могли бы изменить правила игры, помогая нам оставаться организованными в процессе выпуска релизов и, надеюсь, в будущем для любых других критических изменений.

  1. Заведите реестр технического долга. Честно говоря, это гениально. Если бы мы просто вели оглавление или своего рода указатель, который указывал на весь технический долг, который у нас был, люди могли бы просто пойти и забрать один из этих предметов во время простоя, и мы могли бы постепенно взяться за этот список. Это очень напоминает мне мексиканских мам. Если вы выросли с мексиканской мамой, вы знаете, что вам никогда не позволят скучать. Если вы говорили маме, что вам скучно, она отвечала: «ponte a limpiar», или здесь, * протягивает вам метлу * иди почисти что-нибудь. Это технический эквивалент этого. А у тебя есть свободное время? Вот и приступайте к работе над нашим списком технических долгов.
  2. Иметь «разрешенный» список для устаревшего кода или устаревших шаблонов. Весь новый код должен соответствовать новому способу выполнения.
  3. Используйте линтер для устаревших шаблонов.

Дизайн-системы - это качество в сжатые сроки. - Алекс Секстон

«Идеальный» библиотечный инструментарий

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

Как и в дизайн-системе, наши пользователи одновременно являются дизайнерами и разработчиками. Однако только недавно мы постарались получить больше отзывов от наших пользователей, и все, что сказал Бен, только убедило нас в том, что мы идем в правильном направлении. Бен отметил, что в качестве инструментария библиотеки мы должны измерять наш успех по тому, насколько хорошо мы можем предоставить то, что хочет наш конечный пользователь. Не думаю, что когда-либо задумывался о том, что делает нашу дизайн-систему успешной, пока мы не начали сомневаться, предоставляем ли мы вообще то, что нужно нашим пользователям. Если бы вы спросили меня год назад «успешен ли Carbon?», Я бы ответил утвердительно. Мы только что выпустили новую версию компонентов, которые были лучше во всех отношениях: UX, UI, a11y. Но я ни разу не подумал, действительно ли мы даем нашим пользователям все, что им нужно для выполнения своей работы.

В конце концов, если вашим пользователям все равно, действительно ли это был успешный проект? - Милесия МакГрегор

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

Панель TC39

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

Это было для меня интригующим, потому что это международная группа, что для меня означало, что они, вероятно, имеют дело с большим количеством предложений, возможно, аналогичных тому, что может увидеть система дизайна международной компании. [долгая пауза для эффекта] Ребята! 👏🏽Это проблема, над которой моя команда пыталась определить процесс долгое время! Так что вы не можете себе представить, какое волнение я испытал, когда узнал о процессе подачи заявки TC39. В голове я подумал: это возможно? Если это что-то, что они могут определить и эффективно решить, можем ли мы это тоже сделать ???? Можем ли мы иметь четко определенный процесс подачи заявок ???? !!!!!

Итак, вот что я узнал. У них есть 5-этапный процесс подачи заявок.

  • Этап 0: есть идея.
  • Этап 1: они определяют, стоит ли обдумывать эту идею.
  • Этап 2: идея требует определенных технических характеристик.
  • Этап 3: идея требует как минимум двух воплощений. Каждая реализация используется для устранения несоответствий.
  • Этап 4: наконец-то появился язык, но он должен пройти множество тестов производительности, прежде чем даже появится.

Процесс предложения каждой идеи возглавляет так называемый «чемпион», другими словами, делегат от группы TC39. Что меня еще больше заинтриговало, так это их стандарт рассмотрения идей, потому что, честно говоря, это самая сложная часть. Когда они ответили на этот вопрос, я понял, что, возможно, мы не смотрели на запросы функций в правильном объективе. Их ответ был: есть ли проблема, которую мы собираемся решить? Не "это новая функция или API?"

"Есть проблема, которую мы собираемся решить?" - Член комиссии TC39

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

«Одно из моих самых больших достижений в комитете - это помощь в его уничтожении». - Член группы TC39 по ECMAScript 4

Все остальное

Если вы зашли так далеко, я люблю вас. 😭 Я печально известен тем, что не могу выбрать что-либо любимое, как вы, возможно, заметили в моем «любимом» разделе бесед. Честно говоря, я кое-что извлекал из каждого выступления, и я просто подведу итог, перечислив некоторые из этих выводов.

Когда дело доходит до концепций, о которых я мало что знаю, два наиболее поучительных выступления, которые я слышал, были Прогрессивный рендеринг: повышение производительности веб-приложений в более медленных сетях Динеш Пандиян и Убей всех мутантов! (Введение в тестирование мутаций) автора Дэйв Аронсон . Мне также очень понравилась Очень отзывчивая типографика с переменными шрифтами от Мэнди Миши l, потому что она действительно подчеркнула использование возможностей переменных шрифтов для улучшения доступности. Мне понравился Посмотри, что ты делаешь MIDI от Рэйчел Уайт, потому что она вдохновила меня на поиск новых и уникальных способов использования моих навыков программирования в вещах, которыми я увлечен. Мне нравится доклад Чарли Джерарда Примите позу: распознавание жестов в JavaScript с помощью машинного обучения и Arduino, потому что, хотя я ничего не знаю о ML и Arduino, у нее была супер классная демонстрация. и я понял, что создание чего-то бесполезного не означает, что я ничего не получу от этого; Я буду учиться по пути. Наконец, мне понравился доклад Даная Валентина Цифровое колдовство: использование магического мышления для продвинутого цифрового дизайна, потому что она подняла уникальный момент: магия - мать технологий. Прежде чем что-то будет Создано, идеи и возможности кажутся необычными, в некотором смысле волшебными, а затем вы строите его, и это реально. Я настоящий волшебник, воплощающий в жизнь магию. Кто бы это подумал?

«Мой любимый вид программирования - это попытки делать то, чего я никогда раньше не делал». - Рэйчел Уайт