スマッシングポッドキャストエピソード32：2020年のレビュー

公開: 2022-03-10

簡単なまとめ↬このエピソードでは、2020年を振り返ります。今年のエピソードでは誰と話しましたか。また、何を学びましたか。いくつかのクリップを聞いて調べてみましょう。

このエピソードでは、2020年を振り返ります。今年のエピソードでは誰と話しましたか。また、何を学びましたか。いくつかのクリップを聞いて調べてみましょう。

メモを表示

podcast.smashingmagazine.comで、すべてのインタビューの完全なトランスクリプトを含む、過去のすべてのエピソードを見つけることができます。

2021年に会いましょう！

トランスクリプト

Drew McLellan： 1月、私はAmy Hupeに、英国政府の設計システムに関する彼女の取り組みについて話しました。特に、チームが貢献を奨励することで、より広い組織によるシステムの採用をどのように増やしたかについて話しました。これがエイミーです。

Amy Hupe：私たちは本当に早く始めました。それで、ある種のパブリックデザインシステムができるずっと前から、私たちはある種の興味のある貢献者になるだろうと思っている人々と関わり始めました。ここで、チームには優秀なサービスデザイナーがいました。彼女は私たちに加わった…現時点では日付を正確に把握するつもりはないが、彼女は2018年全体で私たちと協力してくれたと思う。彼女の名前はイグナシアだ。彼女はただ周りを回って人々を魅了するという素晴らしい仕事をしました。それで、彼女がしたことの1つは、政府のさまざまなパターンのすべてと、それらのパターンのさまざまな種類のバリエーションをすべて特定することでした。それで外に出てこう言います政府で住所を尋ねるには10の異なる方法があります。それらをすべて一緒に見て、どれが最も適切なアプローチであるかを判断しましょう。これらを1つに統合するにはどうすればよいですか？」

Amy Hupe：彼女は大きなワークショップを開催して、人々にそれらを見てもらい、チームとしてそのような統合を行ってもらいました。私たちが実際に何かを公開する前に、ある種のコラボレーションを構築するという彼女のアプローチは、人々がすでにそのような認識を持っていて、多くの人々がすでに何らかの形でそれに貢献していたことを意味するので、それは本当に助けになったと思います。実際に公開する前にもう1つ。ですから、私たちはほんの数歩先を過ぎていました。ですから、それは本当に重要であり、永続性であり、人々が貢献するのを助けるという意味で、チーム全体からの多くの永続性であると思います。

Amy Hupe：人々にデザインシステムに貢献してもらうとしたら、それはとても素敵なギグだと思います。なぜなら、人々にすべての仕事をしてもらうことができ、そこに座って、あなたはあなたの小さなコードを修正してください、そして誰もが実際にあなたにすべての良いものを与えています。しかし実際には、設計システムに取り組んでいる人なら誰でも知っているように、それは信じられないほど複雑です。複数の異なるチームで機能する一元化されたソリューションを作成することは非常に困難です。

Amy Hupe：実際、設計システムに取り組んだことがない限り、それが何を必要とするのかを誰かが本当に理解することを期待するのは合理的ではありません。ですから、たくさんの種類の手持ちがあります。貢献者の貢献を支援することには多くの仕事が関わっています。これは前にも言ったと思いますが、自分で一元化したチームを作るよりも、誰かがデザインシステムに貢献できるようになるまでには、おそらく時間がかかると思います。しかし、それがもたらす価値を認識し、人々に貢献を認識させ、貢献を支援し、やる気を感じさせるための努力に粘り強く取り組むことは、そう、持続性が本当に重要だったと思います。その分野での私たちの成功。

Drew： MicrosoftのStephanieStimacとAaronGustafsonが加わり、EdgeがレンダリングエンジンとしてChromiumを採用していることについて話しました。私はAaronに、ブラウザー間の競争の状況と、同じレンダリングエンジンで合体する複数のブラウザーがその健全な競争を打ち負かし、オープンWebに悪影響を与える場所について尋ねました。

Aaron Gustafson：これは、私が長い間Web標準の担当者として少し苦労してきたことです。私はそれに対するビジネス上の正当性を完全に理解しています。 Microsoftの観点からは、それは非常に理にかなっています。フロントエンドの開発者の観点からは、さまざまなエンジンに対応する必要がないのは素晴らしいことです。つまり、全体として、長い間Webに取り組んできた私たちの人々は、レンダリングに関して確かに多くの収束を見てきました。私たちが抱えていた問題はそれほど多くありません。たとえば、Netscapeで7日間過ごしたときのように、ブラウザごとに独自のスタイルシートを作成している企業を知っていました。

Aaron Gustafson：しかし、今のところ違うのは、元のブラウザ戦争に戻って、これらの独自のエンジンをすべて持っていて、新しいプラットフォーム機能を出荷しようとするという点で、誰もが一種のワンアップマンシップのゲームに参加していたことだと思います。新しいJavaScript機能、またはMicrosoftの場合はJavaScriptをリバースエンジニアリングして、JScriptを作成し、それをすべて組み合わせる方法を見つけようとします。

Aaron Gustafson：しかし、今ではオープンソースプロジェクトで実際に協力し、対話を続け、それでも…わかりません。ファイトは正しい言葉ではありませんが、さまざまなアプローチの影響について真剣に話し合い、お互いに意見を異にし、スペックを本当に良いものにすることに真剣に取り組み、たとえばChromiumのコンテキスト内で基盤となるコードに競合するアプローチをとることです。 FirefoxスペースのプロジェクトまたはWebKitまたはその性質の何かまたはミズーラ。

アーロン・グスタフソン：そうですね。一方で、私たちは別のレンダリングエンジンを失いました、そしてオペラがChromiumに行くことに決めたとき、私は同じ痛みを感じました。しかし、マイクロソフトの内部にいて、Chromiumプロジェクトに実際に有意義な方法で参加し、Chromiumの下流にあるすべてのものを受け入れるだけでなく、実際に何が起こっているのかを精査することにどれほど熱心に取り組んでいるかを見ると、少し心強いです。プラットフォームとそれに参加しています…ええ。

アーロン・グスタフソン：それで、私はそれによって少し心強くなり、私たちはそのプロジェクトから引き継ぐだけでなく、そのプロジェクトに利害関係を持つすべてのさまざまな人々から受け継がれるものを受け入れるだけでなく、実際にそこでも協力しています。

Drew： 2月に、Bootstrapや友人などのUIフレームワークを操作し、それを使用可能なインターフェイスのカスタマイズされたニーズとバランスさせることについて、StephanieWalterと話しました。私はステファニーに、既成のフレームワークを使用しながら非常に使いやすいUIを作成できるかどうか、またはそれが常に少し厄介な妥協になるかどうかを尋ねました。

ステファニー・ウォルター：うん。私はそう思う。しかし、それはあなたがやろうとしている妥協のレベルにも依存し、これは双方の妥協です。現時点では、多くのボタンを妥協しています。たとえば、マテリアルUIに特定のボタンがいくつかあるためです。ボタンの波及効果はあまり好きではありません。モバイルでは、ユーザーがボタンをクリックまたはタッチしたときに、ある種の大きなフィードバックが必要になるため、モバイルではうまく機能すると思います。しかし、それから彼らはボタンにずっと続くこの種の波及効果を踏みます。特にボタンがたくさんある場合は、少しやり過ぎです。しかし、これはReactフレームワークに組み込まれているため、削除するのは非常に複雑であり、このボタンに別のホバー効果を持たせるため、この波及効果を維持します。これは、この種のふさふさしたものではない、より微妙なものです。ここ。それは非常に複雑になります。つまり、これはあなたが行う一種の妥協案です。

ドリュー：倫理的なデザインは、トリナ・フェルバーとマーティン・マイケル・フレドリクソンとの会話の主題でした。デザインに倫理的なアプローチを取り、ダークパターンを回避することは、短期的な販売目標だけでなく、ビジネスの健全性と成長について長期的に考える場合であるかどうかを尋ねました。これがマーティンです。

マーティンマイケルフレドリクソン：それは完全に真実です。中規模の都市のメインストリートに店があるかのようにオンラインで行っているビジネスを見る必要があると思います。そこでは評判を維持する必要があります。あなたがあなたの顧客をうまく扱わないと、あなたがあなたの顧客を長期的にうまく扱わないと、人々が他の店に行くか、彼らがオンラインから買うので、あなたは廃業するでしょう。したがって、オンラインで何をするにしても、長期的な効果があることを本当に考えなければなりません。また、複雑なことや操作することを行うには、隠れたコストがかかります。 Trinaが言うように、整理整頓すると、長期的な節約になります。ビジネスモデルについて話すとき、それは決して計算されません。あなたはいつもあなたがどれだけのお金を稼ぐことができるかについて話します。あなたはその金額を稼ぐための費用について決して話しません。

Drew： 3月、私はEduardo Boucasに、異なるソースからコンテンツを収集して静的サイトジェネレーターで利用できるようにするSourcebitと呼ばれるオープンソースツールについて話しました。ヘッドレスCMSなどのツールとの統合を可能にすることで、SSGの承認のユーザーエクスペリエンスを向上させることができるかどうかをEduardoに尋ねました。

Eduardo Boucas：その通りです。うん。それができる方法…私は、開発者を助けることができるツールを使用する2つの異なる方法を見ています。 1つは、Sourcebitをデプロイメントルーチンの一部にすることです。たとえば、Netlifyなどのホスティングプラットフォームを使用していて、デプロイコマンドを次のように構成している場合、Hugoビルドかどうかはわかりませんが、Hugoのビルドコマンドか何か、そのようなコマンドですHugoの静的ファイルを生成します。また、そのルーチンの一部として別のコマンドがあります。これは、Sourcebitフェッチのようなものになります。したがって、ビルド時に、Sourcebitは他のすべてのデータをプルし、Hugoが必要とするすべてのファイルを生成します。その後、デプロイメント全体がすでにそれらのファイルを使用し、CMSからのすべてのコンテンツをデプロイします。

Eduardo Boucas：これはSourcebitの1つの可能なユースケースの一種です。もう1つは、ローカル開発ワークフローでローカル開発としてSourcebitを使用することです。したがって、ウォッチモードと呼ばれるものでSourcebitを実行できます。そのため、Sourcebitはリモートデータソースの変更を探し続けます。この場合、ヘッドレスCMSです。したがって、記事を公開したり、エントリをCMSに変更したりすると、Sourcebitはそれを認識し、すべてのファイルをローカルで再生成します。

Eduardo Boucas：つまり、ローカルで作業する開発者にとって、Hugoサイトの横にあるCMSウィンドウをローカルで実行すると、変更がリアルタイムで発生するのを確認できます。 CMSで何かを変更すると、その変更がローカルサイトに反映されていることがわかります。これは、非常に便利です。つまり、これらはSourcebitを使用できる2つの方法の一種です。

ドリュー：コンバージョンの最適化がその日のトピックでした。ベテランのポッドキャスター兼コンサルタントであるポール・ボーグと話をしたとき。サイトが訪問者を顧客に変えるために使用するいくつかのテクニックについて話しました。しかし、私はポールに、あなたが行った変更の影響をどのように測定するかを尋ねたかったのです。ポールは説明した。

ポール・ボーグ：うん。絶対。繰り返しになりますが、これは多くの組織が成功を測定する方法について明確になっていることで非常に貧弱なことだと思います。はい、コンバージョン率は1つの指標です。あなたは絶対に従うべきです。しかし、コンバージョンを達成したとしても、購入する人の数よりも少し洗練されている必要があります。また、平均注文額にも注意を払う必要があります。生涯価値に特に注意を払う必要がありますよね？つまり、ダークパターンなどを使用すると、顧客の解約率が非常に高くなることがよくあるため、顧客の生涯にわたる価値はどれくらいかということです。しかし実際には、コンバージョンは測定している指標の1つにすぎないはずです。

Paul Boag：エンゲージメントに注意を払う必要がある、コンテンツに対する人々のエンゲージメントの程度などもあります。それは、最終的にコンバージョンに進むかどうかに大きな違いをもたらすからです。つまり、あなたはあなたのビデオの量、彼らが見ているのか、彼らがあなたのサイトにどれくらいの時間を費やしているのか、そして彼らがそれをしている間に彼らが何を見ているのかなどを見ていますか？彼らはソーシャルメディアやそのようなものに取り組んでいますか？そして最後の側面は明らかに使いやすさです。あなたは誰かが彼らのウェブサイトで特定のタスクをどれだけ速く完了することができるか、そして彼らがシステムを使うことをどれほど簡単に見つけることができるか、そして他の様々な異なる基準を測定する必要があります。

Paul Boag：これらのさまざまなものを測定するために使用できるメカニズムはたくさんあります。そこにはいくつかの優れたツールがあり、採用できるいくつかの優れたメトリックもあります。したがって、たとえば、ユーザビリティには、システムユーザビリティスケールと呼ばれるものがあります。これは、測定するのに非常に便利なメトリックです。しかし、同様に、maze.designのようなツールがあります。これは、誰かが購入するのにかかる時間を測定します。たとえば、チェックアウトを通過します。そうそう。そのような幅広い指標があるので、あなたはただ焦点を合わせているだけでなく、今四半期に何件の売上を上げましたか？あなたは全体像を見なければなりません。

Drew： 4月、私はBetterBlockerのLauraKalbagとオンラインプライバシーについて話しました。私たちは、パブリックと見なされるものとプライベートと見なされるものとの間の絶え間なく薄くなっている境界について話しました。これがローラです。

Laura Kalbag：数年前に私に起こったこの典型的な例があります。それで私はFacebookを利用していて、母が亡くなったばかりで、葬儀屋の広告を受け取っていました。その時点で私の家族の誰もソーシャルメディアプラットフォームで何も言っていなかったので、それは本当に奇妙だと思いました。私の家族は誰もFacebookで何も言っていませんでした。なぜなら、Facebookを介して友人や家族についてそのようなことを誰も知りたくないということに同意したからです。だから私たちはそれについては言いませんでした。

Laura Kalbag：それで、私は兄弟に「ああ、これを奇妙にするかもしれない何かをFacebookで言ったことはありますか」と尋ねました。なぜなら、私は通常、化粧やドレス、妊娠検査、そして彼らが話したい楽しいことすべての広告を受け取るだけだからです。ある年齢の女性です。代わりに、私の妹は私に戻ってきました。彼女は言いました｢ええ私の友人はオーストラリアに住んでいます。」そこで私は彼女にFacebookMessengerでメッセージを送り、私たちのお母さんが亡くなったことを伝えました。もちろん、Facebookは私たちが姉妹であることを知っていました。それはあなたがそこに追加することを選択できるその関係のつながりを持っています。つまり、私たちが一緒にいた場所から、私たちが姉妹であると推測できるかもしれません。私たちが名前を共有し、「ああ、それは彼女の足に入れるのに適切な広告だ」と決めたという事実です。

ドリュー：テクノロジーが私たちのためにこれらの決定を下していると考えるのは冷静ですよね、それは実際にこの例では非常に敏感または脆弱な時間に潜在的に人々に影響を与えますか？

ローラ・カルバグ：うん。不気味だと言います。多くの場合、「ああ、それは私の電話のマイクやラップトップが私を聞いていたようなものです。私はこの特定の製品についてこの会話をしているだけで、突然それが私のフィードのいたるところに現れました。」実際に怖いのは、彼らのほとんどがあなたのマイクにアクセスできないという事実だと思います。しかし、それはあなたの他の行動、あなたの検索、あなたがお互いに近く、あなたのデバイス上のあなたの場所のためにあなたが誰と話しているのかを知っているという事実です。「ああ、彼らはおそらくすでにそれについて考えていたので、おそらく彼らはこの製品に興味があるだろう」と言うために、私たちが一緒に接続できないかもしれないすべてのものを接続することができます。

ドリュー：コロナウイルスのパンデミックが発生し、多くの国が何らかの形で封鎖されたとき、私はレイチェル・アンドリューと、スマッシングが代わりにオンラインで開催される予定の対面会議をどのように適応させているかについて話しました。サンフランシスコでのSmashing会議を延期しなければならなかったので、私はRachelに、今後の会議やワークショップを仮想ドメインに移行するための計画を尋ねました。

Rachel An Drew：非常に迅速に、サンフランシスコを延期する必要があることに気づいたら、明らかに、私とVitalyの両方がスマッシュとコンプでワークショップを開催し、サンフランシスコで完売しました。私たちのワークショップ。もちろん、私たちのためにワークショップに来て運営している人もたくさんいますし、私たちが長い間一緒に働いてきた人たちも、彼らのすべてのワークショップを見つけていました。私たちの収入の重要な部分。

レイチェル・アン・ドリュー：人前で話すと、一般的に人前で話すことで多くのお金を稼ぐことはありません。講演などを書くのにかかる時間を考えると、ほとんどの人はあまりお金を払っていません。ワークショップは、このようなものを教えるのが得意な人がお金を稼ぐのに非常に良い方法になる傾向があります。つまり、彼らは人々の収入を表しています。だから私自身が必要だっただけでなく、Vitalyは今年初めに私たちのワークショップを失いました。また、Smashingスピーカーの多くもこれらのワークショップに依存していることに気づきました。

レイチェル・アン・ドリュー：それで、私たちは「では、なぜそれらをオンラインにしてみませんか？」と考えました。非常に、非常に迅速に、実際にそれが起こってから数日以内に、私とVitalyが最初に権力に頭を突っ込むことになると決めましたが、それが私たちであることを考えると、それを行う方法を理解することができました。また、非常に異なるワークショップがあります。 Vitalyは、はるかに多くの種類のコラボレーションです。彼はグループ活動や物事を持っています。私は教室スタイルを教えています。それで、私たちの間で、「まあ、私たちはすべての拠点をカバーしているようなものだ」と思いました。だから私たちはこう思いました。それが機能するかどうか見てみましょう。」だから私たちはそれらを宣伝します。それぞれにどれくらいの時間がかかったかを把握した後、座ってこう言いました。「では、オンラインワークショップは実際にはどのようになっているのでしょうか。これは何ですか？"

Drew：技術的な観点から、すぐに考えるWeb開発者として、いったいどうやってそのようなものを提供するのだろうと思います。つまり、あなたが見たさまざまなプラットフォームがたくさんあるに違いありません。あなたが見たさまざまなものと、Smashingが最終的にもたらすものは何でしたか？

レイチェル・アン・ドリュー：それで、私たちはいろいろなことを見てきました、そして私たちはまだそれをしているようなものです。現在、ズームを使用しています。 Zoomを使用している理由は、アクセシビリティです。それはプラットフォームの中で最もアクセスしやすいものでした。明らかに、私たちが選択したプラットフォームのために、人々を排除したくありません。他のプラットフォームは良くなっていると思いますし、人々は…多くのプラットフォームが人々を彼らのところに来て、こう言ったと思います。しかし、私たちはあなたがアクセス可能である必要があります。」そのため、現時点ではズームが最も使いやすいです。」だから私たちはそれらを使うことになったのです。永遠にやるかどうかはわかりません。しかし、それは私たちが現在使用しているものであり、このようなことを行う方法としてはかなりうまく機能しています。

ドリュー：ズームの疲労が始まり、世界がすぐに新しい正常と呼ばれるものに順応し始めたとき、私はテクノロジーがCOVID-19のような状況に対応するのにどのように役立つかについてPhilSmithに話しました。 React Nativeアプリ、CardMedicをわずか10日で構築します。私はPhilに、仕事に最適なテクノロジーを選ぶことと、彼が精通していて迅速に作業できるテクノロジーとのバランスを取る方法について尋ねました。

Phil Smith：それは良い質問です。プロジェクトが私に言われるとすぐに、私はこれらすべてをどのように構築するのかを正確に知っていると思いました。子供がいなくて暗い部屋に座っていたら、要件が非常に多かったので、しっかりと、しっかりと、しっかりと取り組んでいれば、おそらく5日ほどですべてを好転させることができたと思います。私のアプリ構築の経験と一致しています。私は同様の種類のものを構築しました。APIを呼び出し、結果を状態に保存して表示します。私は今、「さて、戻ってリファクタリングする必要があります」と思うような状況になっています。

Phil Smith：スズの入力について話しましたが、実際にはアプリ内で入力がかなり緩い可能性があるため、それを厳しくする必要があります。バックエンドでは、テストはそれほど多くありませんが、多くの人が前に出て、「実際、これは素晴らしいリソースです。これを母国語に翻訳するために、ボランティアでサービスを提供したいと思います。」バックエンドはより多くの人に使用されているので、「ちょっと待ってください。現在本番環境で使用している人がいるので、何も壊れないことを確認するために、ここでさらにいくつかのテストが必要です」と考えています。私はあなたの質問に答えたと思います。基本的に、意思決定はありませんでした。私はそれをできるだけ早くそこに出さなければなりませんでした。

ドリュー：職場が閉鎖され、私たちの多くが自宅での作業に適応したため、自宅のワークスペースを快適で生産的な場所に最適化しても、長期的な身体的健康問題が発生しないことについてベン・フレインに話しました。家でセットアップするために利用できる限られた予算で、私はベンに良い椅子が始めるのに最適な場所であるかどうか尋ねました。

ベン・フレイン：それが私のアドバイスです。うん。つまり、私はこれらのことの権威であると公言することはできませんが、それはおそらくあなたが一日中快適にするためにあなたができる唯一の最も重要なことのようです。あなたはかなり高価なものから始めることができます。私も同じ過ちを犯し、Amazonから45ポンドのオフィスチェアを手に入れました。そのための正しい言葉が何であれ、軸上に前傾がないことに気づきませんでした。だから私が見つけたのは、太ももの裏側、ひざの後ろのようなものを掘り下げていて、「45分座った後、なぜ足が死んでしまうのか」と考えていました。

ベン・フレイン：特にあなたがまともなオフィスチェアを提供する会社で働いているなら、あなたはそれらを当然のことと思っています、そしてあなたが行くのはその特定のメーカーとブランドを見るまではありません。 700ドルの椅子。」そのクリキーに気づいたとき、人々はこれについて考え、あなたのためにたくさんのことをしました、そしてあなたは明らかにあなたの家の環境に来て、あなたは「椅子にX百ドルを費やしてみませんか？」と思います。しかし、多分それは価値があります。特にあなたが長い間ここにいるなら。

ドリュー：そして、長距離は私たちが得たものです。長い間存在している他の何かはDrupalです。 6月に、私はDrupal 9の変更についてAngieByronと話をしました。最初のリリースから20年、Drupalは長い道のりを歩んできました。 Drupal 9に移行するとき、既存のDrupalサイトをアップグレードするプロセスはどのようなものであり、長期的なサイトを持つユーザーにとって大きな負担になる可能性があるかどうかをAngieに尋ねました。

アンジェラ・バイロン：基本的に3つのシナリオがあると思います。つまり、Drupal 8を実行していて、Drupal 8の新しいマイナーリリースがリリースされるたびに、すぐにアップグレードして、新しいものを利用し始めた場合です。あなたの道は基本的に何もないでしょう。あなたはすでにすべての仕事をしていて、元気です。しばらく前にDrupal8に移行し、BCの変更に追いついていない場合は、少し作業が必要です。

Angie Byron：とにかく、これは10年以上のソフトウェアの中で間違いなく最も簡単なアップグレードであり、それを支援するさまざまなツールがたくさんあります。提供されたすべてのモジュールと、それらのDrupal9の状況を示すダッシュボードがあります。コードを調べてチェックし、廃止された関数にフラグを立てるための自動化されたツールがあります。また、自動的に起動して次のように見つけるためのツールがあります。「これはモジュールの最新バージョンであり、Drupal 9の準備はできていますか？あなたはそれをダウンロードしに行くべきです」とそのようなもの。

アンジェラ・バイロン： Drupal 8から9まで、その部分はかなりカバーされていると思います。 Drupalの以前のバージョン、たとえばDrupal7以下からDrupal9を使用している場合は、少し注意が必要です。 Drupal 8で行った変更の中で、たとえば、完全にオブジェクト指向のPHPに移行し、他のソフトウェアプロジェクトで見つかったデザインパターンを利用し始めました。これは、アーキテクチャ上は非常に賢明なことですが、つまり、昔の生活で大量のカスタムコードがあった場合、Drupal 9では、その代替コードを見つける必要があります。

Angie Byron：つまり、AcquiaはAcquia Migration Acceleratorと呼ばれる製品と開発であり、その問題を解決することを目的としています。ここでは、古いDrupal 7データを読み取り、同等のDrupal8データを作成するReact定義の優れたアプリケーションを作成しています。必要になるすべてのモジュールとともに、可能な場合は古いDrupal 7モジュールにマップして、そのプロセスをかなり迅速化してみてください。古いバージョンを使用しているすべての人が引き続きそれを実行できるようにするためです。新しい世界秩序。全員が同じバージョンを使用しており、私たち全員が協力しています。

Angie Byron：さらに、Drupal 7も拡張しました…Drupalのオープンソースコミュニティであり、来年の11月の時点でDrupal7でのサポートが終了します。現在、とにかく、COVIDがそれに影響を与えるかどうかを議論する必要があります。しかし、さまざまな企業があり、Acquiaは、少なくとも2024年までDrupal7の拡張サポートを提供している企業の1つです。そのため、アップグレードが簡単な人は1年半、アップグレードは簡単ではなく、必要に応じて3年半以上かかる可能性があります。そして私たちは、誰もが移動できるように真剣に取り組んでおり、AcquiaMigrateAcceleratorなどのツールを構築してプロセスをスピードアップしています。

Drew： Learning Reactは、MinaMarkhamとの会話の主題でした。ミナと私はどちらも初めてReactを学ぶ立場にありました。 Reactのようなフレームワークがブラウザにどれほどの負担をかけているのかを振り返り、クライアントの手にこれほど多くの制御を与えるのは間違いではないかとミナに尋ねました。

ミナ・マーカム：繰り返しになりますが、私の経験はほとんど静的なWebサイトに非常に多く含まれています。製品開発はあまりしていません。したがって、おそらくその領域では、これはより理にかなっています。しかし、私の観点からは、バターナイフが必要なときに手斧を使用することが多いように感じます。なぜこれをすべてブラウザに入れて、多くのことができるようになると、クライアントに多大な労力とプレッシャーをかける必要があるのかわかりません…これはもっと簡単にできると思います。いつもReactを使うのを少し躊躇していたことの1つ、または私は躊躇していると言いますが、それが私を内臓的に怒らせ、積極的に反対したときの意味は、Webサイトにアクセスするときであり、文字通り何もレンダリングされませんでした。 1つのエラーが発生したか、1つの関数が機能しなくなったために、実際にはページ全体が壊れたようなものがありました。

ミナ・マーカム：多くの場合、それはオールオアナッシングのアプローチだったので、ちょっとイライラしました。過去や過去にAEAで行った講演の1つは、プログレッシブエンハンスメントだけでなく、アートディレクションやサイトのデザインの拡大も含める方法について話していました。プログレッシブエンハンスメントやあらゆる種類の優雅な劣化を行わなかったWebサイトの例を具体的に指摘します。ブラウザでJavaScriptを実行しているか、まったく何も得られないかのどちらかでした。実際に話題になっているサイトのひとつである、1990年頃から現在までのウェブデザインの歴史を紹介するシンプルなサイトになります。それはたくさんのタイムライン、物事のアニメーションを備えた美しいウェブサイトでした。ただし、リストだけで静的にレンダリングすることもできます。何も表示しないことと、現在のWeb開発に取り組んできた方法のために失われたと思う、美しく強化されたエクスペリエンスを表示することの間には、いくつかのステップがありました。

Drew： BEM、SMACSS、OOCSSのようなスタイリング方法であるCUBECSSについてAndyBellに話しました。多くのCSSアプローチは、カスケードのようなCSSの自然な特性に逆らって機能しようとします。 CUBEはその振る舞いを非常に受け入れています。アンディです。

Andy Bell： SassのようなSCSSは、自然なCSS言語の拡張ですよね。あなたはまだCSSでかなり正しいです。つまり、CUBECSSはそのようなものです。つまり、CSSの拡張です。したがって、CSSを作成する必要があります。CSSを作成する必要があります…まあ、それは作成されるはずです。正直に言って、それがどのように書かれるべきかということです。名前はそれを与えます、カスケードスタイルシート。ですから、私が見つけたのは、マイクロ最適化レベルまでずっと下がったということです。私は最近多くの人が下がっているのを見る道を進んできました…私はこれについても記事で言及しました、そこで私は見ることができます…最近それのいくつかの証拠があります。私は人々がスペーサーコンポーネントやそのようなものを作成しているのを見つけました、そして私はその問題を理解しています。私はそのような状況にありました。

Andy Bell：私が修正した方法は、ドリルダウンしてマイクロ最適化を試みるのではなく、コンポーネントがどれほど小さいかは問題ではないため、実際には構成レベルで物事を考え始めました。ある時点で、それらはページになります。それらはビューになります。それは避けられません。それがそうなるでしょう。つまり、「そうです、このレイアウトを行うには、これらの小さなヘルパーが必要です」と言う代わりに、「そうです、連絡先ページビューまたは製品ページビューがあります。これは、骨格のレイアウト構成です。次に、その中に、必要なコンポーネントをスロットに入れることができます。」

Andy Bell： GridやFlexboxのようなものがあり、これをはるかに実現可能にしています。基本的に、必要なものを骨格レイアウト内に配置できます。関係ありません。次に、コンポーネントは、その時点で、コンテナクエリの有無にかかわらず、コンポーネントが希望どおりに動作する必要があります。

ドリュー：ギャツビーはマーシーサットンとの私のチャットの主題でした。ほとんどの静的サイトジェネレーターはフロントエンドコードに依存しませんが、GatsbyはReactを使用するため、最終的なWebエクスペリエンスの一部としてGatsbyコードが実行されることになります。私はマーシーにそのコードとは何か、そしてそれが提供している機能は何かを尋ねました。

マーシー・サットン：はい。その最大の部分はクライアント側のルーティングだと思います。そのため、ギャツビーは現在、内部でリトリーダーを使用しています。それは一種の独自の実装です。しかし、それは静的サイトを初めてロードするときにHTMLファイルがそこにあるという部分です。したがって、ユーザーが何らかの理由でJavaScriptをオフにしても、サイトは引き続き存在し、コンテンツを保持しているはずです。ただし、JavaScriptが有効になっている場合は、このハイドレーションステップが発生し、Gatsbyサイトでリンクを使用すると、そのページからリソースがプリフェッチされます。したがって、ロードが速くなります。つまり、Gatsbyが提供するこのJavaScriptレイヤーですべてが有効になります。

Marcy Sutton：それを超えて、それはあなたがあなたのサイトで何を使っているか、そのJavaScriptバンドルに何が含まれるかによって本当に異なります。しかし、アクセス可能なインターフェースのように、多くの双方向性を使用するものにとっては、それは良い場所です。私にとって、JavaScriptをいつでも利用できるようにし、マークアップを適切な場所に配置することを本当に楽しんでいます。 HTML、JavaScript、CSSをすべて適切に結合し、Gatsbyの構築にはバリエーションの余地があるかどうかは、好みの問題だと思います。 CSSやJSのようなものを常に使用する必要はありません。しかし、それは本当にあなたがあなたのウェブサイトを書いている間にあなたがその動的なJavaScriptレイヤーの力を利用できるようにすることです。別のファイルにあるこのアドオンとは異なります。

Drew：静的サイトジェネレーターが通常どのように機能するかを考えるとき、おそらくマークダウンファイルのコンテンツを考えています。ジェネレーターはそのコンテンツを実行し、テンプレートとマージして、数十、数百、数千のHTMLファイルを作成します。あなたのウェブサイトのページ。 Reactのサイトやアプリについて考えるとき、インターフェイスがReact on theflyによって作成されるシングルページエクスペリエンスについてもっと考えています。だからあなたはギャツビーがそれらの両方をしていると言っているのですか？すべてのページを作成し、JavaScriptで拡張していますか？

マーシー・サットン：そうです。 Gatsbyはビルド時にNode.jsを使用し、Reactコンポーネントを調べてHTMLファイルにコンパイルします。正直なところ、Gatsbyを初めて見たときは、JavaScriptをオフにせず、「わかりました。ここに他のページはありますか？これは何ですか？" Gatsbyがデフォルトでそのように機能するのはとてもうれしかったです。それはあなたのReactコンポーネントからビルドされたファイルを作成します、それは素晴らしいです。

Marcy Sutton： JavaScriptを使用しているので、よりプログレッシブエンハンスメントのアプローチを検討しました。たとえば、ユーザー向けにプログレッシブエンハンスメントを出力したい場合、JavaScriptをオフにしている場合、JavaScriptを想定したこの壊れたコードをすべて望まない場合はどうでしょうか。ある。ですから、それにはいくつかの癖があります。しかし、少なくとも、誰かがまだ何かを購入できるようにしたいコアユーザーフローでは、そのようなことを回避できます。いくつかのサポートを追加する必要があるかもしれませんし、それらのユースケースのために。しかし、ギャツビーがデフォルトでそれを展開する方法に私はうれしく驚きました。

マーシー・サットン：それで、彼らがそのようにサイトを構築することを選択しました、そして私たちは常に評価しています、それはまだ最良の方法ですか？ユーザーが求めているものをユーザーに提供するには、何をする必要がありますか？そのため、Gatsbyがウェブサイトの構築で可能な限り最高の仕事をしていることを確認するために、社内でいくつかの調査を行っています。バンドルサイズを小さく保ち、私たちが言うことのトレードオフを行うために、preとのパフォーマンスの高いコードであることを確認します。 -フェッチ、それをバックアップするためのデータはありますか？それは私が非常に興味を持っている開発者の擁護者としての種類のことであり、私たちがウェブサイトにパッケージ化してバンドルしているものが実際に必要であり、それが作ることができる最高のギャツビーサイトを本当に作ることを確認しています。

ドリュー： 7月にクリスフェルディナンディと話をして、現代のベストプラクティスがウェブに悪いのかどうか尋ねました。クリスはリーンウェブとして知られる運動を支持し、私は彼にそれが何を伴うのか尋ねました。クリスです。

Chris Ferdinandi: When I look at the way we build for the web today, it feels a little bit like a bloated over-engineered mess. 今日のベストプラクティスとして私たちが考えていることの多くは、実際にはWebを悪化させているのではないかと私は信じるようになりました。 The Lean Web is an approach to web development that is focused on simplicity, on performance, and the developer experience over… I'm sorry, not the developer experience, the user experience rather, over the developer experience and the ease of building things from a team perspective, which is what I think where we put a lot of focus today.

Chris Ferdinandi: As we'll probably get into in our conversation, I've actually come to find that a lot of these things we think of as improving the developer experience do so for a subset of developers but not necessarily everybody who's working on the thing you're building. So there's a whole bunch of kind of issues with that too that we can kind of dig into. しかし実際には、リーンWebは、ユーザーのシンプルさとパフォーマンスに焦点を当て、私たちではなく、私たちが作ったものを使用する人々、つまりそれを作っている人々に本当に優先順位を付けるか、焦点を当てることです。

Drew: In August, Chris Coyier joined us to talk about all things serverless. I asked him what sort of the tasks they were putting serverless to over at CodePen?

Chris Coyier: Well, there's a whole bunch of things. One of them is, I think, hopefully fairly obvious is, I need… The point of CodePen is that you write each HTML, CSS, and JavaScript in the browser, and it renders it in front of you, right? ただし、プリプロセッサ言語を選択することもできます。あなたがSassが好きだとしましょう。 CSSでSassをオンにして、Sassを記述します。さて、何かがSassを処理する必要があります。最近、SassはDartか何かで書かれています。 Theoretically, you could do that in the client. しかし、前処理を行うこれらのライブラリはかなり大きいです。 Sassライブラリ全体をあなたに出荷したいとは思いません。ただそれを実行するためです。したくない。 That's not the right architecture for this necessarily. Maybe it is down the road. I mean, we could talk about offline crap, yada, yada, web workers.

Chris Coyier: There's a million architectural things we could do. しかし、これが現在どのように機能するかです。ラムダがあります。 Sassを処理します。それには、小さな、小さな、小さな、小さな仕事が1つあります。 You send it this blob of Sass, and it sends you stuff back, which is the processed CSS, maybe a site map, whatever. It has one tiny little job, and we probably pay for that lambda like four cents or something. Because lambdas are just incredibly cheap, and you can hammer it too. 規模を気にする必要はありません。 You just hit that thing as much as you want, and your bill will be astonishingly cheap.

Chris Coyier: There is moments where serverless starts to cross that line of being too expensive. それが何なのかわかりません。 I'm not that master of stuff like that. But generally, any serverless stuff we do, we basically all nearly count as free, because it's that cheap. しかし、Sass用のものがあります。少ないものがあります。バベル用のものがあります。 TypeScript用のものがあります。 1つあります…これらはすべて、実行する個々のラムダです。 Here's some code, give it to the lambda. It comes back, and we do whatever we're going to do with it. しかし、最近でも、それ以上の目的で使用しています。

Chris Coyier: Here's an example. CodePenのすべてのペンにはスクリーンショットがあります。かっこいいですよね？ So the people make a thing, and then we need a PNG or a JPEG, or something of it, so that we can… that way when you tweet it, you get the little preview of it. Slackで共有すると、プレビューが表示されます。 We use it on the website itself to render… Instead of an iframe, if we could detect that the Pen isn't animated, because an iframe's image is much lighter, so why not use the image? とにかくアニメーション化されていません。そのようにパフォーマンスが向上するだけです。

Chris Coyier: So each of those screenshots has a URL to it, obviously. We've architected it so that that URL is actually a serverless function. それは労働者です。 So if that URL gets hit, we can really quickly check if we've already taken that screenshot or not. That's actually enabled by CloudFlare Workers, because CloudFlare Workers are not just a serverless function, but they have a data store too. They have this thing called key-value store. So the ID of that, we can just check really quick, and it'll be, “True or false, do you have it or not?”

Chris Coyier: If it's got it, it serves it, and it serves it over CloudFlare, which is super fast to begin with and then gives you all this ability too because it's an image CDN, you can say, “Well, serve it in the optimal format. これらの次元としてそれを提供してください。」それらの寸法で画像を作成する必要はありません。 You just put the dimensions in the URL, and it comes back as that size, magically.

Drew: I talked to Next.js co-creator, Guillermo Rauch about the features on offer in Next.js and asked about its automated code splitting functionality. As the size of our JavaScript bundles can have quite an impact on performance, I was interested to know if Next had ways to tackle that. Here's Guillermo.

Guillermo Rauch: Yeah. Your observation is 100% right. So one of the biggest things with the web and one of the biggest weights on the web is JavaScript. Just like different materials have different densities and weights, irrespective of the actual physical volume, JavaScript tends to be a very dense, heavy element. Even small amounts of JavaScript compared to, for example, images that can be processed asynchronously and off the main thread, JavaScript tends to be particularly bothersome.

Guillermo Rauch: So Next.js has invested a tremendous amount of effort into automatically optimizing your bundles. So the first one that was my first intuition when I first sort of came up with the idea for Next.js was, okay, you're going to define, for example, 10 routes. In the Next.js world you create a pages directory, and you drop your files in there, index.js, about.js, settings.js, dashboard.js, terms-of-service.js, signup.js, login.js. これらは、あらゆる種類のメディアを通じて共有できるアプリケーションへのエントリポイントになります。

Guillermo Rauch: When you enter those, we want to give you JS that is relevant for that page, first and foremost, and then perhaps a common bundle so that subsequent navigations within the system are very snappy. Next.jsも非常に優れており、そのエントリポイントに接続されている残りのページを自動的にプリフェッチするため、単一ページのアプリケーションのように感じられます。 So a lot of people say like, “Why not just use Create React app if I know that I have maybe a couple routes?” I always tell them, “Well, look. You can define those as pages, and because Next.js will automatically pre-fetch ones that are connected, you end up getting your single-page application, but it's better optimized with regards to that initial paint, that initial entry point.”

Drew: In September, I had the pleasure of talking to Cassie Evans about SVG animation. We talked about the approachability of SVG for developers who are already familiar with HTML. Here's Cassie.

Cassie Evans: I think that that's what I love the most about SVG is I'm really into creative coding and also teaching people, and I found that teaching people who are more of a creative leaning, they sometimes get a little thrown off when you immediately jump in with JavaScript or Python or something like that for creative coding. But without fail, I've managed to get anyone that I taught on board with SVG because there some really approachable entry points because it does look like HTML.

Cassie Evans: So you can give someone with an understanding of HTML and how to build websites SVG, and it looks the same, but it's the graphics instead of documents, and then you can animate that with CSS to start off with, which is also a little bit more comfortable, and then you can kind of progress to animating it with JavaScript. So it's a really good learning curve.

Drew: Of course, it can be dynamic. It's not just a case of creating motion. You can actually make the properties of it dynamic. So one of the interesting things I've seen SVG used for, and it's a grand term, but data visualization, dataviz, and drawing graphs and charts and of course things like dashboards that we seem to have everywhere these days. SVG is sort of perfect for that, isn't it?

Cassie Evans: Yes, definitely. SVG is great for dataviz. All the way from kind of small dataviz up to D3 which is very well known dataviz library that uses SVG under the hood. But you could also just, if you've got a little bit of data that you wanted to show on a web page, you could create a chart in a graphics editing program, and then you could just use JavaScript to change those values and kind of change how your graph looks. So you don't have to go all in with a massive database library. You can kind of just start off small.

Drew: The Jamstack framework, RedwoodJS was the topic of conversation with Anthony Campolo. I asked Anthony what it meant to be a full-stack Jamstack framework in practical terms.

Anthony Campolo: Yeah, it's pushing the boundaries of what a Jamstack application can be. So by calling it full-stack Jamstack, it's about, how do we go beyond just the front end to having the same sort of deployment paradigm of just get pushed, getting your whole code deployed? How do we get that but also with our back end and have it all connected?

Drew: Vue.js version three was released in October, and I caught up with Natalia Tepluhina from the Vue core team. Discussing the new version, I was curious if the major version bump was just a result of a few backward incompatible modifications or if this was a very clear revisiting of Vue to make deeper changes to the framework.

Natalia Tepluhina: No. I think it was an idea to create a new version due to a few very important things. ですから、まず、反応性を変える動機がありました。 Previous one was built upon Object.defineProperty, and it had a few caveats. They're all documented, but still, even if you document something that people shouldn't do, they will do it anyway, and you would need to point them to the documentation. Nobody reads documentation, by the way. For some reason, it just happens. Until you point people out, it doesn't exist in docs, it does. でも大丈夫。とにかく教えます。

Natalia Tepluhina: So reactivity was one of the things. Performance was the next. Vue 2 still had and has not the worst performance, but we had a few ideas about how to make Vue faster, and also, there was one pain point for a particular part of our, let's say audience, people that use Vue. それはTypeScriptでした。 Vue 2 internally was written in Flow, which is still strongly typed one, but typing with TypeScript were a real nightmare especially if you were working with our state management Vuex.

ナタリア・テプルヒナ：それで、これもまた大きな部分でした。最後の1つは、コンポーネントではなく、関数ヘルパーなどの構成可能なロジックパーツの観点から、ロジックを抽象化する機能を見逃したことですが、Vueアクティビティも含めることができるはずです。ここでの良い例はReactHooksですよね？それらはあなたが機能の一部を抽象化することを可能にします、そしてこれは明らかにVueに欠けていました。今のところ、「Reactから機能を盗んだ」ように聞こえます。実際にはありません。アイデアの相互受粉は私たちのエコシステムにおいて大きくて素晴らしい部分であり、開発者がお気に入りを切り替えるのにも役立つと思いますよね？そこで、これらの主な機能に取り組んで、メジャーバージョンとしてVue3を作成しました。

Drew：続いて、Stefan Baumgartnerと一緒にTypeScriptに飛び込み、バグを減らしてより良いコードを書くのにどのように役立つかを調べました。組織がコードベースを完全にJavaScriptに移行する傾向を観察し、TypeScriptは、個人よりも大きなチームが恩恵を受けるものであるかどうかをStefanに尋ねました。

ステファン・バウムガルトナー：それで私は現在同じ移行期にあります。そのため、将来的に多くのJavaScriptを作成する予定のJavaおよびC++開発者がたくさんいます。 TypeScriptは、新しいプログラミング言語のこれらの恐ろしい領域のためのある種のガイドになる可能性があります。 JavaScriptには、多くの癖、多くの歴史、そして異なるプログラミング言語から来た場合の多くの偏見があります。したがって、型システムにはよく知っている概念がいくつかあるので、TypeScriptはガイドになることができます。

Stefan Baumgartner：しかし、特に、同じコードベースで作業する人がたくさんいる場合や、お互いに作業する必要がある人がたくさんいる場合は、これがプロジェクトのガイダンスの追加レイヤーになる可能性があります。結局、悪い驚きはありません。もちろん、テクノロジーは通信の問題を解決しません。これはTypeScriptが意図しているものではありません。しかし、それは低くなる可能性があります、またはそれはあなたが話す必要がない場合、あなたはあなたのコードで私に何を期待しますか、むしろあなたのコードは何をすべきか、またはあなたの図書館はしますか？

Stefan Baumgartner：他の人のためにコードを書いたり、たくさんの人と一緒にコードを書いたり、自分でコードを書いたりする場合は、翌日再訪する必要があります。TypeScriptを検討してください。ロングラン。これは、来週の次のプロジェクトへの投資だけでなく、特に1か月、2年、または数年の長期にわたるプロジェクトがある場合は、間違いなくそれを提供すると言う人にとってはより多くの投資です。 1年前に小さなコードを書いたときに何を考えていたのかを知ることは決してありませんが、型はあなたが何を意味していたかについてのヒントを与えることができます。

Drew： 11月に、静的サイトジェネレーターであるEleventyについてDavidDarnesとチャットしました。テンプレートについて話しました。また、どのタイプのテンプレートを使用する必要があるかについて、静的サイトジェネレーターの数について非常に多くの意見が寄せられています。 11は同じような強い信念を持っているのだろうかと思いました。これがデイブです。

デビッド・ダーンズ：いいえ、私はそれがあなたが得ることができるのと同じくらい非ピニオンに近いと言わなければなりません。少し個人的な見方ですが、何かを作成するには、何かをどのようにやりたいかについて意見を持っている必要があるため、フレームワークや、ピニオンを外すことができるものを見つけるのに苦労しました。それは一種の撞着語です。きっと人々は私を訂正してくれるでしょう。しかし、ええ。最も使いやすいテンプレート言語に切り替えることができます。つまり、私たちはあなたが快適な言語について話していました。 11は、ある意味で、テンプレート言語がHTML内で使用するもの、または必要に応じてCSSでさえも使用するものでそれをアピールします。

David Darnes：私にとっては、nunjucksがEleventy内のデフォルトのテンプレート言語であるため、nunjucksに直接アクセスしました。つまり、ドットHTML拡張機能を使用して、そのままにしておくことができます。さて、私は人々をさらに混乱させて、「とにかく好きなように名前を付けることができます。あなたはそれを本当に楽しむことができます。」ただし、ハンドルバーは使用できます。通常のJavaScriptテンプレートを使用して、そのように繰り返すことができると思います。非常に人気のあるハンドルバーとリキッドも同様です。それらすべてを頭から離れて考えることはできませんが、すべてを構成に設定すれば、好きなように選択できます。

David Darnes：私は一般的なテンプレート言語の大ファンだと思います。 WordPressの内部で小枝を使用できることを知ったのはそれほど昔のことではなく、そのようなことは私の心を吹き飛ばしました。私は「ああ、ありがとう。 PHP内でforループを処理する必要はありません。」繰り返しになりますが、もう少し快適で理解しやすく、読みやすいものだと思います。そうそう。 11にはさまざまなテンプレートオプションがあり、それらのさまざまなオプションに慣れている人にアピールする必要があります。

Drew： Netlifyが独自のプラットフォームを使用してNetlifyを構築する方法と、DeployPreview機能がフロントエンドの変更に効果的なステージングプラットフォームになる方法についてLeslieCohn-Weinと話をしました。

Leslie Cohn-Wein：おそらく、そのプロセス全体の中で私のお気に入りの部分は、Netlifyを介して取得するDeployPreviewsの魔法です。つまり、GitHubで作業している場合は、PRを押し上げます。したがって、GitHubでPRを開くと、アプリのデプロイプレビューのビルドが自動的に作成されます。そのため、実際にはアプリ自体のデプロイプレビューを使用してテストし、すべてが正常に機能していることを確認します。テストを実行します。これは、コードレビュー中に手動で検証するために使用するものです。そのため、GitHubから直接セットアップされた継続的デプロイのようなものがあります。

Leslie Cohn-Wein：それから、私たちが設定した他のクールなことの1つは、アプリが存在する同じリポジトリからプルしている2つの異なるNetlifyサイトが実際にあることです。つまり、両方のアプリがあります。アプリのUIコンポーネントのようなものを含むStorybookのインスタンスがあります。つまり、両方のアプリ自体があります。 Storybook UIコンポーネントがあり、基本的にStorybook UIを表示するNetlifyサイトがあり、次にWebpackバンドルアナライザーを実行する3番目のサイトもあります。つまり、これは、すべてのアプリバンドルのツリーマップ視覚化を提供する一種のビジュアルUIであり、それらのサイズをある程度測定することができます。アプリのデプロイが進むたびに、一種の再確認を行うことを忘れないでください。そこにあるバンドルサイズで何か変なことをしていないことを確認できます。

Leslie Cohn-Wein：つまり、これら3つのサイトはすべて、アプリの1回のプルリクエストで生成されます。そのため、アプリストーリーブックとそのアプリプロファイルの両方のプレビュー、基本的にはデプロイプレビューへのリンクが表示され、確認することができます。

ドリュー： 12月に、私はクリス・マーフィーと製品設計について、そしてビジネスが焦点を絞って設計されることの意味について話しました。個々の創設者が焦点を合わせて設計するのか、それがビジネスに漏れるのか、そして製品が当然それを作成した人の延長であるのかどうかについて話し合いました。

クリス・マーフィー：それは本当に良い質問だと思います、ドリュー、そしてそれに対する答えはそれによると思います。それはその人にも、会社の規模にもよると思います。 Hiut Denimを見てみると、私はHiutをよく教えていますが、これは1つのことをうまくやっている会社の非常に良い例であり、それは一種のストラップラインジーンズです。デビッドの前の…デビッドとクレアを見ると、彼らはパートナーシップだからだと思います。デビッド・イーイットとクレア・イーイットの前の会社であるハウイーズを見ると、その会社は非常に大きく成長しており、非常に多くの人々が関わっていました。

クリス・マーフィー：スケールが忍び寄り始めると、カスタマージャーニーで重要なすべての小さなタッチポイントを監視することが非常に難しくなり始めます。彼らがハウイーズを去ったとき、ハウイーズはによって買収されていたので、それは本当に言っていると思います…それは複雑です。インターネットで読んでください。しかし、それはティンバーランドであり、ティンバーランドが購入されました、そしてこのすべての話があります。

クリス・マーフィー：彼らが今注目しているのがジーンズだというのは本当に面白いと思います。それでおしまい。彼らはジーンズの周りに驚くほど良い話をしています。彼らはまた、すべてを本当に、本当にうまくパッケージ化していて、ジーンズは本当に物語の乗り物のようなものです。これは私が思うに、ドリュー、私たちがCOVIDのもう一方の端から出てくるにつれて、より重要になるだろうと思います。私たちはもう一方の端から出てくることを願っています。それらのジーンズを作っている人は皆、適切な賃金を支払われています。私が世界を見た瞬間に私が抱えている問題の1つは、すべての人に適切な賃金が支払われているわけではないことです。誰かとして、私は51歳です。息子は25、24歳です。、25、そのようなもの。それはひどいです。私はこれらすべてを知っている必要があります。彼は結婚式の写真家です。彼は1年ほどの間結婚式の写真家でした。彼のビジネスは完全に衰退しています。なぜなら、それはただ難しいので、その瞬間に誰も実際に結婚していないからです。彼はサポートを受けるのに十分な自営業の本を持っていなかったので、彼には給料がありません。

クリス・マーフィー：彼はひび割れに陥っています、そして他にもたくさんの人がひび割れに陥っています。それは設計上の問題であり、私たちはそれを設計上の問題と見なす必要があると私は主張します。しかし、COVIDと政府のより広い問題と、これらすべてを政治的になりすぎずに見ると、昨日ガーディアンでマット・ハンコックの隣人についての記事を読みました。保健大臣。事業を営んでいた彼の隣人は、彼にテキストメッセージを送り、「このCOVIDのものに製品を供給するにはどうすればよいか」についてアドバイスを求めていました。チュモクラシーの周りには非常に多くのゴロゴロがあります、それは新聞がそれを呼んでいるものです、彼らが適切な人々を知っているので仕事を得ているように見える政府大臣の友人の友人。

クリス・マーフィー：私たちはこれの反対側に来て、これを見るつもりだと感じます…個人はそれを見て、「まあ、このお金はどこに行きますか、そして人々は適切に支払われていますか？ショップXのこの1ポンドのTシャツの価格はいくらですか？」ブランドについては触れたくありません。しかし、すべてが支払われる必要があり、作られたすべてのものは、それを作るために人々が支払われる必要があります。人々はますます興味を持っていると思いますが、人々は公平に支払われていますか？

Drew： GraphQLは、今年の最後の完全なエピソードのトピックでした。私はEve Porcelloとチャットし、GraphQLが開発スタックのどこに適合するかを尋ねました。

イブ・ポーセロ：うん。 GraphQLは、フロントエンドとバックエンドの間にある種の適合です。つまり、この2つの中間に位置し、フロントエンド開発者とバックエンド開発者に多くのメリットをもたらします。フロントエンド開発者の場合は、フロントエンドのすべてのデータ要件を定義できます。たとえば、Reactコンポーネントの大きなリストがある場合は、クエリを作成できます。これにより、そのページのデータに入力する必要のあるすべてのフィールドが定義されます。

Eve Porcello：さて、バックエンドピースを使用すると、さまざまなソースから多くのデータを収集できるため、それは本当に独自のものになります。つまり、REST APIとデータベース、およびこれらすべてのさまざまな場所にデータがあり、GraphQLは、すべてのデータが存在する場所の混乱を実際に理解するためのこの素敵な小さなオーケストレーションレイヤーを提供します。ですから、スタック全体のすべての人にとって非常に便利です。