Andy Bell과 함께하는 스매싱 팟캐스트 에피소드 19: CUBE CSS란?
게시 됨: 2022-03-10오늘은 CUBE CSS에 대해 알아보겠습니다. 그것은 무엇이며 BEM, SMACSS 및 OOCSS와 같은 접근 방식과 어떻게 다릅니까? 나는 그것을 만들기 위해 제작자인 Andy Bell과 이야기를 나누었습니다.
메모 표시
- 큐브 CSS
- 피칼리리
- 처음부터 110개 배우기 - 40% 절약!
- 트위터의 Andy Bell과 Piccalilli
참고 : Smashing Podcast 청취자는 SMASHINGPOD 코드를 사용하여 Andy의 Learn SMASHINGPOD From Scratch 과정을 무려 40%나 절약할 수 있습니다.
주간 업데이트
- "Vitruvius가 웹 디자인에 대해 가르쳐 줄 수 있는 것"
프레데릭 오브라이언 - "SWR 소개: 원격 데이터 가져오기를 위한 React Hooks"
이브라히마 은도 - "웹 디자이너가 레스토랑을 디지털 경험으로 전환하는 데 도움이 되는 방법"
수잔 스카카 - "Jest로 React 애플리케이션을 테스트하기 위한 실용적인 가이드"
Adeneye David Abiodun - "Django 하이라이트: 정적 자산 및 미디어 파일 랭글링(4부)"
필립 키엘리
성적 증명서
Drew McLellan: 그는 영국에 기반을 둔 교육자이자 프리랜스 웹 디자이너이며 10년 넘게 디자이너 웹 업계에서 일했습니다. 그 당시 그는 Harley-Davidson, BSkyB, Unilever, Oracle 및 NHS와 같은 세계에서 가장 큰 조직과 함께 일했습니다. Heydon Pickering과 함께 Every Layout의 공동 저자이자 짧고 재미있는 챌린지를 통해 프론트엔드 개발 모범 사례를 가르치는 데 중점을 둔 Front-End Challenges Club을 운영하고 있습니다.
Drew: 그의 최근 벤처 사업은 웹사이트 뉴스레터인 Piccalilli입니다. 이 뉴스레터에는 프론트엔드 개발자 및 디자이너의 레벨을 높이는 데 도움이 되는 튜토리얼과 코스가 포함되어 있습니다. 그래서 우리는 그가 경험 많은 개발자이자 교육자라는 것을 알고 있지만, 그가 Crufts에서 팬더와 경쟁할 수 있는 첫 번째 사람이라는 것을 알고 계셨습니까?
드류: 내 스매싱 친구들, 환영합니다, 앤디 벨. 안녕, 앤디, 잘 지내?
Andy Bell: 굉장합니다. 감사합니다. 잘 지내고 있나요?
드류: 저는 아주 좋습니다. 정말 감사합니다. 이제 저는 오늘 귀하가 최근 몇 년 동안 개발한 CSS 방법론에 대해 Piccalilli 사이트에 게시한 내용에 대해 이야기하고 싶었습니다. 우선, CSS 방법론이 의미하는 바를 살펴봐야 할 것 같습니다. CSS 방법론은 사람마다 의미가 다를 수 있기 때문입니다. 그래서 CSS 방법론을 생각할 때 그것은 당신에게 무엇입니까?
Andy: 처음부터 좋은, 어려운 질문입니다, Drew. 감사합니다, 감사합니다!
드류: 환영합니다!
Andy: 까다로운 일입니다. 그래서 문맥상 저는 BEM을 오랫동안 사용해 왔으며 그것이 Block Element Modifier입니다. 그것은 오랫동안 주변에 있었다. 내가 CSS 방법론을 보는 방식은 프레임워크가 아니라 조직 구조라는 것입니다. 그것이 내가 그것을 보는 방법입니다. 거의 과정 같아요. CSS로 해결해야 하는 문제가 있고 방법론을 사용하여 문제를 해결하고 상황을 예측 가능하고 체계적으로 유지하는 것과 같습니다. BEM은 엄청난 성공을 거두었기 때문에 전설적입니다.
Andy: 그러면 스타일 구성 요소와 같은 것들을 거의 한정할 수 있습니다. 프레임워크가 조금 더 얽혀 있기는 하지만 방법론 지향적이라고 거의 말할 수 있지만 여전히 사물을 작은 분자로 분해하는 방법론입니다. 그래서 본질적으로 그것이 제가 CUBE CSS로도 하려고 하는 것입니다. 사고 구조, 나는 그것을 설명했다고 생각합니다.
Drew: CSS를 설계하고 작성하는 방법에 대한 프로세스의 응용 프로그램이며 도구나 다른 종류의 기술을 기반으로 하는 것이 아니라 일종의 작업 흐름입니다. 그래서 다양한 접근 방식이 존재합니다. BEM을 언급하셨습니다. SMACSS, OOCSS, Atomic CSS가 있습니다. 그리고 ABEM과 같은 특이한 러브차일드 접근 방식이 있습니다. 그거 봤어?
앤디: 네.
Drew: 왜 당신의 것을 출판합니까?
앤디: 네, 네. 왜 직접 만드세요? 아주 좋은 질문입니다. 저를 잘 아시는 분들은 아시겠지만 제가 파도를 거슬러 항해하는 것을 좋아하는 것 같습니다. 그것은 주로 내가 다양한 팀에서 다양한 프로젝트를 많이 하는 경향이 있기 때문입니다. 따라서 기존 개발자와 함께 BEM으로 작업하는 것은 매우 어렵다는 것을 알게 되었습니다. 그들은 CSS가 무엇인지에 대해 CSS를 사용하는 데 익숙하기 때문입니다. .
Andy: 반대로 구조화되지 않은 방법론은 구조와 조직, 작은 구성 요소를 좋아하기 때문에 JS와 같은 프로그래머와 함께 작업하기가 더 어렵습니다. 이는 그들이 작업하는 언어로 작업하는 것을 이해할 수 있기 때문입니다.
Andy: 그래서 저는 다양한 유형의 사람들과 일하고 있는 이러한 위치에 있다는 것을 깨달았습니다. 하나의 방법론이 제대로 작동하지 않는 다양한 유형의 프로젝트였습니다. 수년에 걸쳐 저는 상황이 어떻게 돌아가는지에 대한 아이디어를 가지고 놀았고, 그 다음에는 저와 Heydon이 한 작업인 Every Layout이 있습니다. 이 작업에서 가장 큰 부분을 차지하는 부분이 구성 부분인 C입니다. 그리고 나서 저는 지난 6개월 동안 매우 빠르게 진화시켰습니다.
Andy: 내가 그것에 관해 기사를 쓴 유일한 이유는 내가 이 과정을 하고 있었고 사람들이 이해할 수 있도록 추가 자료를 작성하는 것이 더 낫다고 생각했기 때문입니다. 그래서 우리는 아직 방법론을 끝내지 못했을 것입니다, Drew.
Drew: 그래서 당신이 모은 강의 자료는 실제로 CUBE CSS를 방법론으로 사용하는 것입니까?
앤디: 네. 따라서 코스의 50%는 무제한 코스임에도 불구하고 실제로는 프론트 엔드입니다. 우리가 프론트엔드를 구축하는 방식에 너무 깊이 얽혀 있어서 "아, 그런데, 이것이 내가 멋진 CSS를 작성하는 방법입니다"라고 말하고는 그냥 놔둘 수 없었습니다. 나는 사람들이 세부 사항에 들어가기를 좋아한다는 것을 알고 있으므로 내가 할 일은 정말 길고 매우 상세한 이 게시물을 작성한 다음 누군가가 기술을 배우고 우리가 하는 일을 진정으로 이해하고 싶어한다면 , 그러면 그들은 할 수 있고 나머지는 거기에서 나옵니다. 그리고 오늘 여기, Drew가 앉아서 그것에 대해 이야기하고 있습니다.
Drew: 누군가가 이미 BEM을 이해하고 있고 이미 BEM을 사용하고 있다면 예를 들어 이것이 아마도 가장 널리 채택된 방법론 중 하나일 것입니다. 그렇지 않습니까? 따라서 그들이 이미 BEM에 대해 이해하고 있고 CUBE에 올 예정이라면 채택하기 쉬운 것입니까? 많은 유사점이 있습니까, 아니면 완전히 다른가요?
앤디: 네. BEM에서 CUBE로의 전환은 아마도 부드러운 전환일 것입니다. 특히 CUBE용 CSS를 계속 작성하는 방식을 선호합니다. 그래서 대부분의 일들이 더 높은 수준에서 일어나고 있습니다. 따라서 캐스케이드 수준에서 발생하고 유틸리티를 사용하여 많은 작업을 수행하는 전역 CSS에서 발생합니다. 그러나 그 핵심을 살펴보면 BEM과 매우 유사한 구성 요소, 블록 및 요소입니다. BEM과 약간 다른 유일한 점은 수정자를 사용하는 대신 예외라고 하는 것을 대신 사용한다는 것입니다. CSS 클래스를 사용하는 대신 데이터 속성으로 전환합니다. 수정자가 있어야 하는 예외입니다.
Andy: 내가 BEM에서 멀어진 이유 중 하나는 특히 디자인 시스템에서 BEM으로 작업하는 방식을 찾았기 때문입니다. 수정자가 지배적이어서 문제가 되었습니다. 이 시점에서 내 블록의 역할은? 정기적으로 인식할 수 없는 지점까지 수정하는 경우 이 방법론이 작동해야 하는 방식으로 계속 작동하기 때문입니까?
Andy: 그러면 전체 디자인 토큰이 있습니다. Jina가 Lightning Design System으로 수행한 작업으로 우리 모두가 지금 채택하기 시작했습니다. 유틸리티 클래스 항목은 실제로 그 접근 방식으로 이해되기 시작했습니다. 그래서 나는 다른 사람들의 일에 대해 내가 좋아하는 모든 것을 부수고 대신 내 일에 끼웠습니다.
Drew: 통제 불능 상태가 되는 일종의 수정자 접근 방식인 BEM에 대해 말씀하셨습니다. CUBE가 해결하려는 BEM의 주요 문제점 중 하나였습니까?
앤디: 네, 절대적으로요. BEM을 사용한 수정자 접근 방식이 마음에 듭니다. 이치에 맞습니다. 내가 BEM에 대해 좋아하는 것은 내가 여전히 하고 있는 것, 요소에 대한 이중 밑줄이고 수정자에 대한 이중 대시가 있다는 것입니다. 나는 물건을 정리하는 그런 방식을 좋아한다. 그것은 단지 좋은 경우였습니다. 음, 실제로 유틸리티 클래스와 다른 비트로 설명할 수 있는 많은 수정자...
Andy: 기사에서 사용한 예는 카드가 있다고 상상하고 카드를 뒤집으면 내용이 이미지 앞에 나타납니다. 그래서 그것이 의미가 있습니다. display: flex를 보고 그 순서를 반대로 하면 됩니다. 그것은 의미가 있습니다. 카드의 기본 상태의 예외이기 때문에 예외 규칙을 갖는 것입니다. 그것이 제가 보고 싶은 방식입니다. 이는 해당 구성 요소의 영향을 받는 상태와 같으며 예외이며 이는 의미가 있습니다.
Andy: 내가 최근에 한 많은 작업, 반응형 JavaScript가 있는 최신 프론트 엔드 스택에는 상태 변경이 많이 있으며 CSS와 JavaScript 간에 적절하게 처리하는 것이 합리적입니다. 좋든 싫든 서로 더 얽혀 있습니다. 그것은 그들에게 공통된 언어입니다. 당신이 내 얼굴에서 볼 수 있듯이, 아주 많지는 않지만 거기에 있습니다. "사실, 나는 최근에 react로 꽤 많이 일해왔기 때문에 나는 그 반대다."라고 생각할 것입니다. 그래서 저도 그렇게 봅니다.
Drew: 그럼 CUBE로 들어가 봅시다. 따라서 CUBE는 Composition Utility Block Exception의 약자입니다. 맞나요?
앤디: 네. 바로 그 사람입니다.
드류: 도대체 그게 무슨 뜻이죠?
Andy: 오, 친구, 전에 들었어야 했어요! 나는 작년에 이야기를 하고 있었다. 저는 이야기를 했고 확장 가능한 CSS를 사용하여 단순하게 유지라고 했고 거기에서 캐스케이드 블록 요소 유틸리티 토큰인 CBEUT라는 이전 버전을 소개했습니다. 쓰레기였다. 나는 그 이름이 싫었다. 작년에 이 강연을 몇 번 했었는데 그 이름이 정말 마음에 들지 않았습니다. 그러다가 올해 이 일을 하게 되었을 때, “이것이 실제로 무엇인지, 그리고 그것이 무엇이라고 불리는지 정말 생각해볼 필요가 있다.”라고 생각했습니다. CUBE가 좀 덜 쓰레기인 것 같아요. 그것이 내가 그것을 설명할 수 있는 가장 좋은 방법이라고 생각합니다.
Andy: 하지만 이름은 항상 이런 것들에 대해 쓰레기입니다. 그렇지 않나요? 내 말은, BEM처럼, 그 이름이 얼마나 쓰레기 같습니까! 하지만 우리는 모두 그렇게 합니다. Jamstack을 보세요. 역시 끔찍한 이름이죠?
드류: 내 입술이 봉인됐어!
Andy: 당신의 상사는 "뭐?"라고 말할 것입니다. 사실이야 우리 업계에서는 그렇지 않습니다.
Drew: 많은 CSS 방법론이 CSS의 일부 기능(예: 캐스케이드)을 해결하려고 시도하는 것 같습니다. 내가 읽은 바로는 CUBE가 CSS의 이러한 종류의 기능과 속성을 활용하려고 한다는 것입니다.
앤디: 네. 그것에 대한 좋은 비유는 Sass와 같은 SCSS가 자연 CSS 언어의 확장이라는 것입니다. 그렇죠? 당신은 여전히 CSS에서 꽤 옳습니다. 그래서 CUBE CSS가 그렇습니다. 따라서 CSS의 확장입니다. 그래서 우리는 여전히 CSS를 작성해야 합니다. CSS는… 솔직히 말해서, 그것이 쓰여져야 하는 방식은 이름에서 알 수 있듯이 Cascading Style Sheets입니다. 제가 발견한 것은 미시적 최적화 수준까지 내려갔기 때문입니다. 나는 최근에 많은 사람들이 아래로 내려가는 것을 보는 길을 걸어왔습니다. 그리고 저는 이것을 기사에서도 언급했습니다. 제가 볼 수 있는 곳은… 최근에 그것에 대한 몇 가지 증거가 있습니다. 나는 사람들이 스페이서 구성요소와 그런 것들을 만드는 것을 목격했고, 그 문제를 이해하고 있습니다. 저도 그런 상황에 있었습니다.
Andy: 내가 수정한 방법은 드릴다운하고 미세 최적화를 시도하는 대신 구성 요소가 얼마나 작은지 중요하지 않기 때문에 실제로 구성 수준에서 생각하기 시작했습니다. 페이지가 되려면 조회수가 될 것입니다. 당신은 그것을 피할 수 없습니다, 그렇게 될 것입니다. 따라서 "맞아, 이 레이아웃을 하려면 이 작은 도우미가 필요해"라고 말하려고 하는 대신 "맞습니다. 연락처 페이지 보기 또는 제품 페이지 보기가 있습니다. 이것이 골격 레이아웃 구성입니다. 그런 다음 그 안에 내가 원하는 모든 구성 요소를 넣을 수 있습니다.” 이제 Grid 및 Flexbox와 같은 기능이 있어 훨씬 더 쉽게 달성할 수 있으며 기본적으로 골격 레이아웃 내부에 원하는 것을 넣을 수 있습니다. 상관 없습니다. 그런 다음 구성 요소는 그 시점에서 컨테이너 쿼리를 사용하거나 사용하지 않고 원하는 대로 작동해야 합니다.
Drew: 이것은 CUBE의 구성 부분으로, 더 많은 매크로 수준에서 구성 요소를 구성하여 사이트 또는 앱에 대해 생성해야 하는 종류의 페이지를 생성하는 뷰로 구성할 수 있는 방법을 살펴봅니다. 또는 당신은 무엇을 가지고 있습니다.
Andy: 본질적으로 규칙을 만드는 것입니다. 안내와 같습니다. 무엇인가에 대한 지침을 얻으려고 합니다. 이것은 엄격한 규칙과 같은 것이 아닙니다. 이것은 해야 합니다, 저것은 해야 합니다. 그것은 본질적으로 이 방법론을 사용하여 브라우저로 하는 일입니다. 즉, 브라우저가 아무 것도 하도록 강요하지 않는다는 것입니다. "이상적으로는 이렇게 배치할 수 있다면 좋겠지만 그렇지 않을 수도 있다는 점을 이해합니다. 그래서 여기에 우리가 작업할 수 있는 몇 가지 경계와 몇 가지 상위 및 하위 수준이 있습니다. 할 수 있는 걸 하고 응원해." 그런 다음 일부 구성 요소를 척하고 기능을 수행하도록 합니다. 당신은 그것이 쓰레기처럼 보이지 않도록 거기에 충분한 제어를 추가합니다.
Andy: 좋은 예는... 우리는 스위처라고 하는 모든 레이아웃에서 레이아웃을 수행합니다. 기본적으로 특정 지점까지 항목을 인라인합니다. 계산은 서로의 상단에 얼마나 넓게 쌓아야 하는지를 계산합니다. . 그러나 인라인과 블록에 여백을 추가하기 때문에 상태에 관계없이 작동하지만 여전히 괜찮아 보입니다. 이것이 바로 우리가 브라우저에 "이 3개의 열 그리드를 레이어링해야 합니다."라고 말하지 않는다는 것입니다. "만약 당신이 3개의 기둥 그리드를 겹칠 수 있다면 그렇게 하십시오. 그렇지 않으면 스택과 공간을 대신하십시오.” 그래서 그것은 브라우저가 실제로 그 일을 하도록 하는 일종의 방법론입니다.
Drew: 지난 몇 년 동안 CSS를 위해 나온 다양한 접근 방식은 모든 것을 구성 요소처럼 처리하는 구성 요소 수준에 중점을 두었습니다. CUBE는 그 구성 요소 측면을 너무 얕잡아 보지 않고 단순히 레이아웃이 또 다른 구성 요소라고 말하는 것이 아니라 해당 구성 요소를 가져와 더 큰 레이아웃으로 구성하는 것 이상의 추가 개념을 제공합니다.
Andy: 네, 좋은 지적입니다. 네. 구성 요소에 대해 말할 수 있는 것은 특히 현대 프론트 엔드 항목에서 중요하다는 것입니다. 우리는 많은 구성 요소, 시스템 작업을 수행합니다. 그러나 내가 구성 요소를 보는 방식은 이미 수행된 것을 확장하는 규칙 모음입니다.
Andy: 이 기사에서 요점은 블록 수준으로 내려가면 대부분의 스타일링이 실제로 완료되었으며 실제로 구성 요소가 하는 일은 Is에 점을 찍고 T를 교차하는 것입니다. "맞아, 이 맥락에서..." 그래서 예를 들어 카드의 경우 이미지의 최소 높이가 X가 되도록 만들고 여기에 약간의 여백을 추가합니다. 이것 저것 하고 저것을 하십시오. 여기에 버튼을 놓으십시오. CSS의 나머지 부분에서 이미 상속된 것 위에 추가 규칙의 일종입니다. 그것을 설명하는 가장 좋은 방법이 아닐까 생각합니다.
Andy: 반면 BEM에서는 구성 요소가 진실의 근원입니다. 요소에 해당 클래스를 배치할 때까지는 해당 시점에 아무 것도 적용되지 않으며 해당 메서드가 작동합니다. 나는 그렇게 함으로써 더 많은 CSS를 작성하고 내가 좋아하지 않는 반복적인 CSS를 작성했다는 것을 발견했습니다.
Drew: 타이포그래피, 색상, 세로 리듬, 간격 등 모든 것이 이 모델의 구성 아이디어의 일부라고 생각하십니까?
앤디: 네. 글로벌 CSS에서는 그렇습니다. 특히 수직 리듬과 흐름. 우리는 24가지 방법으로 이에 대한 기사를 작성했습니다. 몇 년 전만 해도 흐름과 리듬 구성요소였습니다. 이것은 본질적으로 lobotomized owl 선택기를 사용하는 기본 구성 요소를 설정하는 이 접근 방식에서도 일종의 추상화였습니다. 라디오에서 그것을 어떻게 설명해야 할지 모르겠지만, 우리는 그렇게 할 것입니다. 우리는 Heydon 기사 또는 무언가에 대한 쇼 노트에 넣을 것이라고 생각합니다. 그러나 본질적으로 자식 요소를 선택합니다. 죄송합니다. 형제 요소입니다.
Andy: "그렇습니다. X 요소 다음에 오는 모든 요소에는 CSS 비용 및 속성 값의 마진 상단이 있습니다." 그리고 그 장점은 구성 컨텍스트에서도 해당 CSS 사용자 정의 속성 값을 설정할 수 있다는 것입니다. 따라서 이렇게 말할 수 있습니다. "맞습니다. 이 구성 요소에서 이동 중에 흐름이 있는 경우 흐름 공간을 실제로 2렘으로 설정할 것입니다. 우리는 멋지고 두툼한 넓은 공간을 원하기 때문입니다." 그런 다음 다른 하나에서 "사실, 나는 플로우 공간이 팽팽하기를 원하기 때문에 반 렘이 되기를 원합니다."라고 말할 수 있습니다. 이것은 모두 일어나고 있으며, 모든 제어는 더 높은 수준에서 오고, 그리고 나서 당신이 하는 일은 매번 재발명하고 같은 것을 계속해서 재발명하는 대신 상황에 맞는 재정의를 추가하는 것입니다.
Drew: C, 작곡입니다. 다음으로 유틸리티인 U가 있습니다. 그렇다면 유틸리티는 무엇을 의미합니까?
Andy: 그래서 하나의 작업을 수행하는 클래스이고, 정말 잘합니다. 그것은 속성의 추상적인 디자인 토큰의 구현일 수 있습니다. 일반적으로 색상이나 타이포그래피 스타일, 크기 및 규칙이 있습니다. 아이디어는 이를 적용하는 유틸리티 클래스를 생성하는 것입니다. 따라서 기본 색상과 같은 배경 기본을 적용한 다음 텍스트 색상인 기본 색상을 적용하는 유틸리티가 있습니다. 그런 다음 여백 패딩 및 이러한 모든 종류의 간격 토큰을 생성할 수 있습니다. 그들은 한 가지 일만 합니다. 그들은 하나의 간격 규칙, 하나의 색상 규칙을 추가하기만 하면 됩니다.
Andy: 하지만 다른 유틸리티도 있습니다. 좋은 예는 래퍼 유틸리티입니다. 그것이 할 일은 요소에 최대 너비를 설정한 다음 왼쪽 및 오른쪽 자동 여백을 넣어 가운데에 배치하는 것입니다. 그래서 그것은 단지 하나의 직업을 가지고 있고, 그것은 단지 그것을 효율적이고 잘 하고 있습니다.
Andy: 그래서 당신은 당신의 글로벌 스타일을 가지고 있고, 많은 타이포그래피 설정과 많은 바닥 공간을 가졌습니다. 그러면 컴포지션이 컨텍스트와 레이아웃을 제공합니다. 그런 다음 유틸리티는 요소에 토큰을 직접 적용하여 필요한 스타일을 부여합니다. 예를 들어 제목과 같이 "나는 이것이 이 크기가 되기를 원하고 이 리드를 갖기를 원하며 이 측정값을 갖기를 원합니다."라고 말합니다. 그런 다음 그 시점에서... 이것이 내가 블록에 대해 말한 것입니다... 스택 아래로 더 내려가면 해당 지점에서 이미 대부분의 작업을 완료한 것입니다.
Andy: 그래서 그들은 매우 효율적인 작업 방식을 제공합니다. 그리고 HTML도 파이프를 따라 내려가기 때문에 워크로드를 CSS가 아닌 HTML로 추상화하는 것도 정말 좋은 일이라는 것을 알게 되었습니다. 예전에는 "오, 관심사의 분리"와 같은 구식 스타일과 같은 유틸리티 수업에 실제로 참여했지만 실제로는 정말 괜찮은 작업 방식이라고 생각합니다. 나는 실제로 Tailwind CSS를 좋아한다고 기사에서 언급했습니다. 나는 그것이 효과가 있다고 생각하고 정말로 빨리 무언가를 출력할 수 있기 때문에 제품 타이핑에 그것을 사용하는 것을 정말로 좋아합니다. 그러나 Tailwind는 그것이 너무 지나치다고 생각하지만, 클래스에 단일 규칙을 적용하는 것 이상일 때 비를 내리는 것을 좋아합니다. 그게 다야. 당신은?
Drew: 네, 기사에서 디자인 토큰에 대해 많이 말씀하셨는데요. 이는 우리가 에피소드 3에서 Jina Anne과 함께한 Smashing Podcast에서 이야기한 것입니다. 그래서 디자인 토큰은 정말 기본적인 측면인 것 같습니다.
앤디: 네. 오, 맙소사. 진아가 라이트닝 디자인 시스템 작업을 하던 시절이 너무 생생하게 기억난다. 당시 내가 디자인 시스템이나 디자인 시스템과 유사한 무언가를 구축하고 있었고 경영진 승인을 받기 위해 고군분투했기 때문이다. 라이트닝 디자인 시스템이 나왔을 때 말 그대로 링크를 연결해서 보냈고 “이것이 우리가 하는 일입니다. 디자인 시스템을 구축하고 있습니다. 이것이 Salesforce가 현재 사용하고 있는 것입니다.” 당시 그녀의 일이 실제로 물건을 꺼내는 데 도움이 되었던 것을 기억합니다.
Andy: 디자인 토큰은 이러한 규칙을 적용하는 정말 좋은 방법이라는 점에서 항상 저를 사로잡았습니다. 저는 직업상 디자이너이기 때문에 그 조직과 단일 소스 소스를 구성하고 생성하는 능력이 디지털 디자인, 특히 Adobe에서는 실제로 경험하지 못한 것이기 때문에 정말 유용하다는 것을 알 수 있습니다. Photoshop과 같은 작업을 하는 시대에 우리에게는 그런 사치가 없었습니다. Pantone Book과 함께 인쇄되어 있었지만 상점 전체에 임의의 16진수 코드가 있는 디지털로 인쇄되어 있지 않았습니다.
Andy: 정말 좋습니다. 나는 그 수준의 통제를 좋아한다. 사실, 저는 그것이 창의성에 도움이 된다고 생각합니다. 왜냐하면 여러분은 더 이상 중요하지 않은 것에 대해 생각하지 않고 그것으로 무엇을 하고 있는지에 대해 생각하기 때문입니다.
Drew: 이러한 디자인 토큰의 구현이 특히 접근 방식과 관련하여 중요합니까? 항상 CSS 사용자 정의 속성입니까?
Andy: 그게 CUBE에서 정말 중요한 포인트인 것 같아요. 내가 가진 응답 중 일부는 사람들이 이것으로 약간 어려움을 겪었습니다. 기술에 대한 언급은 전혀 없습니다. 일관된 유일한 기술은 CSS입니다. 원하는 대로 할 수 있습니다. 사람들이 지금 하고 있는 CSS 및 JS 작업으로 이 모든 작업을 수행할 수도 있고 Vanilla CSS만으로 수행할 수도 있습니다. Sass와 함께라면 가능합니다. 사스와 함께 해요. 덜, 그게 당신이 아직도하고있는 일이라면. 사용 가능한 모든 기술, CSS 이후, 이 모든 것. 하고 싶은 대로 하셔도 상관없습니다.
Andy: 그런 종류의 구성을 따르면 괜찮을 것입니다. 이것이 바로 그 아이디어입니다. 그것은 매우 느슨하고 일부 방법론이 엄격하지 않습니다. 저는 특히 BEM에서 그것을 보았습니다. 사람들은 더 이상 문제를 해결하지도 못하는 것처럼 BEM의 원칙에 정말 깊이 빠져들었습니다. 융통성이 있어야 한다고 생각합니다. 작년에 이 강연에서 말했습니다. "총에 너무 집착하면 특정 경로를 따라가려고 하고 더 이상 작동하지 않는다는 것을 알기 때문에 장기적으로 실제로 문제를 일으킬 수 있습니다." 당신은 항상 유연해야 하고 시스템에 편지에 따라 작업하기보다 시스템과 함께 작업해야 합니다.
Drew: 그래서 B, B는 블록입니다. 블록 수준으로 내려가면 대부분의 모든 것이 제자리에 있어야 하고 블록 수준 스타일 지정은 특정 구성 요소의 실제 세부 사항에만 관심이 있다는 아이디어에 대해 이야기했습니다. 일반적으로 블록의 개념은 사람들에게 친숙한 것과 유사한가?
Andy: 아, 물론이죠. 따라서 BEM 구성 요소를 상상하고 모든 시각적 요소를 제거하면 기본적으로 블록만 남게 됩니다. 이것이 내가 이 방법론에 대해 처음 생각하기 시작할 때 분명히 설명하기 위해 고심했던 것입니다. 블록은 실제로 실제로 C입니다. 컴포지션입니다. 하지만 재귀 영역에 들어가고 사람들의 두뇌가 폭발할 것 같아서 정말 어렵습니다. 그러나 실제로 그것이 블록이라는 것입니다. 실제로는 또 다른 구성 레이어이지만 일종의 엄격한 컨텍스트에 가깝습니다. 예를 들어 카드, 버튼, 회전 목마, 여전히 하고 싶은 일이라면 그 모든 종류의 것들입니다.
Andy: 그것은 특정한 것, 구성요소와 같습니다. 그런 다음 그 안에서 당신이 따라야 할 특정한 규칙을 설정하고 나머지는 정말로 무시합니다. 그래서 당신은 그렇지 않습니다... 블록에 토큰을 적용할 수도 있고 저는 그렇게 합니다. 여전히, 하지만 실제로는 더 레이아웃 지향적이고, 내가 그들과 함께 작업하는 한, 또는 적어도 토큰을 가져 와서 버튼 호버 상태와 같은 특정 방식으로 적용하는 한 블록입니다. 따라서 실제로 당신의 블록은 당신이 그들에게 도달할 때까지 작아야 하고, 그들은 실제로 많은 일을 하지 않아야 합니다.
Drew: 하이퍼링크만큼 작을 수 있습니다.
앤디: 네.
Drew: 하지만 다른 블록의 복합 모음일 수도 있습니다.
앤디: 네. 일종의 모듈처럼. 당신은 확실히 그렇게 할 수 있습니다. 다시 말하지만, 그것은 일종의 구성적 측면으로 돌아가서 그 안에 무엇이 들어가든 상관없어야 한다는 것입니다. 그 좋은 예는 카드와 같습니다. 따라서 카드의 내용은 예를 들어 제목, 요약 및 버튼과 같습니다. 이 세 가지 요소를 구체적으로 타겟팅해서는 안 됩니다. 당신은 "이봐, 무슨 일이든지 콘텐츠에서 발견되고 거기에 흐름 규칙이 있고 일종의 구성 레이아웃 규칙이 있는 것"이라고 말해야 합니다. 그러면 거기에 무엇을 넣어도 문제가 되지 않습니다. 해당 콘텐츠에 이미지를 넣고 싶다고 결정할 수 있으며, 제대로 작동하고 보기에 좋아야 합니다.
Andy: 이것이 CSS 작업의 핵심입니다. CSS로 작업하는 것은 매우 관대한 방법입니다. 당신은 덜 경직되어 당신의 삶을 훨씬 더 쉽게 만들고 있습니다. 왜냐하면 물건이 우연히 무언가에서 발견될 때 당신이 사물에 대해 더 구체적이라면 할 수 있는 것처럼 끔찍해 보이지 않기 때문입니다. 설립하다.
Drew: 내 CSS에 대해 많은 용서가 필요합니다!
앤디: 알고 있어요!
드류: 건배! 이것이 B입니다. 마지막 것은 E입니다. E는 예외입니다. 이제 우리는 오류 메시지에 대해 이야기하는 것이 아닙니다. 그렇지 않습니까?
앤디: 아니요. 일종의-
Drew: JavaScript 예외에 대해 이야기하는 것이 아닙니다.
앤디: 네, 네. 이 시점에서 그런 것이 없어야 합니다. 어쨌든 그렇지 않기를 바랍니다. 그렇지 않으면 그 시점에서 당신은 정말로 숲에 있습니다. 내가 당신을 도울 수 있을 것이라고 생각하지 않습니다! 이것의 전체 아이디어는... 그래서 당신은 블록으로 컨텍스트를 만들었습니다. 그리고 예외는 정확히 말하자면 규칙에 대한 예외와 같습니다. 카드를 뒤집거나 고스트 버튼일 수 있습니다. 테두리와 투명한 배경이 있는 버튼을 알고 계십니까? 버튼에 단색 배경색이 있고 레이블 색상이 있을 수 있으므로 예외입니다. 그래서 그것은 일종의 뚜렷한 변화 상태를 만들고 있습니다.
Andy: 클래스 대신 데이터 속성을 사용하여 이 작업을 수행하는 이유와 그 이유는 a) 구분이 있는 것이 좋다고 생각하기 때문입니다. 따라서 많은 HTML을 스캔할 때 데이터를 볼 수 있고 하이픈을 추가하면 "맞아요. 이 요소에서 뭔가가 확실히 변경되었습니다."라고 생각할 수 있습니다. 다른 점은 JavaScript가 해당 상태에 액세스할 수 있도록 하는 것이 매우 좋다는 것입니다. 그 반대도 마찬가지입니다. 그래서 저는 JavaScript에서 데이터 속성으로 상태를 적용하는 것을 정말 좋아합니다. 나는 그것이 본질적으로 일종의 커뮤니케이션 레이어라고 생각합니다. 그들 사이의 조화가 정말 잘 작동하는 것 같습니다.
Andy: 좋은 예는 상태 메시지가 있고 JavaScript가 데이터 상태를 성공, 오류 또는 정보 등으로 추가한다고 가정해 보겠습니다. 그런 다음 CSS의 예외 스타일을 사용하여 연결할 수 있습니다. 따라서 상태 구성 요소의 예외이며 기본 상태에 반하는 것입니다. 따라서 작업을 수행하는 데 정말 편리한 방법입니다. 양쪽 끝에서 예측 가능합니다. CSS 끝에서 예측 가능하고 JavaScript 끝에서도 예측 가능합니다.
Drew: 클래스 이름이 제공하지 않는 속성과 값이 있다는 것은 꽤 좋은 일이라고 생각합니다. 따라서 상태와 같은 것을 원하고 성공 또는 실패 또는 경고가 될 수 있는 경우 해당 상태 속성을 구체적으로 지정하고 해당 값을 뒤집을 수 있습니다. 반면에 클래스 이름의 긴 목록이 있는 경우, 예를 들어 JavaScript에서 이를 조작하는 경우 각 클래스 이름을 살펴보고 거기에 다음과 같은 비즈니스 로직을 추가해야 합니다. 이 중 하나"라고 말하고 해당 클래스 중 두 개를 동일한 요소에 적용하면 어떻게 될까요? 데이터 속성으로 얻을 수 없으며 하나의 값만 있습니다.
앤디: 네. 좋은 표현이네요, 네. 그렇게 일하는 것이 매우 도움이 됩니다.
드류: 꽤 흥미롭네요. 나는 그 접근 방식을 취하는 다른 방법론을 본 적이 없다고 생각합니다. 그게 CUBE만의 독특한 건가요?
앤디: 그럴 수도 있어요. 내가 해야 할 다른 일에는 별로 관심을 두지 않는다. 다른 누군가가 아마 그렇게 하고 있을 것입니다. 지금 말씀드리자면, 가장 논란이 된 부분입니다. 어떤 사람들은 데이터 속성을 사용하는 아이디어를 정말로 좋아하지 않았습니다. 문제는 또한 내가 대응하는 방식은 원하는 대로 하라는 것입니다. 우리는 특정한 방식으로 일을 하라고 말하는 것이 아니라 단지 제안일 뿐입니다. 수정자와 같은 CSS 클래스에 대한 예외를 수행하려면 스스로를 노크하십시오. CUBE 경찰은 당신의 문을 두드리러 오지 않을 것입니다. 정말 괜찮습니다.
Andy: CUBE는 생각하는 것, 구조입니다. 원하는 도구 또는 원하는 기술을 사용하여 원하는 대로 해당 구조를 적용합니다. 일관성을 유지하는 한 그것이 중요합니다.
Drew: 순수한 CUBE 같은 것은 없는 건가요?
Andy: 제가 쓰는 방식은 순수한 CUBE입니다, Drew. 다른 사람들은 모두 가짜일 뿐이고 약한 모방일 뿐입니다.
Drew: 당신을 제외하고 아무도 "그것은 교과서적인 CUBE가 아닙니다."라고 말할 수 없습니다.
앤디: 아니, 그게 다야. 아무도 그것에 대해 이의를 제기할 수 없습니다. 그렇지 않습니까? 그래, 난 그걸로 갈게. 당신에게 약간의 영향력이나 그런 것을 주는 것 같아요.
Drew: CUBE 접근 방식을 다른 방법론과 혼합하여 사용할 수 있습니까? BEM의 비트를 사용할 수 있습니까?
Andy: 네, 그렇게 생각합니다. 나는 그것이 꽤 유명해져서 사람들이 더 많은 일을 원할 것이기 때문에 곧 더 많은 일을 할 것이기 때문에 그것에 대해 조금 생각했습니다. 내가 살펴볼 한 가지는 기존의 것을 CUBE 방법론을 사용하여 접근하는 방법입니다.
Andy: 저울의 반대쪽 끝이 두 개입니다. 사람들이 묻는 좋은 질문은 "이것이 모든 레이아웃과 다른 것들에서 어떻게 작동합니까?"입니다. 저는 기본적으로 모든 레이아웃이 C라고 생각합니다. 모든 레이아웃이 바로 이것이고 구성 레이어입니다. 그런 다음 다른 누군가가 이렇게 물었습니다. 글쎄요, 당신은 그 조각들을 쪼개서 각 레벨에 적용할 수 있습니다. Atomic Design은 세세한 부분까지 이어집니다. 그것은 그것을 사용하는 것으로 추상화하는 것입니다. 맞습니다. 알겠습니다. 저는 이것을 유틸리티에 적용할 수 있습니다. 그래서 분자는 생각합니다. 나는 그것을 유틸리티에 적용할 수 있고, 그것은 당신이 이미 알고 있는 것을 약간 다른 작업 구조로 번역하고 있습니다.
Andy: 정말이지, 많은 면에서 이름이 바뀌었습니다. 저는 여기서 아무 것도 발명하지 않았습니다. 제가 말했듯이 저는 그저 제가 좋아하는 것을 훔쳤을 뿐입니다. 나는 Atomic Design의 일부가 생각되는 방식을 좋아합니다. 정말 스마트한 작업입니다. 그리고 BEM. Harry가 한 것, 역삼각형 CSS, 정말 멋지다고 생각했습니다. 그래서 저는 각각에서 좋아하는 부분에 흠집을 내서 이 다른 하이브리드 접근 방식에 모두 꿰매었습니다. 더 올 것 같아요.
Drew: CUBE 접근 방식을 이미 CSS가 있는 기존 프로젝트에 적용할 수 있습니까? 아니면 새로운 프로젝트를 시작하는 데 정말로 필요한 것입니까?
Andy: 그것은 크게 좌우됩니다. 따라서 부트스트랩 작업이 있고 수천 줄의 사용자 정의 CSS가 있는 경우 이전에 확실히 관여한 적이 있다면 물 한 병으로 불을 끄려고 할 수 있다고 생각합니다. 가리키다. 그러나 예를 들어, 만약 당신이... 예를 들어, 당신이 대략적인 BEM 설정을 가지고 있고 그것이 약간 계층적으로 사라진다면, 당신은 CUBE를 사용하여 리팩토링하고 실제로 그것을 다시 형태로 되돌릴 수 있습니다.
Andy: It depends, the answer to that one. But it's doable, as with everything. If you really want it to work, Drew, you can do it if you want, can't you? The world is our oyster!
Drew: Especially if your BEM site's gone layer-y.
Andy: Yeah. Nothing worse than a layer-y BEM site!
Drew: I've noticed in the examples that you've given… and I've got an eagle eye, I've seen you've been doing this for a while… a lot of your class values in the HTML attribute are wrapped in square brackets.
Andy: Oh, God, yeah. Tell you what, Drew-
Drew: What is that about? 그것은 무엇에 대한 것입니까?
Andy: I'll tell you what, if there's ever one thing that I've done in my whole career that's just been absolutely outrageously controversial… and you follow me on Twitter, you've seen what comes out of my mouth… it's those bloody brackets! My, God! People either love them or hate them. They're Marmite, they are.
Andy: The reason I do them is a grouping mechanism. So if you look at the way that they're structured, the way I do it is, block at the start and then I'll do a utilities after that. Then what I might do is, in between a block group and a utility group, there might be another block class. So a good example of that would be… we'll go back to the card again. But then say that there's a specific block called a CTA, like a call to action. You might have that applied to the card as well, and then your utilities are enforcing the design attributes, so the colors and all that business. So then you've got three groups of stuff.
Andy: When you come to it, if you've got that order in your head each time, you know, okay, right, this first group's blocks. Oh, that's looks like another block. I've got that one. Then it's like, right, they're definitely utility classes. Then what I might even do is, if there's a lot of design token implementation, have that in a separate group. So it's just very clear what each group is doing, and there's a separation inside of the classes there as well. I've found it really helpful. Some people find it incredibly offensive. It's definitely a do it if you want to do it. Definitely you don't have to do it.
Andy: It's quite funny, when I published that article, so many people finished halfway through to ask me, “What is it with these brackets?” I was like, “Did you finish the article? Because there's a big section at the end where it explains exactly what they're doing,” to the point where I actually had to write a bit in the middle of the article of, “If the brackets are essentially doing your head in, click here and I'll skip you all the way down to that explanation bit so you can just read about them.” It can be quite controversial.
Andy: When I've worked on really, really complex front-ends… and we did a little bit of stuff together, didn't we, last year?
드류: 네.
Andy: You've seen the sort of design implementation on that project that we were on. It requires that sort of grouping because there's just so much going on at the time, there's so much different stuff happening. I've just found it really, really useful over the years, and also get lots of questions about it, to the point where I was almost going to write just one page on my website that I could just fire people to to answer the question for them.
Drew: Slash, what's with the brackets?
Andy: Yeah. Slash, brackets. Have you seen that new Hey Email thing that's just come out? They've bought a domain of itsnotatypo.com, just to answer the whole Imbox, like im with an M rather than an in. Basically, I was like, “I think I need to do that,” like, whatswiththebrackets.com, and just do a one-pager about it.
Drew: It strikes me that the approach with brackets actually could be something that might be useful when using things like Tailwind or something that has a lot of classes because that can-
Andy: Yeah. Oh, God, yes.
Drew: You have classes that are addressing your break points and what have you, and then you'll have things that are for layout, things that are for color or type, or what have you. So it might also be a useful way of dealing in situations like that.
Andy: I'd definitely agree with that. A good analogy… not analogy. A good bit of info about Tailwind is that I actually quite like Tailwind. I've used that on very big projects. The one thing that really opened my eyes to Tailwind though was when I saw a junior developer try to work out what was going on, and it was really, really eye-opening because they just didn't have a clue what was happening.
Andy: I think that's one problem I've found with these sort of over-engineered approaches, which I think it's fair to say Tailwind is, is that there's a certain skill level that is required to work with it. I know the industry tends to have an obsession with seniority now, but there's still people that are just getting into the game that we need to accommodate, and I think having stuff that's closer to the language itself is more helpful in those situations because they're probably learning material that is the language as it is. So I think it's just a bit more helpful. Especially having a diverse team of people as well. Just food for thought for everyone.
Drew: People might look at all the different methodologies that are out there and say, “This is evidence that CSS is terrible and broken, that we need… all these problems have to be solved by hacking stuff on top. We need tools to fix bits of CSS. We need strict procedures for how we implement it, just to get it to work.” Should the platform be adapting itself? Do we need new bits of CSS to try and solve these problems or are we all right just hacking around and making up funny acronyms?
Andy: I think the power of CSS, I think, is its flexibility. So if you're going to program CSS, a lot of the knowledge is less of the syntax and more of the workings of a browser and how it works. I think that might be a suggestion, that the problem is that people might not have learnt CSS quite as thoroughly as they thought they might have learnt it, who created these problems. I've seen that in evidence myself. I spotted a spacing mechanism that had been invested, which was very complicated, and I thought, “This person has not learnt what padding is because padding would actually fix this problem for them, understanding how padding works and the box model.” That's not to be snidey about it.
Andy: We work in an industry now that moves at an even faster pace than it has done previously and I think there's a lot less time for people to learn things in detail. But, on that front, I think CSS still does have work to do in terms of the working group, who I think do a bloody good job. A great, shining example of their work was the Grid spec which was just phenomenal. The way that rolled out in pretty much every browser on day one, I thought that was so good.
Andy: But we've got more work to do, I think, and I think maybe the pace might need to increase a little, especially with stuff like container queries, we all love talking about them. Stuff like that I think would help to put CSS in a different light with people, I think. But I think CSS is brilliant, I love it. I've never had a problem with it in lots of years really. I do find some of the solutions a bit odd, but there you go.
Drew: What's the response been like to CUBE since you published the article?
Andy: Mind-blowing. I honestly published it as just supporting material, and that's all I expected it to be, and it's just blown up all over the place. A lot of people have been reading it, asking about it, been really interested about it. There's definitely more to come on it.
Andy: I did say in the article, I said, “Look, if people are actually quite interested in this, I'll expand on this post and actually make some documentation.” I've got bits of documentation dotted around all over the place, but to sort of centralize that, and then I was thinking of doing some workshops and stuff. So there's stuff to go. It's how Every Layout started as well. We both had these scattered ideas about layout and then we sort of merged them together. So something like that, I suppose, will come in the future.
Drew: Are there any downsides that you're aware of to using CUBE? Are there problems that it doesn't attempt to solve?
Andy: Yeah. This accent, Drew, it just won't go way, no matter what I do! In all seriousness, I think CUBE's got as close as I can get to being happy with the front-end, which is saying a lot, I think. You never know, things might change again. This has evolved over more recent years. Give it another five years, I'll probably be struggling with this and trying something else. I think that's the key point, is to just keep working on yourself and working on what you know and how you approach things.
Andy: This definitely won't work for everyone as well, I know that for a fact. I know that from my comments. I don't expect it to work for everyone. I don't expect anything to work for everyone. It's the same with JavaScript stuff: some people like the reactive stuff and some people don't. 그것은 그것이 무엇인지입니다. We're all people at the end of the day, we all have different tastes. It's all about communicating with your teammates at the end of the day, that's the important thing.
Drew: I know you as a very talented designer and developer and you, like many of us, you're just working on real projects all day, every day. But you've recently started publishing on this site, Piccalilli, which is where the CUBE CSS introduction article was. So Piccalilli is kind of a new venture for you, isn't it? 무슨 일이야?
Andy: Very kind of you to say, Drew. You've actually worked with me, so that's high praise. But the Piccalilli thing is an evolution. So I'm a freelancer. I do client work, but I think this has become apparent with the pandemic, that that is not the most sustainable thing in the world in some industries. I think freelancing can be very, very tough, as a developer and designer. It's something that I've been doing it for so long now, 10 years… well, 12 years now actually.
Andy: 저는 조금 다른 일을 하고 제가 가진 지식을 적용하고 실제로 사람들과 공유하는 것을 좋아했습니다. 저는 항상 매우 개방적이고 공유했고, 그것을 공식화하고 싶었습니다. 그래서 저는 튜토리얼을 작성하기 위해 Piccalilli를 만들었습니다. 하지만 주로 제가 만들고 있는 코스용입니다. 바로 고기와 감자입니다. 그리고 뉴스레터가 있습니다. 매주 인터넷에서 찾은 멋진 것들을 공유하기 때문에 사람들이 뉴스레터를 정말 좋아하고 있습니다. 그것이 핵심입니다. 정말 잘 되고 있습니다. 그것이 본질적으로 내가 생각하는 시간이 지남에 따라 점점 더 풀타임으로 일하는 내 자신을 보고 싶은 곳입니다.
Drew: Piccalilli의 다음 계획은 무엇입니까? 나온거 있으신가요?
Andy: 문 열어줘서 고마워, Drew! 이 녹음이 나올 때쯤이면 첫 번째 과정이 시작됩니다: 처음부터 110개 배우기, 여기에서 Gatsby 웹사이트를 구축하는 방법을 배웁니다! 아니요, Eleventy 사이트를 구축하는 방법을 배웁니다. 따라서 완전히 비어 있는 디렉토리로 시작하여 그 안에 아무 것도 없고 비어 있다가 결국에는 이 정말 멋진 에이전시 사이트로 마무리됩니다. 우리는 그 안에서 모든 것을 배웁니다. Eleventy와 함께 실제로 마을에 가는 방법을 배웁니다. 우리는 장소에서 원격 데이터를 가져옵니다. 우리는 CUBE CSS를 사용하여 정말 멋진 프론트엔드를 구축합니다.
Andy: Jamstack에 들어가고 정적 사이트 생성기에 대해 알고 싶거나 멋진 웹사이트를 구축하는 방법에 대해 알고 싶다면 정말 편리한 과정입니다. 현재 우리가 이야기하는 동안 수명이 1인치도 채 되지 않아 편집되고 있습니다. 멋지고 유용하고 유용할 것입니다. 그러나 그것은 지난 몇 년 동안 내가 해온 많은 일의 축적입니다. 그래서 재미있어야 합니다.
Andy: 그러니 사세요. 할인 코드를 입력하고 스매싱포드처럼 40% 할인된 가격에 판매하면 바로 구매할 수 있습니다.
드류: 놀랍군. 우리는 그것을 연결합니다. Piccalilli의 철자를 안정적으로 쓰는 방법을 아직 알아내셨습니까?
Andy: 저는 Chris와 Dave와 함께 ShopTalk Show에 참석했고 그곳에서 "저를 고용하고 싶은 것이 있다면 그것은 생각조차 하지 않고 처음으로 Piccalilli를 손으로 쓰는 것입니다"라고 말했습니다. 그 단어를 너무 많이 썼기 때문에 나는 그것을 마음으로 철자하는 방법을 정확히 알고 있습니다. 따라서 귀하의 질문에 대한 대답은 예입니다.
Drew: 글쎄요, 저는 여전히 힘들어하고 있습니다. 그 정도는 말씀드리겠습니다!
앤디: 어렵다. 오, 세상에. 전적으로 공감합니다. 철자법을 배우는 데 오랜 시간이 걸렸지만 우리 사전에 있는 단어 중 하나입니다. 올해는 꼭 필요한 철자법을 틀리지 않게 쓰려고 노력 중이에요!
Drew: 그래서 저는 CUBE CSS에 대한 모든 것을 배웠습니다. 최근에 무엇을 배웠습니까, Andy?
앤디: 그거 알아? 이것은 당신을 놀라게 할 것입니다, 드류. MySQL은 내가 최근에 배운 것입니다. 따라서 기본적으로 Piccalilli는 완전히 자체 출판됩니다. 그것은 Eleventy 사이트이지만 그 뒤에 API가 있고 그 뒤에 MySQL 데이터베이스가 있습니다. 사람들이 구매한 콘텐츠를 제공하는 것은 꽤 많은 쿼리가 필요합니다. 그래서 저는 실제로 일부 MySQL에 적절하게 투자했습니다. 특히 조인 간의 차이점은 각 조인 유형 간에 차이가 있다는 것을 실제로 깨닫지 못했습니다. 그래서 그것은 정말 유용했고 데이터베이스와 꽤 빠른 상호 작용을 했습니다.
Andy: 저는 Front-End Challenges Club이라는 이 프로그램을 운영했는데 처음 시작했을 때 MySQL이 조악했기 때문에 무너지고 스스로 죽었습니다. 그래서 저는 백엔드 담당자가 아니라 픽셀 푸셔이기 때문에 실제로 그렇게 하는 방법을 배우고 있습니다. 그래서 그것은 확실히 내 소관이 아닙니다. 그것은 당신의 목에 더 가깝습니다. 그렇지 않습니까? 정말 멋진 것 같아요, MySQL. 나는 실제로 그것을 쓰는 것을 정말로 좋아한다. 정말 훌륭하고 교육적인 언어입니다. 그렇지 않나요?
드류: 그렇군요 , 대단합니다. 나는 학교에서 SQL을 배웠다.
앤디: 와!
Drew: 우리는 지금 20년 전처럼 이야기하고 있습니다.
Andy: 그 당시에도 컴퓨터가 있었나요?
드류: 그랬습니다. 우리는 바람을 쐬어야 했다-
Andy: 꼭 손으로 써야 했나?
Drew: 우리는 그들을 감쌀 수밖에 없었습니다! 우리는 했다. 하지만 개발자에게 이것은 시간 테이블을 배우는 것과 비슷하다고 말씀드리고 싶습니다. 약간 귀찮은 일처럼 보이지만 일단 유창해지면 몇 번이고 다시 유용하게 사용되는 것 중 하나입니다.
앤디: 네. 확실히. 실제로 눈에 띄는 차이점도 있습니다. 정말 속도의 차이가 보입니다. Node로 작업하는 것은 정말 빠르기 때문에 정말 좋아하지만 Node와 MySQL은... 흔하지 않은 선택이지만 꽤 좋은 선택이라고 생각합니다. 나는 그것이 정말로, 정말로 잘 작동한다고 생각한다. 그래서 나는 그것에 만족합니다. 아시다시피 저는 PHP 작성을 좋아하지 않습니다. 따라서 그것은 결코 선택 사항이 될 수 없습니다.
Drew: 청취자 여러분, Andy의 소식을 더 듣고 싶다면 hankchizljaw에 있는 Twitter에서 그를 팔로우할 수 있습니다. piccalil.li에서 Piccalilli를 찾을 수 있습니다. 여기에서 CUBE CSS를 설명하는 기사도 찾을 수 있으며 물론 쇼 노트에 있는 모든 링크에 대한 링크도 추가할 것입니다.
Drew: 오늘 함께해주셔서 감사합니다, Andy. 이별의 말은 없었나요?
Andy: 안전을 유지하고 마스크를 착용하십시오.