스매싱 팟캐스트 32회: 2020년 올해의 리뷰

이 에피소드에서는 2020년을 되돌아봅니다. 올해 에피소드에서 우리는 누구와 이야기를 나누었고 무엇을 배웠습니까? 알아보기 위해 몇 가지 클립을 다시 들어 보겠습니다.

메모 표시

podcast.smashingmagazine.com에서 모든 인터뷰의 전체 스크립트를 포함하여 과거 에피소드를 모두 찾을 수 있습니다.

2021년에 만나요 여러분!

성적 증명서

Drew McLellan: 1월에 Amy Hupe와 영국 정부의 디자인 시스템에 대한 작업, 특히 팀이 기여를 장려하여 더 넓은 조직에서 시스템 채택을 증가시킨 방법에 대해 이야기했습니다. 여기 에이미가 있습니다.

Amy Hupe: 우리는 정말 일찍 시작했습니다. 그래서 일종의 공공 디자인 시스템을 갖기 전에 우리는 관심 있는 기여자라고 생각하는 사람들과 교류하기 시작했습니다. 여기서 언급해야 할 것은 우리 팀에 훌륭한 서비스 디자이너가 있다는 것입니다. 그녀는 우리와 합류했습니다… 지금은 날짜를 정확히 알 수 없지만 2018년 내내 그녀와 함께 일한 것 같습니다. 그녀의 이름은 Ignacia입니다. 그녀는 사람들을 돌아다니고 참여시키는 환상적인 일을 했습니다. 그래서 그녀가 한 일 중 하나는 정부의 모든 다양한 패턴과 이러한 패턴의 모든 다양한 종류를 식별하는 것이었습니다. 그래서 나가서 "알았어. 정부에서 주소를 요청하는 10가지 다른 방법이 있습니다. 모두 함께 살펴보고 어떤 접근 방식이 가장 적절하다고 생각하는지 결정해 보겠습니다. 이것을 어떻게 하나로 통합할 수 있습니까?”

Amy Hupe: 그녀는 사람들이 그것을 보고 팀으로서 그런 종류의 통합을 하도록 하기 위해 큰 워크샵을 운영했습니다. 우리가 실제로 무언가를 대중에게 공개하기 전에 공동 작업을 구축하는 방식에 대한 그녀의 접근 방식은 확실히 도움이 되었다고 생각합니다. 왜냐하면 그것은 사람들이 이미 그것에 대해 그런 종류의 인식을 갖고 있었고 많은 사람들이 이미 어떤 방식으로든 또는 어떤 방식으로든 그것에 기여했다는 것을 의미했기 때문입니다. 우리가 실제로 그것을 공개하기 전에 또 다른. 그래서 우리는 몇 발짝 앞서 있었습니다. 그래서 사람들이 기여할 수 있도록 돕는 데 팀 전체의 많은 끈기가 정말 중요하고 끈기 있다고 생각합니다.

Amy Hupe: 사람들이 디자인 시스템에 기여하게 하면 꽤 좋은 일이라는 생각이 들어요. 사람들이 당신을 위해 모든 일을 하도록 하고 거기에 그냥 앉아 있기만 하면 되기 때문입니다. 작은 코드를 수정하면 모두가 실제로 모든 좋은 것을 제공합니다. 그러나 실제로 디자인 시스템에 대해 작업해 본 사람이라면 알겠지만, 이는 엄청나게 복잡합니다. 여러 팀에서 작동하는 중앙 집중식 솔루션을 만드는 것은 매우 어렵습니다.

Amy Hupe: 정말, 디자인 시스템 작업을 하지 않는 한, 누군가가 그 작업이 무엇을 필요로 하는지 진정으로 이해하기를 기대하는 것은 합리적이지 않습니다. 그래서 손에 잡힐 일이 많다. 기여자들이 기여할 수 있도록 지원하는 데 많은 작업이 필요합니다. 전에도 말했지만, 누군가가 디자인 시스템에 기여하도록 돕는 것이 자신과 중앙 집중식 팀을 만드는 것보다 더 오래 걸릴 것이라고 생각합니다. 하지만 그것이 가져오는 가치를 인식하고 사람들이 기여를 인식하고, 일을 하도록 돕고, 동기를 부여하도록 돕기 위해 지속적으로 노력하는 것 같아요. 네, 그런 끈기가 정말 핵심이었습니다. 그 분야에서 우리의 성공.

Drew: Microsoft의 Stephanie Stimac 및 Aaron Gustafson과 함께 Edge가 Chromium을 렌더링 엔진으로 채택하는 것에 대해 이야기했습니다. 나는 Aaron에게 브라우저 간의 경쟁 환경과 동일한 렌더링 엔진에서 여러 브라우저가 통합되어 건전한 경쟁을 없애고 개방형 웹에 좋지 않은 상황에 대해 물었습니다.

Aaron Gustafson: 이것은 제가 확실히 오랫동안 웹 표준을 다루는 사람으로서 약간의 어려움을 겪었던 것입니다. 나는 그것에 대한 비즈니스 정당성을 완전히 이해합니다. 마이크로소프트의 관점에서 볼 때 그것은 많은 의미가 있었습니다. 프론트 엔드 개발자의 관점에서 보면 다양한 엔진을 수용할 필요가 없다는 것이 좋습니다. 내 말은, 우리 중 오랫동안 웹 작업을 해 온 사람들은 확실히 렌더링 측면에서 많은 수렴을 보았습니다. Netscape에서 7일 동안 우리가 겪었던 것만큼 많은 문제는 없었습니다. 우리가 겪었던 일은... 저는 서로 다른 브라우저에 대해 고유한 스타일 시트를 만드는 회사를 알고 있었습니다.

Aaron Gustafson: 하지만 지금과 달라진 점은 원래 브라우저 전쟁으로 돌아가면 이러한 독점 엔진이 모두 있었고 모두가 새로운 플랫폼 기능을 제공하고 새로운 JavaScript 기능 또는 Microsoft 리버스 엔지니어링 JavaScript의 경우 JScript를 만들고 이 모든 것을 함께 맞추는 방법을 알아 내려고 합니다.

Aaron Gustafson: 하지만 이제 우리는 실제로 오픈 소스 프로젝트에서 함께 일할 수 있고 여전히 대화를 나눌 수 있고 여전히... 잘 모르겠습니다. 싸움은 올바른 단어가 아니지만 서로 다른 접근 방식의 영향에 대해 진지하게 토론하고 서로 동의하지 않고 사양을 정말 좋게 만드는 데 실제로 노력하고 Chromium과 같은 컨텍스트 내에서 기본 코드에 대해 경쟁적인 접근 방식을 취하는 것입니다. 프로젝트 또는 WebKit 또는 Firefox 공간의 그러한 특성 또는 Missoula.

Aaron Gustafson: 그렇습니다. 한편으로 우리는 다른 렌더링 엔진을 잃어버렸고 오페라가 Chromium으로 가기로 결정했을 때도 같은 고통을 느꼈습니다. 하지만 저는 Microsoft 내부에 있으면서 우리가 의미 있는 방식으로 Chromium 프로젝트에 실제로 참여하기 위해 얼마나 노력하는지 보고 있으며, 그저 가만히 앉아서 Chromium에서 오는 모든 것을 받아들이는 것이 아니라 실제로 어떤 일이 진행되고 있는지 검토하고 있습니다. 플랫폼과 그 참여… 예.

Aaron Gustafson: 그래서 저는 그것에 대해 조금 용기를 얻었고 우리가 단지 그 프로젝트에서 가져오고 그 프로젝트에 이해 관계가 있는 모든 다른 사람들이 전달한 것을 받아들이기 위해 거기 있는 것이 아니라 실제로도 협력하고 있습니다.

Drew: 2월에 저는 Bootstrap 및 친구들과 같은 UI 프레임워크와 작업하고 사용 가능한 인터페이스의 사용자 정의 요구 사항과 균형을 맞추는 것에 대해 Stephanie Walter와 이야기했습니다. 나는 Stephanie에게 기성 프레임워크를 사용하면서 매우 유용한 UI를 만들 수 있는지 또는 항상 약간 어색한 타협이 될 것인지 물었습니다.

스테파니 월터: 네. 나는 그것이라고 생각한다. 그러나 그것은 또한 당신이 기꺼이 하고자 하는 타협의 수준에 달려 있으며, 이것은 양쪽 모두에서 타협합니다. 현재로서는 많은 버튼을 타협하고 있습니다. 예를 들어 머티리얼 UI에 정말 특정한 버튼이 있기 때문입니다. 나는 버튼의 파급 효과를 별로 좋아하지 않는다. 모바일에서는 사용자가 버튼을 클릭하거나 터치할 때 일종의 큰 피드백이 필요하기 때문에 모바일에서 잘 작동한다고 생각합니다. 그러나 그런 다음 버튼에 끝까지 가는 이러한 종류의 파급 효과를 적용합니다. 특히 버튼이 많을 때 약간 과도합니다. 하지만 여전히 우리는 이 파급 효과를 유지할 것입니다. 왜냐하면 이것이 React 프레임워크에 내장되어 있고 이 버튼에 또 다른 호버 효과가 있기 때문에 제거하는 것은 매우 복잡하기 때문입니다. 여기. 엄청나게 복잡할 것입니다. 그래서 이것은 당신이 하는 일종의 타협입니다.

Drew: 윤리적인 디자인은 Trina Felber 및 Martin Michael Fredrickson과의 대화 주제였습니다. 나는 디자인에 윤리적인 접근 방식을 취하고 어두운 패턴을 피하는 것이 단기적인 판매 목표가 아니라 비즈니스의 건강과 성장에 대해 장기적으로 생각하는 경우인지 물었다. 여기 마틴이 있습니다.

마틴 마이클 프레드릭슨: 그것은 완전히 사실입니다. 온라인에서 하는 사업을 중대도시의 큰길가에 매장을 둔 것처럼, 평판은 그대로 유지해야 한다고 생각합니다. 고객을 잘 대하지 않으면 장기적으로 사람들이 다른 가게에 가거나 온라인에서 구매하기 때문에 사업이 망하게 될 것입니다. 따라서 온라인에서 무엇을 하든 장기적 효과가 있고 복잡하거나 조작하는 일을 하는 데는 숨겨진 비용이 있다는 사실을 생각해야 합니다. Trina가 말했듯이 정리를 하면 장기적으로 절약할 수 있으며 비즈니스 모델에 대해 이야기할 때 계산되지 않습니다. 당신은 항상 당신이 얼마나 많은 돈을 벌 수 있는지에 대해 이야기합니다. 당신은 그 정도의 돈을 버는 데 드는 비용에 대해 결코 이야기하지 않습니다.

Drew: 3월에 Eduardo Boucas와 서로 다른 소스에서 콘텐츠를 수집하여 정적 사이트 생성기에서 사용할 수 있도록 하는 Sourcebit라는 오픈 소스 도구에 대해 이야기했습니다. 나는 이것이 헤드리스 CMS와 같은 도구와의 통합을 가능하게 함으로써 SSG에 대한 권한 부여의 사용자 경험을 향상시킬 수 있는지 Eduardo에게 물었습니다.

에두아르도 부카스: 맞습니다. 응. 가능한 방법... 저는 개발자를 도울 수 있는 도구를 사용하는 두 가지 다른 방법을 봅니다. 하나는 Sourcebit를 배포 루틴의 일부로 만드는 것입니다. 따라서 예를 들어 Netlify와 같은 호스팅 플랫폼을 사용하고 배포 명령을 Hugo 빌드로 구성하는 경우 Hugo에 대한 정적 파일을 생성합니다. 또한 해당 루틴의 일부로 다른 명령이 있습니다. Sourcebit fetch와 같은 것입니다. 따라서 빌드 시 Sourcebit는 다른 모든 데이터를 가져와 Hugo에 필요한 모든 파일을 생성한 다음 전체 배포에서 이미 해당 파일을 사용하고 CMS에서 가져온 모든 콘텐츠를 배포합니다.

Eduardo Boucas: Sourcebit 의 가능한 사용 사례 중 하나입니다. 다른 하나는 Sourcebit를 로컬 개발 워크플로에서 로컬 개발로 사용하는 것입니다. 따라서 우리가 watch 모드라고 부르는 것으로 Sourcebit를 실행할 수 있습니다. 따라서 Sourcebit는 원격 데이터 소스의 변경 사항을 계속 찾고 있으므로 이 경우 헤드리스 CMS입니다. 따라서 기사를 게시하거나 항목을 CMS로 변경할 때마다 Sourcebit는 이를 인식하고 로컬에서 모든 파일을 재생성합니다.

Eduardo Boucas: 로컬에서 작업하는 개발자에게 의미하는 바는 Hugo 사이트 옆에 있는 CMS 창을 로컬에서 실행하고 실시간으로 변경 사항을 볼 수 있다는 것입니다. CMS에서 무언가를 변경하면 해당 변경 사항이 로컬 사이트에 반영되는 것을 볼 수 있습니다. 이는 제가 매우 유용하다고 생각합니다. 이것은 Sourcebit를 사용할 수 있는 두 가지 방법입니다.

Drew: 오늘의 주제는 전환 최적화였습니다. 베테랑 팟캐스터이자 컨설턴트인 Paul Boag와 이야기를 나누었을 때. 우리는 사이트가 방문자를 고객으로 전환하는 데 사용하는 몇 가지 기술에 대해 이야기했습니다. 그러나 나는 Paul에게 당신이 만드는 변화의 영향을 어떻게 측정하는지 묻고 싶었습니다. 폴은 설명했다.

폴 보그: 네. 전적으로. 다시 말하지만, 이것은 많은 조직이 성공을 측정하는 방법에 대해 명확하지 않은 부분입니다. 예, 전환율은 하나의 측정항목입니다. 당신은 절대적으로 따라야합니다. 그러나 전환을 하더라도 구매하는 사람의 수보다 조금 더 정교해야 합니다. 평균 주문 금액에도주의를 기울여야합니다. 평생 가치에 각별히 신경을 써야겠죠? 그래서 평생 동안 고객의 가치는 얼마나 됩니까? 어두운 패턴과 이와 유사한 것을 사용하는 경우 고객 이탈률이 상당히 높다는 것을 알 수 있기 때문입니다. 그러나 실제로 전환은 측정하는 측정항목 중 하나일 뿐입니다.

Paul Boag: 참여, 즉 사람들이 귀하의 콘텐츠에 얼마나 참여하는지에 주의를 기울여야 하는 것과 같은 것들이 있습니다. 왜냐하면 그것이 그들이 궁극적으로 개종할지 여부에 큰 차이를 만들기 때문입니다. 그래서 당신은 당신의 비디오를 얼마나 보고 있는지, 그들이 당신의 사이트에서 얼마나 오래 머무르는지, 그들이 그것을 하는 동안 무엇을 보고 있는지 등을 보고 있는 것입니다. 그들은 소셜 미디어와 그런 종류의 일에 참여하고 있습니까? 그런 다음 마지막 측면은 분명히 사용성입니다. 누군가가 웹사이트에서 특정 작업을 얼마나 빨리 완료할 수 있는지, 시스템을 사용하기 위해 얼마나 쉽게 찾는지, 기타 다양한 기준을 측정해야 합니다.

Paul Boag: 이러한 다양한 측정에 사용할 수 있는 많은 메커니즘이 있습니다. 거기에는 몇 가지 훌륭한 도구와 채택할 수 있는 몇 가지 좋은 메트릭이 있습니다. 예를 들어 사용성에는 시스템 사용성 척도라는 것이 있는데 이는 측정하기에 매우 유용한 척도가 될 수 있습니다. 그러나 마찬가지로 maze.design과 같은 도구가 있습니다. 내가 자주 사용하는 도구로, 예를 들어 결제를 완료하는 등 누군가가 구매하는 데 걸리는 시간을 측정합니다. 그래. 그런 종류의 광범위한 메트릭을 가지고 있기 때문에 이번 분기에 얼마나 많은 매출을 올렸는가에 초점을 맞추는 것이 아닙니다. 더 큰 그림을 봐야 합니다.

Drew: 4월에 Better Blocker의 Laura Kalbag과 온라인 개인 정보 보호에 대해 이야기했습니다. 우리는 공개로 간주되는 것과 비공개로 간주되는 것 사이의 점점 좁아지는 경계와 우리가 비공개로 간주하는 것이 우리가 데이터를 위탁한 회사에서 어떻게 그렇게 보지 않을 수 있는지에 대해 이야기했습니다. 여기 로라가 있습니다.

Laura Kalbag: 몇 년 전에 나에게 일어난 전형적인 예가 있습니다. 그래서 저는 페이스북을 하고 있었고 어머니는 막 돌아가셨고 장의사 광고를 받고 있었습니다. 그 시점에서 가족 중 누구도 소셜 미디어 플랫폼에서 아무 말도 하지 않았기 때문에 정말 이상하다고 생각했습니다. 우리 가족 중 누구도 Facebook을 통해 친구나 가족에 대해 그런 것을 알고 싶어하지 않는다는 데 동의했기 때문에 Facebook에서 아무 말도 하지 않았습니다. 그래서 우리는 그것에 대해 말하지 않았습니다.

Laura Kalbag: 그래서 저는 형제들에게 이렇게 물었습니다. "오, Facebook에서 이 이상하게 만들 수 있는 말을 한 사람이 있습니까?" 왜냐하면 나는 보통 메이크업과 드레스, 임신 테스트기, 그리고 그들이 좋아하는 모든 재미있는 것들에 대한 광고를 받기 때문입니다. 특정 연령의 여성입니다. 대신 언니가 나에게 돌아왔다. 그녀는 "글쎄요. 제 친구는 호주에 살고 있어요.” 그래서 나는 그녀에게 페이스북 메신저로 우리 엄마가 돌아가셨다는 메시지를 보냈다. 물론 페이스북은 우리가 자매라는 것을 알고 있었습니다. 거기에 추가하도록 선택할 수 있는 관계 연결이 있습니다. 내 말은, 아마도 우리가 함께 있었던 장소, 우리가 성을 공유하고 "오, 그녀의 발에 넣어야 할 적절한 광고"라고 결정했다는 사실에 의해 우리가 자매였다는 것을 짐작할 수 있을 것입니다.

Drew: 기술이 우리를 위해 이러한 결정을 내리고, 이 예에서 잠재적으로 사람들에게 잠재적으로 상당히 민감하거나 취약한 시간에 영향을 미칠 수 있다고 생각하는 것은 정신을 차리게 하지 않습니까?

로라 칼백: 네. 우리는 그것이 오싹하다고 말합니다. 많은 경우 사람들은 "오, 이 특정 제품에 대해 대화를 나누다가 갑자기 내 피드에 갑자기 나타나서 내 전화나 노트북의 마이크가 내 말을 듣고 있는 것 같아요."라고 말합니다. 실제로 무서운 것은 그들 대부분이 당신의 마이크에 접근할 수 없다는 사실입니다. 그러나 그것은 당신의 다른 행동, 당신의 검색, 당신이 서로 가까이 있고 당신의 기기에서 당신의 위치 때문에 당신이 누구와 이야기하고 있는지 알고 있다는 사실입니다. 그것은 우리가 서로 연결되지 않을 수도 있는 모든 것들을 연결하여 "아, 아마도 그들은 이미 그것에 대해 생각하고 이야기하고 있었기 때문에 이 제품에 관심을 가질 것입니다."라고 말할 수 있습니다.

Drew: 코로나바이러스 팬데믹이 닥치고 많은 국가가 어떤 형태로든 폐쇄 조치를 취함에 따라 저는 Rachel Andrew와 Smashing이 대신 온라인으로 예정된 대면 회의를 조정하는 방법에 대해 이야기했습니다. Smashing 컨퍼런스 샌프란시스코를 연기해야 ​​했던 저는 Rachel에게 다가오는 컨퍼런스와 워크샵을 가상 도메인으로 옮기는 계획이 무엇인지 물었습니다.

Rachel An Drew: 샌프란시스코를 연기해야 ​​한다는 사실을 깨달았을 때 매우, 매우 빠르게, 분명히 우리는 워크샵을 갖고 있습니다. 저와 Vitaly는 모두 스매시 및 컴프에서 워크샵을 운영하고 있습니다. 샌프란시스코에서는 두 곳 모두 매진되었습니다. 우리의 워크샵. 분명히, 우리는 우리를 위해 워크숍을 운영하는 많은 사람들이 있습니다. 우리와 오랫동안 함께 일해 온 사람들은 그들의 모든 워크숍과 우리 중 워크숍을 하는 사람들이 실제로 우리 수입의 핵심 부분.

Rachel An Drew: 대중 연설에서, 당신은 일반적으로 연설을 하고 많은 돈을 벌지 못합니다. 연설문 등을 작성하는 데 걸리는 시간을 고려할 때가 아니라 대부분의 사람들은 많은 급여를 받지 않습니다. 워크샵은 이런 것들을 잘 가르치는 사람들이 돈을 벌기 위한 꽤 좋은 방법인 경향이 있습니다. 그래서 그들은 사람들의 소득을 나타냅니다. 그래서 나 자신이 필요했을 뿐만 아니라 Vitaly는 올해 초 워크샵을 잃었습니다. 우리는 또한 많은 Smashing 연사들도 이러한 워크샵에 의존하고 있다는 것을 깨달았습니다.

Rachel An Drew: 그래서 우리는 생각했습니다. 아주, 아주 빨리, 정말 그 일이 일어난 지 며칠 만에 우리는 나와 Vitaly가 가장 먼저 권력에 대해 머리를 맞대기로 결정했지만 우리가 주어진다면 어떻게 해야 할지 알 수 있었습니다. 우리는 또한 매우 다양한 워크샵을 가지고 있습니다. Vitaly는 훨씬 더 협력적입니다. 그는 그룹 활동과 물건이 있습니다. 나는 교실 스타일을 가르친다. 그래서 우리는 "글쎄, 우리는 모든 기지를 덮고 있는 것 같다"고 생각했습니다. 그래서 우리는 생각했습니다. “그냥 해보자. 작동하는지 봅시다.” 그래서 우리는 그들을 광고합니다. 우리는 각각의 작업에 시간이 얼마나 걸리는지 파악한 다음 앉아서 "음, 온라인 워크샵은 실제로 어떤 모습인가요? 이게 뭔가요?"

Drew: 기술적인 관점에서 웹 개발자는 즉시 생각하는 것 같아요. 도대체 우리가 어떻게 그런 것을 제공할 수 있겠습니까? 제 말은, 당신이 보았을 다른 플랫폼이 많이 있을 것입니다. 당신이 보았던 다른 것들은 무엇이고 Smashing은 결국 무엇을 얻었습니까?

Rachel An Drew: 그래서 우리는 모든 종류의 일을 살펴보았고 여전히 그렇게 하는 과정에 있습니다. 현재 Zoom을 사용하고 있습니다. Zoom을 사용하는 이유는 접근성입니다. 가장 접근성이 좋은 플랫폼이었습니다. 분명히, 우리는 우리가 선택한 플랫폼 때문에 사람들을 잘라내고 싶지 않습니다. 다른 플랫폼은 점점 더 좋아지고 있고 사람들은… 그러나 우리는 당신이 접근 가능해야 합니다.” 따라서 줌은 현재 사람들이 가장 쉽게 사용할 수 있습니다.” 그것이 우리가 그것들을 사용하게 된 이유입니다. 우리가 영원히 할 것인지 모르겠습니다. 하지만 그것이 우리가 현재 사용하고 있는 것이고, 이 일을 하는 방법으로 꽤 잘 작동했습니다.

Drew: Zoom의 피로가 시작되고 세상이 빠르게 새로운 표준이라고 불리는 것에 적응하기 시작하면서 저는 Phil Smith에게 기술이 COVID-19와 같은 상황에 대응하는 데 도움이 될 수 있는 방법에 대해 이야기했습니다. 단 10일 만에 React Native 앱 CardMedic을 빌드합니다. 나는 Phil에게 직무에 가장 적합한 기술을 선택하는 것과 그가 익숙하고 빠르게 작업할 수 있는 기술의 균형을 어떻게 맞추는지 물었습니다.

필 스미스: 좋은 질문입니다. 프로젝트가 나에게 언급되자마자 이 모든 것을 구축하는 방법을 정확히 알고 있다고 생각했습니다. 아이가 없고 어두운 방에 앉아 있었다면 요구 사항이 매우 많았기 때문에 견고하고 견고하며 견고하게 작업했더라면 약 5일 만에 모든 것을 뒤집을 수 있었을 것이라고 생각합니다. 내 앱 빌드 경험과 일치합니다. API를 호출하고 결과를 상태에 저장하고 표시하는 비슷한 종류의 것을 만들었습니다. 저는 이제 "좋아요, 다시 돌아가서 리팩토링해야 합니다."라고 생각하는 부분이 있는 위치에 있습니다.

Phil Smith: 주석 입력에 대해 이야기한 적이 있지만 실제로는 유형이 앱에서 상당히 느슨할 수 있으므로 이를 조일 필요가 있습니다. 백 엔드에서는 테스트가 많지 않고 이제 백 엔드를 롤백하기 시작했습니다. 많은 사람들이 "사실, 이것은 훌륭한 리소스입니다. 이것을 제 모국어로 번역하는 봉사에 자원하고 싶습니다.” 더 많은 사람들이 백엔드를 사용하고 있기 때문에 "잠깐만요, 지금 프로덕션에서 이것을 사용하는 사람들이 있기 때문에 아무 것도 깨질 수 없는지 확인하기 위해 몇 가지 테스트가 더 필요합니다."라고 생각하고 있습니다. 나는 당신의 질문에 대답했다고 생각합니다. 기본적으로 의사결정이 없었습니다. 최대한 빨리 그곳에서 꺼내야만 했다.

Drew: 직장이 문을 닫고 우리 중 많은 사람들이 재택 근무에 적응함에 따라, 저는 Ben Frain에게 가정 작업 공간을 편안하고 생산적인 장소로 최적화하는 것이 장기적인 신체 건강 문제를 일으키지 않을 것이라고 말했습니다. 집에 설치하는 데 사용할 수 있는 예산이 제한되어 있기 때문에 Ben에게 좋은 의자가 시작하기에 가장 좋은 장소인지 물었습니다.

벤 프레인: 그게 제 조언이 될 겁니다. 응. 내 말은, 내가 이런 것들에 대한 권위자라고 공언할 수는 없지만, 그것은 아마도 당신이 하루 종일 편안하게 지낼 수 있도록 할 수 있는 가장 중요한 일인 것 같습니다. 상당히 비싼 것으로 시작할 수 있습니다. 저도 같은 실수를 저질렀고 결국 아마존에서 45파운드의 사무용 의자를 얻었습니다. 그리고 그 축에 맞는 단어가 무엇이든 간에 앞으로 기울어지지 않는다는 것을 깨닫지 못했습니다. 그래서 제가 찾은 것은 무릎 뒤와 같은 허벅지 아래쪽을 파고 있었습니다. 저는 생각했습니다. "저걸 45분 동안 앉아 있으면 다리가 왜 죽어가는 거죠?"

Ben Frain: 특히 괜찮은 사무용 의자를 제공하는 회사에서 일한다면 그것을 당연하게 여기고 특정 제조사와 브랜드를 보고 나서야 “맙소사, 이거구나. 700달러짜리 의자.” 당신이 그 위급함을 깨달을 때, 사람들은 이것에 대해 생각하고 당신을 위해 많은 일을 했고, 분명히 당신은 집 환경에 와서 "의자에 X백 달러를 쓰지 않는 이유는 무엇입니까?"라고 생각합니다. 하지만 그럴만한 가치가 있습니다. 특히 당신이 장거리를 위해 여기 있는 경우에.

Drew: 그리고 장거리가 우리가 얻은 것입니다. 장기적으로 주변에 있는 다른 것은 Drupal입니다. 6월에 저는 Angie Byron과 Drupal 9의 변경 사항에 대해 이야기했습니다. Drupal이 처음 출시된 지 20년이 지난 지금, Drupal은 많은 발전을 이루었습니다. Angie에게 Drupal 9로 이전할 때 기존 Drupal 사이트를 업그레이드하는 과정이 어땠는지, 그리고 장기간 사이트를 운영하는 사람들에게 큰 부담이 될 수 있는지 물었습니다.

Angie Byron: 기본적으로 세 가지 시나리오가 있다고 생각합니다. 하나는 Drupal 8을 실행 중이고 Drupal 8의 새로운 마이너 릴리스가 나올 때마다 즉시 로 업그레이드하고 새로운 기능을 사용하기 시작한 경우입니다. 당신의 길은 기본적으로 아무것도 아닐 것입니다. 당신은 이미 모든 일을 했고 괜찮습니다. 얼마 전에 Drupal 8로 이전했고 BC 변경 사항을 따라가지 못했다면 약간의 작업이 필요합니다.

Angie Byron: 어쨌든 10년이 넘는 우리 소프트웨어 중에서 가장 쉬운 업그레이드이며, 이를 도와줄 다양한 도구가 있습니다. 기여한 모든 모듈과 Drupal 9 상황을 보여주는 대시보드가 ​​있습니다. 코드를 살펴보고 확인하고 더 이상 사용되지 않는 기능에 플래그를 지정하는 자동화 도구가 있으며 자동으로 실행되어 "이것이 모듈의 최신 버전이고 Drupal 9가 준비되었습니까? 다운로드 받으러 가셔야죠.” 이런 식으로 말이죠.

Angie Byron: Drupal 8에서 9까지, 그 부분이 꽤 잘 커버되었다고 말할 수 있습니다. Drupal의 이전 버전(예: Drupal 7 이하에서 Drupal 9로 변경)에서 온 경우 조금 더 까다로워 보이기 시작합니다. 예를 들어 우리가 완전히 객체 지향 PHP로 전환하고 다른 소프트웨어 프로젝트에서 발견된 디자인 패턴을 활용하기 시작한 Drupal 8의 변경 사항 중 아키텍처적으로는 정말 현명한 일이지만 실제로는 예전에 수많은 사용자 정의 코드가 있었다면 Drupal 9에서는 이에 대한 대안을 찾아야 한다는 의미입니다.

Angie Byron: 그래서 Acquia는 이 문제를 해결하는 것을 목표로 하는 Acquia Migration Accelerator라는 제품 및 개발입니다. 여기서 우리는 이전 Drupal 7 데이터를 읽고 그에 상응하는 Drupal 8 데이터를 생성하는 멋진 React 정의 애플리케이션을 만들고 있습니다. 필요한 모든 모듈과 함께 이전 버전을 사용하는 모든 사람이 여전히 이전 버전을 사용할 수 있도록 하기 위해 해당 프로세스를 시도하고 촉진할 수 있는 경우 이전 Drupal 7 모듈에 매핑해야 합니다. 모든 사람이 같은 버전에 있고 우리 모두가 함께 일하는 새로운 세계 질서.

Angie Byron: 그런 다음 Drupal 7도 확장했습니다... Drupal의 오픈 소스 커뮤니티인 Drupal 7은 내년 11월에 종료됩니다. 어쨌든 현재로서는 COVID가 영향을 미치는지 여부에 대해 논의해야 합니다. 그러나 여러 회사가 있으며 Acquia는 그 이상으로 최소한 2024년까지 Drupal 7에 대한 확장 지원을 제공하는 회사 중 하나입니다. 그래서 쉽게 업그레이드할 수 있는 사람은 1년 반 안에 완료할 수 있고, 덜 쉬운 사람은 업그레이드할 수 있으며, 필요한 경우 완료하는 데 잠재적으로 3년 반 또는 더 오래 걸릴 수 있습니다. 그리고 우리는 모든 사람들이 이 단계로 넘어갈 수 있도록 하고 프로세스 속도를 높이는 데 도움이 되는 Acquia Migrate Accelerator와 같은 도구를 구축할 수 있도록 열심히 노력하고 있습니다.

Drew: 학습 React는 Mina Markham과의 대화 주제였습니다. 나와 미나는 둘 다 처음으로 React를 배우는 입장이었다. React와 같은 프레임워크가 브라우저에 얼마나 많은 부담을 줬는지 생각하며 Mina에게 클라이언트의 손에 너무 많은 제어 권한을 부여한 것이 실수인지 물었습니다.

Mina Markham: 다시 한 번 말씀드리지만 제 경험은 대부분 정적인 웹사이트에 포함되어 있다는 점을 말씀드리고 싶습니다. 저는 제품 개발을 많이 하지 않습니다. 그래서 아마도 그 영역에서는 이것이 더 합리적일 것입니다. 하지만 내 관점에서 우리는 버터 나이프가 필요할 때 도끼를 사용하는 경우가 많다고 생각합니다. 나는 왜 우리가 이 모든 것을 브라우저에 넣어야 하는지, 우리가 많은 일을 할 수 있을 때 클라이언트에 너무 많은 작업과 많은 압력을 가해야 하는지 모르겠습니다... 훨씬 더 간단하게 할 수 있을 것 같습니다. 항상 React를 사용하는 것을 약간 주저하게 만드는 것 중 하나, 또는 저는 주저한다고 말하지만, 그것이 저를 본능적으로 화나게 만들고 적극적으로 반대했을 때 의미하는 것은 웹사이트에 가서 말 그대로 아무 것도 렌더링되지 않을 때였습니다. 하나의 오류가 있거나 하나의 기능이 고장나서 전체 페이지가 깨졌습니다.

Mina Markham: 많은 경우에 그것이 전부 아니면 전무(all or nothing) 방식이라는 것이 저를 짜증나게 했습니다. 과거 AEA와 과거 다른 장소에서 제가 했던 강연 중 하나는 점진적인 향상을 포함하는 방법에 대한 이야기였습니다. 귀하의 개발뿐만 아니라 더 큰 아트 디렉션 및 사이트 디자인도 포함됩니다. 나는 점진적인 향상이나 어떤 종류의 우아한 저하도 하지 않은 웹사이트의 예를 구체적으로 지적할 것입니다. 브라우저에서 JavaScript를 실행하고 있거나 아무 것도 얻지 못하는 것입니다. 1990년대부터 지금까지의 웹디자인의 역사, 실제로 이야기되는 사이트 중 하나인 웹디자인의 역사에 대한 정보를 나타내는 단순한 사이트일 것입니다. 많은 타임라인과 애니메이션이 있는 아름다운 웹사이트였습니다. 그러나 목록만 있으면 정적으로 렌더링될 수도 있습니다. 아무것도 표시하지 않는 것과 현재 현대적인 웹 개발에 접근하는 방식 때문에 잃어버렸던 아름답게 향상된 경험을 보여주는 사이에는 단계가 있습니다.

Drew: Andy Bell과 BEM, SMACSS, OOCSS 방식의 스타일링 방법론인 CUBE CSS에 대해 이야기했습니다. 많은 CSS 접근 방식은 캐스케이드와 같은 CSS의 자연 속성에 대해 작동하려고 합니다. CUBE는 그러한 행동을 적극 수용합니다. 여기 앤디가 있습니다.

Andy Bell: SCSS에 대한 좋은 비유는 Sass와 마찬가지로 자연 CSS 언어의 확장입니다. 그렇죠? 당신은 여전히 ​​CSS에서 꽤 옳습니다. 그래서 CUBE CSS가 그렇습니다. 따라서 CSS의 확장입니다. 그래서 우리는 여전히 CSS를 작성해야 합니다. CSS는… 솔직히 말해서, 그것이 어떻게 쓰여져야 하는지. 이름에서 알 수 있듯이 Cascading Style Sheets입니다. 제가 발견한 것은 미시적 최적화 수준까지 내려갔기 때문입니다. 나는 최근에 많은 사람들이 아래로 내려가는 것을 보는 길을 가는데… 기사에서도 이것을 언급했습니다. 제가 볼 수 있는 곳은… 최근에 그것에 대한 몇 가지 증거가 있습니다. 나는 사람들이 스페이서 구성 요소와 이와 유사한 것을 만드는 것을 목격했으며 그 문제를 이해합니다. 나는 그런 상황에 처한 적이 있다.

Andy Bell: 내가 수정한 방법은 드릴다운하고 미세하게 최적화하는 대신 구성 요소가 얼마나 작은지 문제가 되지 않기 때문에 실제로 구성 수준에서 생각하기 시작했습니다. 어느 시점에서 그들은 페이지가 될 것입니다. 그들은 조회수가 될 것입니다. 당신은 그것을 피할 수 없습니다. 그렇게 될 것입니다. 따라서 "맞아, 이 레이아웃을 수행하려면 이 작은 도우미가 필요해"라고 말하는 대신 "맞아요. 연락처 페이지 보기 또는 제품 페이지 보기가 있는데 이것이 골격 레이아웃 구성입니다. 그런 다음 그 안에 내가 원하는 모든 구성 요소를 넣을 수 있습니다.”

Andy Bell: 이제 Grid 및 Flexbox와 같은 기능을 통해 훨씬 더 쉽게 달성할 수 있으며 기본적으로 골격 레이아웃 내부에 원하는 모든 것을 넣을 수 있습니다. 그것은 중요하지 않습니다. 그런 다음 구성 요소는 그 시점에서 컨테이너 쿼리를 사용하거나 사용하지 않고 원하는 대로 작동해야 합니다.

Drew: Gatsby는 Marcy Sutton과의 대화 주제였습니다. 대부분의 정적 사이트 생성기는 프론트 엔드 코드에 구애받지 않지만 Gatsby는 React를 사용하므로 최종 웹 경험의 일부로 Gatsby 코드가 실행됩니다. 나는 Marcy에게 그 코드가 무엇이며 어떤 기능을 제공하는지 물었습니다.

마시 서튼: 네. 그 중 가장 큰 부분은 클라이언트 측 라우팅이라고 말하고 싶습니다. 그래서 Gatsby는 지금 후드 아래에서 retreader를 사용하고 있습니다. 그것은 일종의 자체 구현입니다. 그러나 그것은 처음으로 정적 사이트를 로드할 때 HTML 파일이 있는 부분입니다. 따라서 사용자가 어떤 이유로 JavaScript를 끄더라도 귀하의 사이트는 여전히 그곳에 있어야 하며 여전히 콘텐츠가 있어야 합니다. 그러나 JavaScript가 활성화되면 이 수화 단계가 발생합니다. 여기서 Gatsby 사이트의 링크를 사용할 때 해당 페이지에서 리소스를 미리 가져옵니다. 따라서 더 빨리 로드됩니다. 따라서 Gatsby가 제공하는 이 JavaScript 레이어를 사용하면 이 모든 것이 가능합니다.

Marcy Sutton: 그 외에도 사이트에서 사용하는 것과 JavaScript 번들에 포함되는 내용에 따라 달라집니다. 그러나 액세스 가능한 인터페이스와 같이 상호 작용을 많이 사용하는 항목의 경우 좋은 위치입니다. 저에게는 항상 JavaScript를 사용할 수 있고 내 마크업이 좋은 위치에 있게 하는 것이 정말 좋습니다. HTML과 JavaScript, CSS가 모두 깔끔하게 결합되기를 원하는지 여부는 선호도의 문제이며 Gatsby를 구축하는 데 있어 변형의 여지가 있다는 것을 압니다. CSS 및 JS와 같은 것을 항상 사용할 필요는 없습니다. 그러나 실제로 웹 사이트를 작성하는 동안 사용할 수 있는 동적 JavaScript 계층의 기능을 얻는 것입니다. 별도의 파일에 있는 이 추가 기능과 다릅니다.

Drew: 정적 사이트 생성기가 일반적으로 어떻게 작동하는지 생각할 때 아마도 마크다운 파일의 콘텐츠를 생각하고 생성기는 해당 콘텐츠를 가로질러 실행하고 템플릿과 병합하고 수십, 수백, 수천 개의 HTML 파일을 생성합니다. 귀하의 웹사이트 페이지. React 사이트나 앱을 생각할 때 나는 인터페이스가 React에 의해 즉석에서 생성되는 단일 페이지 경험에 대해 더 많이 생각합니다. 개츠비가 이 두 가지를 모두 한다는 말입니까? 모든 페이지를 생성하고 JavaScript로 개선하고 있습니까?

마시 서튼: 그렇습니다. Gatsby는 빌드 시 Node.js를 사용하고 React 구성 요소를 살펴보고 HTML 파일로 컴파일합니다. 솔직히 말해서 Gatsby를 처음 봤을 때 JavaScript를 끄지 않고 이렇게 말했습니다. 여기에 다른 페이지가 있습니까? 이게 뭔가요?" Gatsby가 기본적으로 그런 식으로 작동한다는 사실이 너무 기뻤습니다. React 구성 요소에서 빌드된 파일을 생성합니다.

Marcy Sutton: JavaScript에 있기 때문에 좀 더 점진적인 향상 접근 방식을 살펴보았습니다. 예를 들어 사용자를 위해 점진적으로 향상된 기능을 출력하려면 어떻게 합니까? JavaScript가 꺼져 있는 경우 JavaScript를 가정하는 깨진 코드를 모두 원하지 않을 것입니다. 있다. 그래서 약간의 단점이 있습니다. 그러나 최소한 누군가가 여전히 무언가를 살 수 있기를 원하는 핵심 사용자 흐름에 대해서는 그런 종류의 문제를 해결할 수 있습니다. 이러한 사용 사례에 대한 지원을 추가해야 할 수도 있습니다. 그러나 나는 Gatsby가 기본적으로 그것을 구현하는 방식에 유쾌하게 놀랐습니다.

Marcy Sutton: 그래서 그들은 그런 방식으로 사이트를 구축하기로 한 선택이었고 우리는 항상 평가하고 있습니다. 여전히 최선의 방법입니까? 사용자가 원하는 것을 제공하려면 어떻게 해야 합니까? 그래서 우리는 내부적으로 몇 가지 탐색을 하고 있으며 Gatsby가 웹사이트 구축에서 할 수 있는 최선의 일을 하고 있는지 확인하기 위해 계속 진행 중입니다. - 가져오기, 백업할 데이터가 있습니까? 개발자 옹호자로서 제가 매우 관심을 갖고 있는 것은 웹사이트에서 패키징하고 번들로 제공하는 것이 실제로 필요하고 실제로 최고의 Gatsby 사이트를 만들 수 있는지 확인하는 것입니다.

Drew: 7월에 Chris Ferdinandi와 이야기하면서 현대의 모범 사례가 웹에 나쁜지 물었습니다. Chris는 린 웹(Lean Web)으로 알려진 운동을 지지했고 나는 그에게 그것이 무엇을 수반하는지 물었습니다. 여기 크리스입니다.

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. 나는 오늘날 우리가 모범 사례라고 생각하는 많은 것들이 실제로 웹을 악화시킬 수 있다고 믿게 되었습니다. 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. 그러나 실제로 린 웹은 사용자를 위한 단순성과 성능에 초점을 맞추고 우리가 만드는 것을 만드는 사람들보다 우리가 만드는 것을 사용하는 사람들에 우선순위를 두거나 초점을 맞추는 것입니다.

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를 처리합니다. 그것은 하나의 작은, 작은, 작은, 작은 작업을 가지고 있습니다. 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 don't know what that is. 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를 위한 것이 있습니다. Less를 위한 것이 있습니다. Babbel을 위한 것이 있습니다. TypeScript용이 있습니다. 하나는... 모두 우리가 실행하는 개별 람다입니다. 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. 타입스크립트였습니다. 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.

Natalia Tepluhina: 이것은 다시 중요한 부분이었습니다. 마지막 하나는 구성 요소가 아니라 기능 도우미 등과 같은 구성 가능한 논리 부분의 관점에서 논리를 추상화하는 기능을 놓쳤지만 Vue 활동도 포함할 수 있어야 한다는 것입니다. 여기에서 좋은 예는 React Hooks가 될 수 있습니다. 맞죠? 그것들을 통해 기능의 일부를 추상화할 수 있으며 이는 Vue에서 분명히 누락되었습니다. 지금은 "당신은 React에서 기능을 훔쳤습니다." 사실은 아닙니다. 아이디어 교차 수분은 우리 생태계에서 크고 좋은 부분이며 개발자가 즐겨찾기 간에 전환하는 데 도움이 된다고 생각합니다. 그렇죠? 그래서 우리는 Vue 3를 주 버전으로 만들기 위해 이러한 주요 기능에 대해 작업하고 있었습니다.

Drew: 그 후 우리는 Stefan Baumgartner와 함께 TypeScript를 자세히 살펴보고 더 적은 수의 버그로 더 나은 코드를 작성하는 데 어떻게 도움이 되는지 알아냈습니다. 조직에서 코드 기반을 JavaScript로 완전히 옮기는 추세를 관찰하면서 저는 Stefan에게 TypeScript가 개인보다 더 큰 팀에서 더 많은 이점을 얻을 수 있는 것이냐고 물었습니다.

Stefan Baumgartner: 그래서 저도 현재 같은 전환기에 있습니다. 그래서 우리는 장래에 많은 JavaScript를 작성할 Java 및 C++ 개발자를 많이 가지고 있습니다. TypeScript는 새로운 프로그래밍 언어의 무서운 영역에 대한 일종의 가이드가 될 수 있습니다. 다른 프로그래밍 언어에서 온 경우 JavaScript에는 많은 단점, 많은 역사 및 많은 편견이 있습니다. 따라서 TypeScript는 유형 시스템에서 친숙한 몇 가지 개념이 있기 때문에 가이드가 될 수 있습니다.

Stefan Baumgartner: 하지만 특히 같은 코드 기반에서 작업하는 많은 사람들이 있거나 서로 작업해야 하는 많은 사람들이 있을 때 이것은 프로젝트에서 추가 지침이 될 수 있습니다. 결국 나쁜 놀라움이 없습니다. 따라서 물론 기술은 통신 문제를 해결하지 못합니다. 이것은 TypeScript가 의도한 것이 아닙니다. 그러나 그것은 낮을 수 있거나 올바른 토론을 위한 훨씬 더 많은 공간을 만들 수 있습니다. 그러면 당신이 이야기할 필요가 없다면, 당신은 당신의 코드에서 나에게 무엇을 기대합니까? 오히려 당신의 코드가 무엇을 해야 하는지 또는 도서관은?

Stefan Baumgartner: 저는 항상 다른 사람들을 위해 코드를 작성하거나 많은 사람들과 함께 코드를 작성하거나 자신을 위해 코드를 작성하는 경우 다음 날 다시 방문해야 한다고 말합니다. TypeScript가 장기적으로. 이것은 다음 주의 다음 프로젝트를 위한 투자일 뿐만 아니라, 특히 1개월, 2년 또는 1년 동안 오래 지속되는 프로젝트가 있는 경우 확실히 제안하는 사람을 위한 것입니다. 1년 전에 작은 코드 조각을 작성할 때 무슨 생각을 했는지 결코 알 수 없지만 유형을 통해 의미하는 바를 알 수 있습니다.

Drew: 11월에 David Darnes와 정적 사이트 생성기 Eleventy에 대해 이야기했습니다. 우리는 템플릿에 대해 이야기했고 얼마나 많은 정적 사이트 생성기가 어떤 유형의 템플릿을 사용해야 하는지에 대해 상당히 의견이 엇갈렸습니다. 일레븐티도 그런 확고한 신념을 갖고 있는지 궁금했다. 여기 데이브가 있습니다.

David Darnes: 아니요, 당신이 얻을 수 있는 한 의견이 없을 정도로 가깝습니다. 약간의 개인적인 견해지만, 어떤 틀이나 의견이 없는 것을 보기가 어려웠습니다. 무언가를 만들기 위해서는 어떻게 하고 싶은지에 대한 의견이 있어야 하기 때문입니다. 일종의 모순입니다. 나는 사람들이 그것에 대해 나를 고칠 수 있다고 확신합니다. 하지만 그래. 가장 편안하다고 느끼는 템플릿 언어로 전환할 수 있습니다. 내 말은, 우리는 당신이 편안한 언어에 대해 이야기하고 있었던 것뿐입니다. Eleventy는 템플릿 언어가 HTML 내부에서 사용하거나 원하는 경우 CSS까지 사용하는 일종의 의미에서 이에 호소합니다.

David Darnes: 저는 nunjucks가 Eleventy 내부의 기본 템플릿 언어이기 때문에 바로 nunjucks로 이동했습니다. 즉, dot HTML 확장을 사용하고 그대로 둘 수 있습니다. 이제 저는 사람들을 더 혼란스럽게 하고 "어쨌든 이름은 마음대로 지정할 수 있습니다. 당신은 그것으로 진짜 재미를 가질 수 있습니다.” 그러나 핸들 바를 사용할 수 있습니다. 일반 JavaScript 템플릿을 사용하고 그렇게 반복할 수 있다고 생각합니다. 핸들 바는 꽤 유명하고 Liquid도 있습니다. 머리로는 모든 것을 생각할 수 없지만 구성에서 모두 설정하면 원하는 대로 선택할 수 있습니다.

David Darnes: 저는 일반적으로 템플릿 언어에 대한 열렬한 팬이라고 말하고 싶습니다. 워드프레스 내부에서 나뭇가지를 사용할 수 있다는 것을 알게 된 것은 그리 오래되지 않았습니다. 나는 "오, 맙소사. PHP 내부에서 for 루프를 처리할 필요가 없습니다.” 다시 말하지만, 조금 더 편안하고 이해하기 쉬우며 더 읽기 쉽다고 생각합니다. 그래. Eleventy에는 다양한 템플릿 옵션이 있으며 이러한 템플릿에 익숙한 사람들에게 어필해야 합니다.

Drew: Netlify가 자체 플랫폼을 사용하여 Netlify를 구축하는 방법과 Deploy Preview 기능이 프런트 엔드 변경을 위한 효과적인 스테이징 플랫폼이 되는 방법에 대해 Leslie Cohn-Wein과 이야기했습니다.

Leslie Cohn-Wein: 전체 프로세스에서 제가 가장 좋아하는 부분은 Netlify를 통해 얻을 수 있는 Deploy Previews의 마법일 것입니다. 따라서 GitHub에서 작업하고 PR을 푸시합니다. 따라서 GitHub에서 PR을 열면 앱의 Deploy Preview 빌드가 자동으로 생성됩니다. 따라서 실제로 앱 자체의 Deploy Previews를 사용하여 모든 것이 제대로 작동하는지 확인합니다. 우리는 우리의 테스트를 실행합니다. 이것이 우리가 코드 검토 중에 수동으로 확인하는 데 사용하는 것입니다. 그래서 우리는 GitHub에서 바로 모든 지속적인 배포를 설정했습니다.

Leslie Cohn-Wein: 그런 다음 우리가 설정한 다른 멋진 점 중 하나는 실제로 앱이 있는 동일한 저장소에서 가져오는 두 개의 다른 Netlify 사이트가 있다는 것입니다. 그래서 우리는 둘 다 앱을 가지고 있습니다. 앱에 대한 일종의 UI 구성 요소가 있는 Storybook 인스턴스가 있습니다. 그래서 우리는 둘 다 앱 자체를 가지고 있습니다. Storybook UI 구성 요소가 있고 기본적으로 Storybook UI를 보여주는 Netlify 사이트가 있으며 웹팩 번들 분석기를 실행하는 세 번째 사이트도 있습니다. 모든 앱 번들에 대한 트리 맵 시각화를 제공하는 일종의 시각적 UI이며 크기를 측정할 수 있습니다. 앱이 배포될 때마다 일종의 재확인을 하라는 알림일 뿐입니다. 밖으로, 우리는 우리의 번들 크기에 이상한 일을 하고 있지 않은지 확인하고 확인할 수 있습니다.

Leslie Cohn-Wein: 따라서 이 세 사이트는 모두 앱의 한 번의 pull 요청으로 생성됩니다. 따라서 우리가 확인할 수 있도록 앱 스토리북과 해당 앱 프로필의 미리보기 링크, 즉 기본적으로 배포 미리보기 링크를 받게 됩니다.

Drew: 12월에 Chris Murphy와 제품 디자인에 대해 이야기했고 비즈니스에 초점을 맞춘 디자인이 의미하는 바에 대해 이야기했습니다. 우리는 개별 설립자가 초점을 디자인하는지, 그것이 비즈니스에 누출되는지, 제품이 자연스럽게 그것을 만든 사람의 연장인지에 대해 논의했습니다.

Chris Murphy: Drew, 그건 정말 좋은 질문이라고 생각합니다. 그리고 그에 대한 대답은 그것에 달려 있다고 생각합니다. 그 사람에 따라 다르고 회사 규모에 따라 다르다고 생각합니다. Hiut Denim을 보고 제가 강의에서 Hiut를 많이 사용한다면, 그것은 한 가지 일을 잘하고 있는 회사의 정말 좋은 예입니다. 그것은 일종의 스트랩라인 청바지입니다. David의 이전... David와 Clare를 보면 파트너 관계이기 때문입니다. David Hieatt와 Clare Hieatt의 이전 회사인 Howies를 보면 그 회사가 너무 크게 성장했고 너무 많은 사람들이 관련되어 있었습니다.

Chris Murphy: 규모가 커지기 시작하면 고객 여정에서 중요한 모든 작은 접점을 주시하기가 매우 어려워지기 시작합니다. 그들이 Howies를 떠났을 때 Howies가 에 의해 사들여졌기 때문에… 그것은 복잡합니다. 인터넷에서 읽어보세요. 그러나 그것은 Timberland였고, Timberland는 사들여졌고, 이 모든 이야기가 있습니다.

Chris Murphy: 지금 그들이 집중하고 있는 것이 청바지라는 것이 정말 흥미로운 것 같아요. 그게 다야 그들은 청바지에 대해 놀랍도록 좋은 이야기를 하고 있습니다. 그들은 또한 모든 것을 정말, 정말 잘 포장하고 있으며, 청바지는 정말 이야기를 위한 수단과 같습니다. 이것은 우리가 COVID의 반대편 끝에서 나올 때 Drew가 더 중요해질 것이라고 생각하는 것입니다. 그 청바지를 만드는 모든 사람들은 적절한 임금을 받고 있습니다. 내가 세상을 바라보는 순간 내가 겪고 있는 문제 중 하나는 모든 사람이 적절한 급여를 받고 있지 않다는 것입니다. 그리고 저는 누군가로서 조금 걱정스럽습니다... 보세요, 저는 51세입니다. 제 아들은 25, 24세입니다 , 25, 그런 것. 끔찍하다. 이 모든 것을 알아야 합니다. 그는 웨딩 포토그래퍼입니다. 그는 1년 조금 넘는 기간 동안 웨딩 포토그래퍼로 일해 왔습니다. 그의 사업은 너무 어려워서 당장 결혼을 하는 사람이 아무도 없기 때문에 완전히 망했습니다. 그는 지원을 받을 충분한 자영업 서적이 없었기 때문에 급여가 없습니다.

Chris Murphy: 그는 균열을 통해 넘어졌고, 균열을 통해 넘어진 다른 많은 사람들이 있습니다. 나는 그것이 디자인 문제라고 주장하고 싶습니다. 우리는 그것을 디자인 문제로 볼 필요가 있습니다. 하지만 제가 COVID와 정부, 그리고 이 모든 것들을 너무 정치적이지 않게 다룬다면 어제 가디언지에서 Matt Hancock의 이웃에 관한 기사를 읽었습니다. 그리고 듣고 있는 사람 중에 영국 사람이 아닌 Matt Hancock은 보건장관. 사업을 하고 있던 그의 이웃은 그에게 문자를 보내며 “이 코로나 사태에 대한 제품을 어떻게 공급해야 합니까?”라고 조언을 구하고 있었습니다. 신문이 부르는 대로, 적절한 사람을 알고 있기 때문에 일자리를 얻는 것처럼 보이는 정부 장관의 친구 친구인 chumocracy에 대해 엄청나게 많은 소문이 있습니다.

Chris Murphy: 저는 우리가 이것의 반대편에 와서 이것을 보게 될 것이라는 느낌이 듭니다. 개인들은 그것을 보고 생각합니다. X 가게에서 파는 이 1파운드 티셔츠의 가격은 얼마입니까?” 어떤 브랜드도 언급하고 싶지 않습니다. 하지만 모든 것은 대가를 치러야 하고, 만들어진 모든 것, 사람들은 그것을 만들기 위해 대가를 치러야 합니다. 사람들이 점점 더 관심을 갖고 있다고 생각합니다. 사람들이 공정하게 지불되고 있습니까?

Drew: GraphQL은 올해의 마지막 전체 에피소드의 주제였습니다. 저는 Eve Porcello와 채팅을 하고 GraphQL이 개발 스택에서 어디에 적합한지 물었습니다.

이브 포첼로: 네. GraphQL은 프론트 엔드와 백엔드 사이에 적합합니다. 따라서 둘 사이의 중간에 있는 일종의 프론트엔드 개발자와 백엔드 개발자에게 많은 이점을 제공합니다. 프론트엔드 개발자라면 프론트엔드의 모든 데이터 요구 사항을 정의할 수 있습니다. 따라서 예를 들어 React 구성 요소의 큰 목록이 있는 경우 쿼리를 작성할 수 있습니다. 그러면 해당 페이지의 데이터를 채우는 데 필요한 모든 필드가 정의됩니다.

Eve Porcello: 이제 백엔드 부분을 사용하면 정말 고유합니다. 다양한 소스에서 많은 데이터를 수집할 수 있기 때문입니다. 그래서 우리는 REST API와 데이터베이스, 그리고 이 모든 다른 장소에 데이터를 가지고 있으며 GraphQL은 우리의 모든 데이터가 있는 곳의 혼란을 실제로 이해할 수 있도록 이 멋진 작은 오케스트레이션 계층을 제공합니다. 따라서 스택 전체에 있는 모든 사람에게 정말 유용합니다.