12월 스크랩

1. PNG Parser Differential (링크)

- 병렬 디코딩 PNG 구현 버그를 이용해서, 애플 기기에서만 다르게 보이는 PNG 이미지 만들기
ㅤ→ 애플 기기에서는 "HELLO APPLE" 과 올드 매킨토시 이미지
ㅤ→ 그외 기기에서는 "HELLO WORLD" 와 구형 IBM PC가 보임
- 간단한 소스 코드를 공개해서 누구나 비슷한 이미지 생성 가능

2. Automa - 크롬 브라우저 자동화 확장 (링크)

- No-code 블록 연결 방식으로 웹 브라우저를 자동화
- 폼 자동 채우기, 반복 작업, 스크린샷 저장, 데이터 스크래핑 등의 다양한 작업 지원
   (웹훅 호출, CSV/JSON Export, 탭/창 열기/닫기, 프레임 선택...)
- 원하는 시간에 스케줄링 가능

3. lazygit - 심플한 터미널 git UI (링크)

"강력한 Git을 아주 사용하기 쉽게"
- 윈/맥/리눅스 및 대부분의 환경 지원
- 쉬운 파일 추가 및 최근 브랜치 체크아웃
- 보기 편한 머지 충돌 해결 화면
- log/diff 스크롤해서 보기
- 빠른 푸시/풀
- 모든 기능을 키보드 단축키로
ㅤ→ z : undo , ctrl+z : redo (reflog 기반 작업을 쉽게 처리)

4. Polly.js - HTTP를 녹화/재생하는 라이브러리 (링크)

- Netflix가 만든 오픈소스
- HTTP 인터랙션을 녹화/재생/저장 하는 JS 라이브러리
ㅤ→ 브라우저 및 Node에서 사용 가능
- 별다른 설정없이 HTTP Req/Res를 Mock 가능
- 간단하지만 직관적이고 강력한 API제공
- Mocha 및 QUnit 지원
- 이벤트를 Intercept, Pass-Through, Attach 가능
- 느리게 또는 빠르게 재생 가능

5. 방어적(defensive) CSS (링크)

특정 CSS문제가 생기지 않도록 하는 스니펫 콜렉션
- Flexbox 줄바꿈 → flex-wrap: wrap;
- 여유 공간 주기 → margin-right: 1rem;
- 줄바꿈 되지 않아야할 긴 콘텐츠 → text-overflow: ellipsis; white-space:nowrap; overflow: hidden;
- 이미지 늘려짐/찌그러짐 방지 → object-fit: cover;
- 스크롤 연쇄 잠금 → overscroll-behavior-y: contain;
- CSS 변수 폴백 값 주기 → max-width: calc(100% - var(--actions-width, 70px));
- 고정 높이 → height 보다는 min-height 사용
- 고정 넓이 → width 보다 min-width 사용
- 배경 반복 제거 → background-repeat: no-repeat;
- 버티컬 미디어 쿼리 활용 → position:sticky 같은거 쓸 때 특정 세로크기 이상에서만 적용 @media (min-height:600px) {}
- Flexbox 아이템 배열시 justify-content: space-between; 대신 gap: 1rem; 사용
- 이미지 위에 하얀 텍스트 올리때 이미지 로딩 실패시 대응 → background-color: grey; 사용
- CSS Grid 위에서 고정 값 사용은 조심 → 항상 미디어 쿼리 사용할 것
- 필요할때만 스크롤바 보이기 → overflow-y: auto;
- 스크롤바 생길때 레이아웃 변화 없애기 → scrollbar-gutter: stable;
- Flexbox 에서 최소 콘텐츠 사이즈 지정 → min-width: 0; (기본값이 auto 여서 overflow 발생 )
- CSS Grid에서 최소 콘텐츠 사이즈 지정 → minmax() 사용
- CSS Grid 사용시 Auto Fit vs. Auto Fill → 대부분의 경우 auto-fill 이 나음
- 이미지 최대 넓이 지정 → max-width: 100%
- 그리드 컨테이너 차일드에 postition: sticky 사용시 align-self: start 적용
- 그룹 셀렉터 지정은 다른 브라우저에서는 안될수 있으니 각각으로 분리할 것

6. 자바스크립트는 왜 프로토타입을 선택했을까? (링크)

'왜' JS에선 상속을 위해서 클래스가 아니라 프로토타입을 선택했을까? /
호이스팅과 This는 왜 이 모양일까? 에 대한 답을 찾아서
- 플라톤과 이데아, 그리고 클래스 기반 객체지향프로그래밍
- 분류(Classification)
- 프로토타입(Prototype)
- 의미사용이론(the use theory of meaning)
- 가족 유사성(Family Resemblance)
- Rosch 의 프로토타입 이론
- 프로토타입 기반 객체지향 프로그래밍
- 자바스크립트 — 프로토타입
- 자바스크립트 — 어휘적 범위(lexical scope)
- 자바스크립트 — this

7. 객체지향 시스템과 패러다임 그리고 철학 (링크)

- 클래스와 프로토타입의 가장 커다란 차이는 객체 생성 방식 [클래스 -> 인스턴스 vs 객체 -> 복사된 객체].
- 가장 큰 공통점은 객체지향이며, 프로그램을 객체라는 단위로 나누고 상호작용하게 하는 것.
- 객체지향의 핵심인 캡슐화를 잘하기 위한 가장 간단한 방법은 추상화를 잘 하는 것.
- 추상화는 데이터 위주의 성질(고전적 OOP), 형태(타입), 상태(데이터 주도 설계)와 관계 중심인 시간(절차지향), 행동(함수형), 정의(논리형), 상황(도메인 주도 설계, AOP) 등으로 나누어 생각할 수 있음.
- 잘 분류하고 설계하기 위해서 사고의 형식을 인식하게 만드는 다양한 범주의 이해가 있다면 좋음 [예) 칸트의 4강 12목].
- 철학과 패러다임
- 절차형: 시간은 대부분의 추상화에 영향을 미치며, Goto처럼 컨텍스트가 섞이게 만드는 문법은 좋지 않음.
- 함수형: 행동의 형태로 나타내려 하기 때문에 타입(형태)와 깊은 연관관계.
- 논리형: 사실과 규칙으로 논리를 구성하고, 질의를 함으로서 술어논리의 결과를 얻을 수 있음.
- 전통적 OOP: 직관적. 하지만 완벽한 속성을 알아내기는 불가능함.
- 데이터 주도 설계: 로직의 상태를 다루려는 함수형과 달리 컴퓨터 자체에서의 상태를 줄이려 시도. 캐시 히트를 높혀서 성능향상을 가져옴.
- 도메인 주도 설계: 전통적 OOP와 달리 도메인과 맥락에 따라 다르게 설계를 함(그림이론-용도의미론과 비슷), 서브도메인의 의존성 주입을 하는 AOP를 사용하면 구현이 편해짐.
- MVP
- 프로토타입 제작: 중요한 기능이 포함되어야 하며 디자이너, 개발자, 재무등의 관점에 따라 달라질 수 있음. 많은 사람들이 중요하다고 생각하는 제품의 유사도에 따라 전형적인 요건.
- MVP: 최소한의 완성도가 보장된 사용이 가능하고, 최종단계로 생각하는 제품과 유사하게 설계해야함.
- 객체지향과 존재
- 플라톤: 보편적 성질이 불변하며 실재하고, 개별적 존재들은 보편적 특성이 결여된 채로 존재한다 주장.
- 아리스토텔레스: 개별적 개체만이 근본적 실체이며, 보편자는 상하/포함 관계에서 나타나는 표상이라 주장.
- 클래스-인스턴스는 플라톤의 이데아론을, 프로토타입-복제된 객체는 아리스토텔레스 실체론과 유사.

처음에 쓰려던 목표는
- 전통적 OOP는 그림이론, 도메인 주도 설계는 용도의미론과 유사.
- 클래스-인스턴스는 플라톤의 이데아론을, 프로토타입-복제된 객체는 아리스토텔레스 실체론과 유사.
둘이었는데 생각보다 너무 길어졌네요.

8. Google Fonts Knowledge (링크)

- 구글 폰트 팀이 Typography 관련 자료를 모은 지식 저장소
- 폰트에 대한 기초 소개 : Punctuation, Weights, Glyphs, OpenType ..
- Typeface 선택 및 페어링 하는 법
- 사용 관련 : 알맞는 Line Height 선택, Kerning, Web Fonts 사용
- 예제와 함께 잘 정리된 용어 사전(Glossary)

9. freesound - 약 50만개의 무료 소리/효과 DB (링크)

 CC 라이센스로 공유된 다양한 소리 및 효과음 들
- 누구나 업로드 가능
- geotag 로 지도 기반 검색 가능
- tag 별 검색 지원 : ambient, bass, city, drums, electronic, loop, nature, metal, wind.

10. Voiceliner - 음성 메모 앱 (링크)

- 음성 메모를 남기면 원본 음성과 Transcribe 한 텍스트 내용을 같이 기록해주는 앱
- Dart로 작성된 AGPLv3 오픈소스
- 모든 기록은 로컬에 저장
ㅤ→ iOS의 기본 받아쓰기 기능을 이용
ㅤ→ Android는 Azure를 이용
- Outline 단위 기록
ㅤ→ 특정 주제에 대해서 각각 기록
ㅤ→ 들여쓰기(Swipe) 기능으로 계층별 정리 및 순서 조정 가능
- 위치 정보도 같이 기록 가능 하며 지도에서 보기 지원
- Google Drive 및 iCloud 로 백업 지원

11. FlutterFlow - Flutter 앱을 드래그앤 드랍으로 개발 (링크)

"Webflow for Mobile App with Flutter"
- 훌륭한 인터페이스의 다이나믹/UGC/비즈니스 모바일 앱을 드래그앤 드랍 방식으로 개발
ㅤ→ 50+개 이상의 템플릿
- Firebase 및 API 연동 지원
ㅤ→ Algolia(검색), 구글 AdMob, Braintree(결제)
- 생성된 소스를 다운로드 가능. GitHub에 연결해서 변경관리 지원
- 프리뷰 모드/런 모드(브라우저) 등으로 프로토타입을 공개하고 피드백 받기 지원

12. Animated Drawings - 그림을 애니메이트 하기 (링크)

- Meta AI Research 의 데모
- 아이들 그림을 애니메이션으로 만들어 주는 도구
- 캐릭터 그림을 올리면 포인트를 인식하고 조절해서 해당 캐릭터에 움직임을 부여
ㅤ→ 눈/귀, 손목/팔꿈치/어깨, 발목/무릎/엉덩이
- 다양한 기본 동작 제공
ㅤ→ 걷기, 뛰기, 댄스, 점프..
- Detectron2 + AlphaPose

 

Detectron2 - https://github.com/facebookresearch/detectron2
AlphaPose - https://github.com/MVIG-SJTU/AlphaPose

13. 디자인 시스템의 성공과 실패에 대한 6가지 문답 (링크)

요즘 디자인시스템 초기 설계에 참여하면서 고민이 많습니다.
관련해서 저번주 UX Collective 본 내용인데요. 회사내 디자인 시스템 멤버들을 위해 번역했는데 아까워서 여기도 공유해봅니다.
디자인 시스템을 다루는 10명의 디자이너를 인터뷰해서 요약한 내용이라고 해요.

질문 1. DS 역할에서 실패하려면?:

- 경찰이 되기
- 디자이너의 힘을 쓰기 (정치 얘기)
- 구성요소를 통합 해놓고 사용하진 않기
- 팀의 요구사항을 예측하는 대신 사후대응 하듯이 작업하기
- 사용자(다른 디자이너나 개발자)의 목소리를 듣거나 조사하지 않기
- DS를 위해 만든 DS
- 작업의 명확한 로드맵과 프로세스를 유지하지 않기
- 실현 불가능한 이상적인 경험 만들기
- 팀과 함께 테스트 하지 않는 것
- DS를 하나의 제품으로 이해하지 않는 것
- 도구를 만들고 사람들에게 사용하는 법을 교육하지 않기
- 실제 일하는 방식에서 벗어난 이론을 너무 많이 가져오기
- 혼자 할 수 있다고 생각하기
- 기술팀의 누군가와 지식교환에 100% 집중하지 않기
- 너무 유연하지 못한 컴포넌트를 만들고 Detaching 허용하지 않기
- 도움을 요청하지도 않고 사람들과 연결되지 않기 (내부던 외부던)
- 바로 옆이 아닌 멀리서 규칙을 지시하기

질문 2. DS가 성공하려면 필요한 소프트스킬에는 어떤 것들이 있을까요?

- 커뮤니케이션, 커뮤니케이션, 커뮤니케이션!!!
- 사용자와 함께하기, 듣고 묻고 조사하는게 정말 중요합니다.
- 실패를 겸손하게 인정하세요
- 인내심을 가지세요
- 안전한 공간을 만드는 능력
- 가르쳐주기
- 재사용 방법에 대한 체계적인 비전 제시
- 확장에도 단호하게 일관성을 유지해야합니다
- 상대방을 이해 할 때 그렇게 많이 이입할 필요는 없습니다. 규칙을 있는 그대로 받아들이세요.
- 95%는 하드스킬이고 5%는 규칙에 어긋났을 때를 위한 소프트스킬입니다.
- 사람들의 성장을 독려하고 공유하세요
- 자율성
- 계속 제품(DS)을 파세요
- 전략적으로 생각하세요
- 모든 사람들이 참여하게 하세요
- DS와 관련된 소음 내기
- 가능한 많은 시나리오를 알아내기위해 가능한 많은 시간을 쏟으세요
- 언어를 맞추세요.

질문 3. DS가 수행되는 방식이 더 중앙집중적이여야 합니까 아니면 더 분산되어야 합니까?

두가지 방식이 있는데 있는데 사람들이 어떻게 디자인을 하는지 확인하고 책임지는 중앙집중식 팀과, 모든 사람이 그것을 책임지게 하는 방식입니다. 어느쪽을 선택하는게 맞을지 사람들에게 물어봤습니다.

- 우리는 너무 중앙집중적인 팀이라 병목이 발생합니다. 하지만 분산모델은 오너십 약화 문제가 있을수도 있습니다.
- 우리는 DS를 집중화하기 위한 100명 이상이 모여있는 디자이너 팀이 있습니다.
- 사람들이 만드는 알파 라이브러리들과 협력하고 거기서 DS 팀의 백로그를 만듭니다.
- 사람들이 자발적으로 컴포넌트를 만들도록 교육합니다.
- 중앙집중화할지 여부는 다분히 정치적인 문제입니다. 그것을 결정하기 전에 얼마나 확장성있어야 할지에 대해서 정확히 알아야합니다.
- 기대치를 조정하고 DS 만들기에 사람들을 참여시켜야합니다.
- 협업하길 원했지만, 그 방법을 잘 몰라서 프로세스를 만들었습니다. (Culture vs Process)
- 처음엔 전달을 위해 다소 덜 협력적일 수 있습니다. 성숙해지면 더 협력적으로 만들 수 있습니다.
- 우리는 이제 그걸 탈중앙화해야 하는 시기에 도달했습니다; 사람들에게 기여하는 방법을 가르쳐야합니다.
- 당신이 사람들을 교육하지 않는다면 사람들은 기여하지 않을것입니다.
- 디자이너가 표준을 넘어서서 더 나은 결과물을 만들고 싶어할 때, 동시에 그것을 표준화하는 방법을 같이 생각할 수 있어야합니다.
- DS 는 1~2명이서 할 수 없습니다. 시스템을 만드는 것이기 때문에 DS는 스쿼드 단위에서 시작되어야 합니다.
- 팀 규모에 따라 매우 다르며 때로는 DS 팀은 코어 컴포넌트 개발에 집중하고 다른 앰버서더들이 그것을 전파시킬 수 있습니다.
-최종적으로 우리는 중앙집중식 팀이지만 앰버서더들과 협력적으로 일합니다. 최종결정은 DS 팀에서 합니다.

4. DS가 더 자세하고 제한적으로 만들기 위한 규칙이라고 생각합니까? 아니면 더 광범위하고 디자이너가 새 레이아웃을 만들게 자유를 주는 개방적인 것이라고 생각합니까?

폐쇄냐 개방이냐? 만약 디자인시스템 일을 하신다면 이 질문에 관심이 있을겁니다. 나도 그렇기에 사람들에게 물어보기로 했습니다.

- "접근성"에 대한 것은 더 제한적으로 접근하세요
- 우리는 다같이 기본적인 구조에서 시작했지만, 몇가지 비일관성을 만들기 시작했습니다. 따라서 우리는 100% 폐쇄적이지는 않지만 좀 더 제약사항을 두기로 했습니다. 그러면서도 디자이너에게 뭔가 되돌려 줄 수 있는 방법을 찾으려고 항상 노력합니다
- 상황에 따라 다르므로 리스크를 먼저 측정하고 결정하세요. 일반적으로 더 작은 팀 = 높은 유연성
- 그저 창의적이고 새로운 구성요소를 만드는 일이 아닙니다. 사람들의 요구에 맞출 수 있도록 충분히 유연한 컴포넌트가 필요합니다
- DS는 비즈니스입니다. 컴포넌트가 적을 수록 좋습니다.
- 사람들이 DS를 사용하기를 즐겨야합니다. 겉으로보기엔 유니폼같아서 유연성이 없어도 된다고 생각하기 쉽습니다만 (그렇지 않습니다)
- 처음부터 매우 제한적일 수는 없습니다. 시간이 충분히 지남에 따라 특정 패턴 등으로 진화를 시작할 수 있습니다.
- 회사에 새로 합류하는 디자이너에게는 더 많은 제약이 도움이 될수도 있습니다. 규칙을 깨기 위해선 규칙부터 시작해야합니다.
- 우리는 사람들이 그들만의 레시피를 만들 수 있도록 충분한 재료를 제공합니다.
- 팀의 성숙도에 따라 다릅니다. 주니어가 더 많다면 더 적은 문서를 이해하기 때문에 더 많은 디자인 지침을 요청하는 경향이 있습니다. 그래서 더 많은 교육이 필요해지지만 그래도 그들을 가두지 않고 자유롭게 일할 수 있게 하도록 노력합니다. 가장 큰 챌린지는 사람들이 문서를 직접 읽고 사용하도록 만드는것이므로 Figma 처럼 디자이너에게 더 가까운 곳으로 가져갈 가능성이 있습니다.
- 접근성과 미학에 대한 것이라면 더 제한적이여야합니다.
- 토큰들은 일관성을 지키는데 중요합니다.
- 좋은 문서는 사람들과 조화를 이루는 것과 자유롭게 두는 것 사이의 밸런스를 맞춥니다.

질문 5. 브랜딩과 마케팅에 연결된 DS에 대해 어떻게 생각하십니까?

(잘 모르는 분야라 번역이 좀 어렵네요)

디자인 시스템이 결국 디지털 제품에 대한 것이여야 한다는 걸 이해하지만, 제품은 가장 중요한 브랜드 플랫폼 중 하나일 수 있기 때문에 사람들이 그것을 어떻게 연결지어 생각하는지 궁금했습니다.

- DS에 연결된 브랜딩에 대해 생각하는 법은 그게 반대로 DS에 어떻게 영향을 끼치는지 생각해보는 것입니다.
- 우리는 브랜드의 모양과 느낌을 정렬하기 위해 디자인 시스템을 브랜드에 맞추기 시작했습니다.
- DS는 확장성과 브랜드 ID 를 위한 것이지만, 이 둘 사이의 연결은 브랜딩 팀에 따라 다릅니다.
- Since DS is a language, MKT could support with assets for it;
- 브랜딩 팀은 기본 규칙을 만들기 위해 처음부터 DS 에 합류해야 합니다.
- 회사에 따라 다릅니다. DS 는 브랜드를 강화하는 도구이기 때문에 정렬을 맞추는 것은 중요합니다. 두 영역간의 연결은 DS의 접근성에도 영향을 끼칩니다.
- 전략을 조정하기 위해 브랜딩 팀과 싱크를 맞춘 방법을 찾는것이 중요합니다.
- They were used to join projects that the company already had a partner to support with branding, so they would come together with these partners to bring the brand inside the DS;
- 때로는 문서와 시스템을 함께 사용할 수 있지만, 대체로는 그렇지 않습니다. DS는 인터페이스입니다. 브랜드 팀은 따로 "브랜딩 시스템"을 갖고 있고 라이브러리끼리 상호작용하는 경우가 더 일반적입니다. 그 둘은 완전히 동일하진 않습니다.

질문 6. DS의 성공을 어떻게 측정할 수 있습니까?

- 참여, 채택 및 팀 상태를 이해하기 위한 인식 조사
- 컴포넌트 커버리지 (DS가 얼마나 쓰이는지 vs 하드코딩 되어있는지)
- Adoption
- Time to market
- ROI
- Figma Analytics
- 개발팀들의 반응
- 접근성
- 구성요소가 사용된 횟수

14. HTTP Tollkit - HTTP 디버깅용 오픈소스, 포스트맨 대체?! (링크)

- 모든 HTTP/HTTPS 리퀘스트를 인터셉트 및 보기/Rewrite/Redirect/Inject Error 지원
- 다양한 환경의 HTTP 요청을 설정 필요없이 바로 캡쳐가능
ㅤ→ 브라우저/안드로이드 앱/백엔드(Node/Pyhon/Java/Ruby..)/터미널 및 Electron앱 등
- 윈도우/맥/리눅스
- HTTP 정보를 MDN에서 바로 조회 가능하게 연결
- Monaco 에디터로 메시지 바디 보기 지원 (하이라이트 & 구문강조)
- 브레이크 포인트를 통해 HTTP 트래픽을 잠시 멈추거나 실시간 편집 가능

15. 애자일 안한 이야기 (링크)

"애자일 비 전문가이고 애자일 하겠다는 생각을 가진적이 별로 없는 사람으로서 애자일에 도움을 받아 개발 과정의 어려움을 극복하고 조금이나마 더 유용한 소프트웨어를 만들려고 노력했던 이야기를 정리해 봤습니다."

- 애자일과 첫만남
- 객체지향의 재발견
- 애자일 성공사례
ㅤ→ 진짜 성공 이유 : 현장 상주 고객(On-Site Customer)
- 개발조직의 두가지 함정
- 완전한 팀(Whole Team)
- 버스 인자(Bus Factor)
- O2O 스타트업
- 오늘 하던 일을 못하게 되어도…
- 일이 일을 만들게 하지 말자

- Agile에 관심이 없는 이유
- 그건 Agile이 아니야!
- 고통(Pain) 주도 개발 vs. 원칙(Principle) 주도 개발