2025-07-28 주간 URL 모음

  • TrackWeight - 맥북 트랙패드를 디지털 저울로 사용하기 | GeekNews
    • 요약
      • TrackWeight는 MacBook의 Force Touch 트랙패드를 디지털 저울로 활용할 수 있게 해주는 macOS 앱
      • Open Multi-Touch Support 라이브러리를 사용해 일반적으로 접근 불가능한 트랙패드의 상세 압력 데이터를 획득하여 그램 단위로 무게 측정
      • 정전 용량 변화 감지가 필요해 손가락 접촉이 필수이며, 금속 물체 측정 시에는 종이나 천이 필요함
      • macOS 13.0 이상, Force Touch 트랙패드 탑재 MacBook(2015년 이후), App Sandbox 비활성화가 요구 사항
      • 실험적/교육적 목적의 프로젝트로, 정확한 계량이 필요한 상업적 용도에는 정식 디지털 저울 사용 권장
      • Hacker News에서는 iPhone의 기압계를 활용한 저울 기능, 과거 iPhone 6S의 TouchScale 등 유사한 사례들이 논의됨
      • 사용법의 복잡성(손가락을 트랙패드에 올린 상태 유지, 최소 압력으로 접촉 등)이 Rube Goldberg 머신 같다는 의견도 제기됨
      • 과거 PowerBook의 하드디스크 진동 센서를 지진계로 활용한 SeisMac 프로젝트와 유사한 창의적 하드웨어 활용 사례로 평가받음
      • Private Frameworks를 통해 공식 API에서 제공하지 않는 기능에 접근하는 기술적 구현 방식이 관심을 끌음
      • 창의적이고 기발한 해킹으로 평가받으며, 하드웨어의 의도되지 않은 용도로의 활용에 대한 긍정적 반응이 많음
  • They're putting blue food coloring in everything
    • 요약
      • (참고: AI를 파란색 으로 비유한 글임)
      • 한 사람이 햄버거를 주문했는데 예상치 못하게 파란색으로 나왔고, 웨이터는 모든 레스토랑이 이제 트렌드로 파란 음식을 만들고 있다고 설명함
      • 화자는 맛에는 영향을 주지 않는다고 들었음에도 불구하고 파란색 착색을 싫어하며, 전통적인 음식 색깔을 선호함
      • 파란 음식이 레스토랑을 넘어서 퍼짐 - 우유 배달도 파란색이 되었고, 우유배달원은 이를 정상적인 시범 프로그램이라고 설명함
      • 친구들은 화자의 우려를 일축하며, 파란 음식도 괜찮고 변화에 적응해야 한다고 말함
      • 1년 후, 파란 음식이 어디에나 있게 되고 더 비싸졌으며, 회사들은 다른 향료 생산을 포기하고 파란 식용 색소 생산으로 방향을 바꿈
      • 화자는 파란 육류 제품을 피하기 위해 채식주의자가 되었지만, 레스토랑에서는 샐러드조차 이제 파란색이라는 것을 발견함
      • 레스토랑들이 "파란색 우선" 정책을 채택하여, 음식에서 파란색 착색을 제거하려면 특별 요청이 필요하게 됨
      • 화자는 파란 음식을 피하기 위해 집에서 요리하는 것으로 물러났고, 더 수고스럽지만 선호할 만하다고 느낌
      • 전 친구가 몰래 "정상" 음식에 파란 착색료를 테스트로 넣었고, 이것이 밝혀졌을 때 그들의 우정이 끝남
      • 파란 착색료가 결국 상수도와 "고급 칼"을 통한 집에서 만든 음식까지 오염시켜 피할 수 없게 됨
      • 화자의 삶은 가능한 한 어디서든 파란 음식을 피하는 것에 사로잡히게 되고, 심지어 알약 같은 자연적으로 파란 물건들도 의심하게 됨
  • (번역) 상태들의 참담한 상태
    • 요약
      • 피그마 컴포넌트의 state 속성이 실제 코드 구현과 일치하지 않는 문제점을 다루며, 디자인 시스템에서 상태를 올바르게 모델링하는 방법을 제시
      • 대부분의 디자인 시스템에서 state 속성을 잘못 설계하고 있으며, hover, active, disabled, error 등을 하나의 state 속성에 몰아넣는 방식이 코드의 실제 작동 방식과 다름
      • 코드에서는 disabled, readonly, error 등이 독립적인 불리언 속성으로 구현되지만, 피그마에서는 이들을 state의 옵션으로 처리하여 조합 상태를 표현하지 못함
      • 체크박스와 라디오 버튼 예시를 통해 selected 상태와 상호작용 state(rest, hover, active, focus)가 조합되어 8가지 가능한 상태 조합을 형성함을 설명
      • disabled 속성은 다른 상호작용 상태와 독립적이며, true일 때 hover, active, focus가 무의미해지므로 별도의 불리언 속성으로 분리해야 함
      • readonly 속성 역시 독립적이지만 disabled와 상호 의존적이며, 둘 다 true일 때 disabled가 우선순위를 가짐
      • 검증 상태(error, success)는 상호 배타적이므로 none, error, success 옵션을 가진 열거형 속성으로 모델링하는 것이 적절
      • focus 상태는 특별한 경우로, 다른 상호작용 상태와 조합 가능하지만 실용적 관점에서 별도 속성으로 분리할 필요성은 낮음
      • 현재 Atlassian, GitHub, Shopify 등 주요 디자인 시스템도 이런 문제를 안고 있으며, 피그마 에셋과 코드 컴포넌트 간 API 불일치가 지속되고 있음
      • 디자인과 코드 간의 더 깊은 통합과 정렬이 필요하며, 완벽한 모델링을 추구하되 실용성과 균형을 맞춰야 함