Xcode 프로젝트에서 색을 고르고 UIColor 혹은 NSColor 값을 얻고자 할 때 지금까진 개발자용 Color Picker의 도움을 받았는데, ColorSense Xcode plugin 을 설치하면 code editor를 떠나지 않고 바로 이 작업을 진행할 수 있어서 아주 편리하다.

Edit 메뉴에 있는 색 삽입 명령(Insert Color…)을 통해 바로 원하는 색을 선택해서 해당 UIColor(NSColor) 선언문을 자동으로 넣어줄 수 있고, 또 키보드 caret을 색 선언문 안으로 가져가면 실제 색을 바로 위에서 확인할 수 있으며 Mac OS X color picker를 통해서 실시간으로 색을 변경할 수도 있다.

Edit 메뉴의 색 삽입 명령은 단축키를 등록해 두면 편한데, 이는 Xcode가 아닌 시스템 환경 설정의 키보드 항목에서 해줘야 한다. ColorSense for Xcode Plugin 데모 비디오

CSS를 작성할 때마다 보통 CSS properties를 정의하는 순서는 개인마다 자기만의 어떤 정해진 규칙이 있을 것인데, 여기서 중요한 것은 그 어떤 규칙의 세세한 내용보다도 이런 규칙을 일관성 있게 따른다면 차후 관리와 유지보수 측면에서 더 효율적일 것이고, 또한 팀원의 일원으로서 작업할 때는 이런 일관된 규칙을 정하고 따르게 하는 것이 더 중요해지기 마련이다.

여기에 도움을 줄 수 있는 도구로 여러 개발자로부터 권장된 기준과 이 기준에 맞는 순서를 자동으로 정리해주는 CSScomb이 있다. CSScomb Online 도구도 있지만, 여러 text editors 안에서 사용할 수 있는 plugin 형태로도 제공하고 있다.

현재 최신 버전은 2.11인데, 위에서 제공하는 text editors 용 plugin이 최신 버전이 아닐 땐 직접 소스를 내려받아 컴파일해서 설치할 수도 있다.
CSScomb – CSS properties의 순서를 단정하게 정리해주는 도구(이)란 제목의 글 마저 읽기 →

iOS 6가 설치된 기기에서 웹 페이지를 방문했을 때 해당 페이지 관련 native iOS 앱의 설치를 권하거나 이미 해당 앱이 설치되어 있다면 관련 앱을 클릭으로 바로 열어줄 수 있는 배너를 스크린 상단에 슬며시 띄워 주는 기능이 추가되었다.
소위 이 Smart App Banner를 띄우려면 페이지에다 다음과 같은 meta tag을 추가해주면 된다.

<meta name="apple-itunes-app" content="app-id=123456789, app-argument=x-sfp:///visit/seal-rocks">

content attribute에 있는 App-ID는 iTunes Link Maker를 통해서 얻을 수 있다. 그리고 app-argument(optional)는 방문한 페이지와 native App 간의 정보 전달 목적으로 사용되는데, 실제 URL 형식을 가지며 scheme이나 주소는 개발자가 아무것이나 적당한 것으로 지정해 줄 수 있다.

아래는 이렇게 해서 열리는 앱에서 delegate처럼 자동 실행되는 method로 openURL에는 app-argument에서 지정했던 URL을 받게 되면서 이곳의 정보를 확인해서 방문 페이지에 맞는 적절한 추가 조치를 취해줄 수 있겠다.

- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation;

WWDC 2012 Session 601 Optimizing Web Content in UIWebViews and Websites on iOS에서 소개된 내용으로, 단순한 native 앱의 광고기능 말고도 웹 앱과 이를 보완하는 native 앱 간의 상호 소통에 따른 풍부한 사용자 경험을 제공하는데 하나의 좋은 수단이 될 수도 있겠다.

정식 Safari 6가 어서 빨리 배포되길 기대하며.

function clearAllCookies(domain, path) {
  var doc = document,
      domain = domain || doc.domain,
      path = path || '/',
      cookies = doc.cookie.split(';'),
      now = +(new Date);
  for (var i = cookies.length - 1; i >= 0; i--) {
    doc.cookie = cookies[i].split('=')[0] + '=; expires=' + now + '; domain=' + domain + '; path=' + path;
  }
}

다만, HttpOnly cookie는 지울 방법이 없다.
단순히 쿠키에 남겨진 방문 흔적을 지우는 데 사용될 수도 있다.

웹에 접속하는 장비의 다양한 화면 크기와 점점 높아지는 pixel density에 맞춰서 상황에 따라 적당한 이미지를 전달해 주는 일은 어렵지만 당장 해결해야 할 시급한 문제였다.

이 문제를 적절히 대처하고자 여러 개발자들이 responsive images의 문제에 대응하는 많은 방법을 제시하고 있지만, 각각의 장단점을 고려하기 이전에 어차피 과도기적인 꼼수에 지나지 않는다는 문제를 공통으로 안고 있다.

그래서 이 문제를 해결할 장기적인 표준안을 도출해 내려고 Responsive Images Community Group에 모여서 지금까지 제시된 다양한 방법에 대한 서로의 의견을 교환하고 가장 이상적인 방법을 도출하고자 머리를 맞대고 있는 사이, 이 문제를 해결해 줄 또 하나의 방법으로 며칠 전 Apple에서 WHATWG list에 제시했던 img의 srcset attributes이, 외부에서 보면 갑작스러울 수도 있게, WHATWG 표준 draft에 바로 추가되는 일이 발생하였다. 그래서 그동안 머리를 맞대고 고민했던 많은 개발자들을 발끈하게 만들었고, 다수의 지지를 받으며 새로 도출해낸 <picture> element가 그냥 무시되었다는 점에서도 큰 허탈감을 표시하고 있다.

이런 사태는 개발자와 WHATWG 간의 원만한 소통 창구의 혼돈에서 비롯되었다는 얘기가 나오는데, 지금까지의 진행 상황은 Jeremy Keith씨가 올린 글에 자세히 나와 있다.

과연 이제 막 HTML draft에 추가된 srcset attribute이 앞으로도 그 자리를 지킬 수 있을지 모르는 일이고 또 몇 번의 수정안으로 대체되겠지만, 그 사용법을 보면 다음과 같다.

<h1><img alt="The Breakfast Combo"
         src="banner.jpeg"
         srcset="banner-HD.jpeg 2x, banner-phone.jpeg 100w, banner-phone-HD.jpeg 100w 2x"></h1>

Responsive images를 위한 img element의 srcset attributes(이)란 제목의 글 마저 읽기 →