Category Archives: Technology

Apple Photos

도대체 애플은 이해하려고 해도 이해할 수가 없는 회사다. 앱스토어에는 ‘베타’딱지 붙은 앱은 올리지도 못하게하면서 정작 전세계에서 가장 많이 쓰이는 MobileOS중 하나인 iOS에 ‘iCloud Photo Library’라는 이름으로 ‘베타’기능을 넣어놨으니 말이다. 그리고 이 기능을 ‘지원할 것 같은’ 자기네의 사진 앱 2종의 지원을 하루아침에 중단 시켰다. 나는 열심히 Aperture를 쓰던 유저로써 어이가 없는 결정이긴 했지만… 기다려보기로했고… 2014년 6월부터 8개월을 기다렸고 드디어 오늘, Photos의 Developer Preview가 공개되었다.

“뭐야 이게?” Photos를 기대하는 마음으로 첫 설치를 하고 난뒤 느낀 느낌. 뭔가 어려운 느낌이었다. 사실 iOS의 Photo 역시 iOS8 이후로 굉장히 헷갈리는 구조를 갖게되었다. ‘특별한 순간’이라는 말부터 기존에 있던 Photo Stream은 어디갔으며, 사진은 왜 자기마음대로 정렬이 되는가… 라는 생각을 가질때쯤 적응이 되어서 잘 쓰고있었던 참이었다. 그런데 Mac용 Photos는 느낌이 좀 쌔- 했다. iPhoto의 바둑판식으로 나열되는 라이브러리가 싫어서 어퍼쳐로 이사를 왔건만, 이녀석도 마찬가지로 iPhoto의 그것과 같은 형태의 라이브러리 구조를 띄고 있었기 때문.

스크린샷 2015-02-06 19.44.07

사이드바를 켜고 쓰는게 나에겐 더 편하다.

“아, 이거다.” 이고민은 이내 사라졌다. iTunes와 비슷한 플로우를 통해 기존의 익숙함을 다시 찾을 수 있었는데, 간단하게 사이드바를 켬으로써 걱정은 기대로 바뀌었다. Aperture에서 쓰던것과 같이 좌측에 정렬된 앨범들을 한눈에 볼 수 있었고, Aperture에서 자동적으로 마이그레이션된 라이브러리는 내가쓰던것과 거의 흡사하게 Photos의 기능으로 옮겨왔다. 베타임에도 불구하고 Aperture보다 체감상 2배는 빠르고 안정적이었다. 아직까지 ‘미완성’이라는 느낌이라는 부분이 없지 않아 있지만(예를들면 왠지 여기 아이콘이 있어야 할것같은데 없다거나. ), ‘불안정’하다는 느낌은 없다. 뿐만아니라, 일부 올바르게 재생이 되지 않던 슬로우모션도 올바르게 재생해 내고 있고, 버스트샷한 사진들도 아이폰과 같이 여러장을 넘겨보며 사진을 픽하던 iOS에서만 느끼던 재미를 느낄수있게 되었다.

iOS를 그대로 들고온 '편집'

iOS를 그대로 들고온 ‘편집’

다시 예전으로 돌아가 내가 어퍼쳐를 구매한 이유는 사진을 편집하기 위해서는 절대 아니었다. 앞서 말한대로 iPhoto의 그리드형식 라이브러리가 마음에 안들었고, 뭔가 전문가 느낌적인 느낌이 나는 까만 테마. 그리고 마지막으로 Apple에서 만들고 관리하는 애니까 애플이 버리진 않겠지.. 애플의 기능이 모두 녹아있겠지.. 하는 막연한 기대 때문이었던것 같다. 그럼 예전에 나였다면 Photos는 Aperture를 대신선택했을까? 일단은 전문가 느낌적인 느낌의 까만테마는 없지만 그럴것 같다.

편집탭은 iOS에서의 그것과 거의 90%이상 동일 하다. 나는 iOS를 그렇게 오래썼는데도… 내장된 사진편집툴을 한번도 사용해 본적이 없고 오로지 VSCOCam만 사용하고있다. 뿐만아니라 Aperture에서도, iPhoto에서도 사진편집기능을 이용해본적이 없고 사진을 편집할일이 있다면 Photoshop으로 옮겨 작업을 하곤 했었다. Photos의 사진 편집기능에 대한 평가는  ‘급하면 쓰겠네’ 정도. 그런데 Aperture와 iPhoto를 없애고 만든 앱이라면 Aperture의 강력한 기능들도 어느정도는 업고왔어야 했는데, UI에 더 많은 역량을 쏟고자 한것인지 아니면 iOS에서의 UX를 그대로 가져오고자 한것인지는 모르겠지만 너무 기능이 단순화 된 느낌. 어짜피 Photos가 된 이상 프로사용자들은 더이상 사용하지 않겠지만(물론, raw바이너리의 관리나 편집도 가능하다.)  나는 뭐… 원래 안쓰는거라 되던말던(..)

 

iCloud Photo Library

iCloud Photo Library

하.지.만, Photos가 가장 필요한 이유는 이곳에 있다. 아마도 애플은 이걸 위해서, 이 사용자 경험하나를 위해서 모든것을 없애고 새로만든게 아닐까 하는생각을 한다. 그리고 중간에 있었던 ‘포토 스트림’은 이 모든것을 만들기 위한 경험을 쌓기위한 시도가 아니었나 하는 생각도 해본다. 일단 개인적인 의미로써의 Photos의 역할은 이 기능하나로 모두 귀결된다. Apple의 가장 성공한 광고 카피중 하나인 “여기에서 찍은 사진이, 여기에도 있고. 여기에서 찍은 사진이 여기에도 있습니다.” 그리고 “It just works.”를 하기 위해 필요한것이 바로 iCloiud Photo Library이다. iCloud Photo Library 를 활성화 해둔 디바이스간에서는 찍은 사진들이 서로 공유가된다. 거의 지연시간이 없이. 그리고 앨범들도 공유가 된다. 말그대로 사진을 관리하기 위한 라이브러리가 모두 공유가 된다는 말이야기이다.

이 싸이클에 중심이 되어야할 Mac이 지금까지 싸이클에서 빠져있었다. Photos가 없었기 때문에 iCloud.com을 통해서 사진을 올리고 내릴수 밖에 없었다. 그런데 이제 이게 자동적으로 되는것. 아이폰으로 사진을 찍으면 해당 라이브러리 사진이 추가되고, 그 라이브러리를 땡겨쓰는 아이패드와 다른 iOS Device들은 해당 사진을 땡겨올 수 있었다. 이제 Mac에서도 사진을 보고 카메라를 통해 Import한 사진이 iCloud Photo Library와 동기화 되어 모든 IOS Device와 Mac에서 공유될 수 있게 된 것인데, 이것은 애플이 지향하는 바에 조금 많이 가까워지게된것이라고 생각한다. 물론 ‘포토스트림’이 iCloud Drive용량을 차지 않던것에 반해 iCloud Photo Library의 경우 용량을 차지하지만 리즈너블한 가격이라 생각한다.


나는 2년에 한번씩 라이브러리를 묶어서 관리하는데, 2014년부터 올해까지 찍을 라이브러리의 현재까지의 용량이 약 80GB정도 되어서 200GB를 결제하였다. (이거결제를 언제부터했는데 ! ㅠㅠ 어퍼쳐에서 업로드 되는줄알고 결제했던 바보같은 시절을 떠올리며 ㅠㅠ)  카메라로 열심히 찍은 사진을 그저 라이브러리에서 관리만 하면, 그대로 아이폰에서 끌어다 쓸 수있다는 사실에(정확히 말하면 ‘다시’ 끌어다 쓸수있다는 사실이) 행복행복하다.

Apple Photos

Apple Photos

결론을 내자면, 오래간만에 애플이 ‘완성도 높은’ 앱을 만들어냈다는 것. 사진은 추억을 담는 것이니, Photos앱이 아무리 궁금하더라도 기존 라이브러리에서 마이그레이션을 할때는 꼭 백업을 한 뒤 마이그레이션을 진행하라고 말씀 드리고 싶다.

정식버전이 나오면 꼭 ‘전문가 느낌이 나는 까만 테마’도 만들어 주면 좋겠다(..)

 

iOS7에서의 StatusBar(상태바)에 대하여.

navicon

 

제가 이 문서를 이해하는데에 필요해서 번역을 한지라 번역의 질은 개판이지만, 조금이나마 도움이 되었으면해서 글을 써봅니다. 이 글에서 궁금하신 내용은 리플을 통해 말씀해주시면 제가아는 한에서 답변해 드리겠습니다 🙂

원문 : http://blog.jaredsinclair.com/post/61507315630/wrestling-with-status-bars-and-navigation-bars-on-ios-7

iOS7에 대응한 Riposte와 Whisper앱을 업데이트하는동안, 계속해서 반복되는 문제점이 하나 있었는데, 우리의 앱의 계층적 레이아웃때문에 발생하는 문제들이 계속적으로 발생하였습니다. 문제가되는 API들은 대부분 System StatusBar(이하 상태바)와 UINavigationController(이하 네비게이션컨트롤러)가 원인이었는데. API문서들이 쓰여져 있더군요.  아무튼 아래에 있는 내용들은 iOS7에서 상태바와 UIViewContorller간의 문제점들떄문에 고생하고있는 개발자들을 위한 내 지식을 공유한것입니다.

1. iOS6 스타일의 상태바 레이아웃은 더이상 제공하지 않습니다. iOS7에서 실행되는 어플리케이션의 상태바는 항상 앱화면위를 오버랩하여 나오게됩니다.

2. 상태바의 Appearance와 상태바의 레이아웃을 헷갈리지 마십시오. 상태바의 Appearance(Light Or Default)는 상태바의 레이아웃(Frame이나, 높이, 오버랩되는것..)등에 영향을 전혀 끼치지 않습니다. 더이상 상태바에 배경색이 들어가지 않는다는것을 의미합니다. 해당 API의 UIStatusBarStyleLightContent라는 값으로 설정하면 글자색만 하얀색으로 변경될뿐 배경색은 투명합니다. UIStatusBarStyleDefault는 검정색 글자에 투명한 배경입니다.

3. 상태바의 모양은 두가지 설정중 하나를 참조하게 되는데요, 기존과같이 StatusBar를 설정하는 코드를 통해 상태바를 설정하는 방식을 사용하거나, UIViewController를 위해 새롭게 추가된 Property를 통하여 설정할 수 있습니다.  후자의 옵션이 디폴트로 사용 되게되어있습니다. 두가지 옵션은 앱의 기본 plist의 <ViewController-Based Status Bar Appearance> 의 값을 통해 스위칭할 수 있습니다. 만약 이 값이 YES로 설정되어있다면, 모든 최상위 뷰컨트롤러는 “preferredStatusBarStyle”메소드의 오버라이드를 필요로 하게됩니다. 이 메소드에서 리턴값을 light하게주느냐 default하게 주느냐에따라 Statusbar의 모양이 달라지게됩니다. 만약 <ViewController-Based Status Bar Appearance>의 값이 NO라면, 기존에 사용한 방식대로 일반적인 코드,즉 UIApplication의 메소드를 통해 StatusBar의 Style을 변경 할 수 있습니다.

4. UINavigationController가 UINavigationBar의 높이를 44px이나 64픽셀중 하나로 변경하게되니다. 만약 UINavigationController의 최상단의 뷰의 프레임이 UIWindow의 최상단에 항상 붙어있는 것을 감지하면, 자동적으로 navigation bar의 높이는 64px이 됩니다. 만약 최상단의 뷰가 UIWindow에 계속적으로 붙어있지 않는다면, Navigation Bar의 높이는 기존의 44px을 사용하게 됩니다. 이 로직은 어플리케이션내에 UINavigationController 아래에 있는 모든 하위 뷰컨트롤러들에게 계속해서 사용되는데, 이 로직이 작동하는것을 막을 수 없습니다.

5. UINavigationBar에 커스텀 백그라운드 이미지의 사이즈의 높이가 기존 44px인 이미지만 사용하고 있다면 어떻게될까요? UINavigationController의 사이즈가 UIWindow의 사이즈와 맞아 떨어진다면, 4번 항목에 따라 UINavigationBar의 사이즈는 64px이 될것이고, UINavigationController는 커스텀 백그라운드의 이미지의 프레임을 (0,20,320,44)로 지정하여 그리게됩니다. 그러니까, 상단에서 20px떨어진 위치에 커스텀 백그라운드 이미지를 그리게됩니다. 이렇게 하게되면 1번에서 말한 내용들을 우회할수 있는 방법 으로 iOS6스타일의 NavigationBar를 그리게 된것같지만 같지만, NavigationBar는 여전히 64px입니다. 이건 좌우로 당기면 나타나는 뷰컨트롤러 (페이스북과같은 형태의 MMDrawercontroller같은..)의 뷰구조에서 더 명확하게 드러납니다.

6. UIViewController의 프로퍼티중 하나로 생긴 edgesForExtendedLayout의 혼동하기 쉬운이름에 혼동하-.. edgesForExtendedLayout는 대부분의 경우에서 아무런 도움도 주지 못합니다. 이 프로퍼티는 UINavigationController에 ViewController를 추가해서 사용하는경우에만 동작을 하는데, 이 프로퍼티를 사용하게되면, edgesForExtendedLayout는 자동적으로 자식뷰컨트롤러의 UINavigationBar의 영역과 상태바의 영역까지 사용할것인가에대한 결정을 내립니다.  edgesForExtendedLayout프로퍼티로 UINavigationController의 UINavigationBar의 영역이 44px이될지 64px이 될지 결정하는것이 아니므로 위와같은 상황에서는 아무런 도움도 되지못합니다. (이로직은 4번로직을 보면됩니다.)

7. 만약에 UINavigationController안에있는 자식뷰컨트롤러의 내용이 네비게이션바에 가려져서 보이지않는 현상을 방지하려면 edgesForExtendedLayout의 값을 UIRectEdgeNone으로 변경하면됩니다. 자식뷰컨트롤러의 View Life Cycle중에 할수있는한 가장 빠른시점에서 설정하세요.

8. UINavigationController와 UITabBarController도 마찬가지로 Tableview와 Collectionview의 서브뷰계층을 ContentInset속성에 덧붙이려고 합니다. 이것은 어느정도는 4번 항목의 상태봐 로직과 비슷한 형태입니다. 이것을 방지하려면 TableView와 CollectionView의 automaticallyAdjustsScrollViewInsets 속성 값을 NO로 세팅해주면됩니다. (기본값은 YES입니다.)

9. 다시한번 말씀드리지만, iOS6스타일로 돌아갈 수있는 로직은 더이상 제공되지 않습니다. iOS6와 가장 비슷한 형태로 구현하려면, 모든 뷰컨트롤러의 모든 뷰를 20픽셀 아래로 내린다음, 최상단에 까만색 20px짜리 뷰를 만들어서 기존의 모양을 흉내내는 수밖에는 없습니다.

10. 애플은 9번에서말한 형태와 같은 형태로 앱을 구성하지 않도록 밀고있고, 애플은 여러분이 상태바아래의 영역까지 새롭게 디자인하기를 바라고있습니다. 맞는 말이긴한데, 기존에 출시되었던 앱이라면 기존의 사용자경험과 기술적인 이유들때문에 항상 애플이 바라는대로 할수는 없을것 같습니다. 여러분의 앱을 사용하는 유저가 원하는 가장 최상의 기발한 방법들을 사용해 보세요.

글쓰기가 재미있어지는 규칙, markdown.

github를 그렇게 들날날락해도, readme파일을 읽지도않고, 어짜피 페이지에 다나오니 신경쓰지 않았던것이 하나있다. 그 이름 하여 markdown. 위키문법을 기억하시는지? 그런거 비슷한거같다. 근데, 어렵지 않다. 문서펼쳐놓고 배울필요도없고, ‘스펠이맞나?’생각할 필요도없다. 그냥 몇가지만 기억하면 된다. 그리고 더 신기한건, 이 규칙은 실제 메모하는데에도 많은 도움이 될것같다는 점이다. 일단 이렇게 쓰면 무슨 글들이 나올까? 고민해보자.

# Markdown 문법이에요.
## Markdown 이란?
- Markdown은 간단한 마크업 언어입니다. 몇가지 규칙이 있는데요, 그건 [위키](http://ko.wikipedia.org/wiki/마크다운)에서 확인하시는게 오히려 이해하기 더 편하실겁니다. 
> 맞아맞아 

## Markdown 관련 어플리케이션
1. [mou](http://mouapp.com)
2. [Markdown Pro](http://www.markdownpro.com)
3. 어플리케이션은 물론 [Tumblr](http://tumblr.com)나 워드프레스 플러그인으로도 있습니다.

** 좋으다! **

어떤가? 위에서 조금 써본 이 문장이 Markdown 문법이다. 사람이 읽는데도 전혀 불편하지 않으면서, 실제 종이에서 활용할 수도있을것같으면서, 머리에도 쏙쏙들어온다. (물론 글은 잘써야겠지.) 위에서본 이문장을 HTML로 렌더링(변환)된 내용은 아래와 같다.

Markdown 문법이에요.

Markdown 이란?

  • Markdown은 간단한 마크업 언어입니다. 몇가지 규칙이 있는데요, 그건 위키에서 확인하시는게 오히려 이해하기 더 편하실겁니다.

    맞아맞아

Markdown 관련 어플리케이션

  1. mou
  2. Markdown Pro
  3. 어플리케이션은 물론 Tumblr나 워드프레스 플러그인으로도 있습니다.

좋으다!

정말 깔끔히도 정리된다.  만약 당신이 맥을 사용하고있다면, 위에서도 언급한 ‘mou’라는 어플리케이션을 강력 추천한다. 공짜고, 깔끔하다. 또, 맥사용자라면 언제 어디서나 마크다운을 HTML로 변환할 수 있는 스크립트를 사용하면 더 좋을듯하다. (Back to the Mac 블로그 참조)

mou

왜 진작 편한걸 몰랐을까… 싶다. 그리고 조금전까지 evernote노트에 markdown을 연동할 수 있도록 맥용 어플리케이션을 만들다가 때려친것같다(..) 그냥 mou에서 작업해다 붙여넣는게 더편하긴 한것같다(….)

아무튼, 아무튼. HTML이 귀찮고, 문서화는 해야하는 사람들이라면 markdown을 써보자. 만약 이글을 읽고있는 당신이 영어를 잘 한다면, Daring Fireball의 마크다운 문법 문서를 읽어보는것도 추천한다. 나는 영어를 못해서 다 읽지는 못하고. 깨작깨작.

마침내, iTunes 11.

iTunes 11.

지난 애플 미디어데이때 공개된 iTunes 11, 당시 바로 공개될것으로 기대하고 목이 빠-지도록 기다렸는데 10월을 건너뛰고 11월 말이되어서야 공개되었다. 어쨋거나 환영. 일단 처음 실행시키면 크게 몇가지가 바뀌었는데, 사이드바가 없어졌고, 하단에 있던 Status도 없어졌을것이다. [View]에가면 Status도 켤수있고, 사이드바도 다시 켤수있으니 아쉬우신 분들은 사이드바를 켜고 사용하면 되겠다.

이제 출시된지 1시간도 안되었지만, 사용하는내내 새롭지만 익숙한 UI를 만날수있었고 검색속도도 눈에띄게 빨라졌다. 음악이 약 8500여곡이 있는데 예전에는 리스팅하는데 살짝 딜레이가 있었다면 이제는 파파파팍 새로운 드랍팝윈도우에 뜨게되니까 훨씬 보기도좋고 사용하기도 편리하다. 1달이 딜레이되더라도 엔지니어링 이슈를해결하기위해 노력했다고하니 완성도에있어서는 의심의 여지가 없기를 바란다.

좌측하단에있었던 앨범아트도 상단 중앙 컨트롤 바 쪽으로 이사갔다. 예전버전과 동일하게 앨범아트를 누르면 앨범아트만 따로 띄워서 볼 수 있는 기능은 여전하다. 이거 모르는분들 많던데 (..)

가장 마음에 드는 기능중 하나는, upnext 기능의 일부인 [Play Next]기능. 물론 플레이리스트로 구성해도 되겠지만 플레이리스트를 만드는것자체가 부담인나에게는 정말 마음에 드는기능. 현재곡 바로 다음에 바로 플레이될 곡을 선택하면 현재 플레이되는 곡 다음에 플레이되도록 순서가 조정된다. Shuffle로 재생중이어도 다음에 듣고자 하는곳을 Play Next로 선택하면 순서대로 진행이되고나서 다시 셔플 모드로 재생. 마음에든다.

Mini Player

가장 기대한 기능이고, 가장 실망한 기능인 미니플레이어. 기존의 아이튠즈에도 미니플레이어는 있었지만 멍청했던게 사실. 조금더 기능을 몇개 더붙였고, 마치 iOS Notifications 같은 UI. 다좋은데 요녀석을 핫키로 불러낼수있는 기능이 없다. 나의경우 Alfred로 ctrl을 2번 연타할경우 Alfed의 iTunes Search기능이 뜨게 해두었는데 이걸 대체하길 바랬는데 조금 부족한듯. 아이튠즈 내에서는 단축키 ⌘⌥M 혹은 ⌘⌥3 (새창으로 미니플레이어 띄우기)으로 언제든지 불러낼 수 있다. 굳이 필요하다면 ⌘+을 이용해서 Preference를 불러낸뒤, 고급탭에서 ‘Keep miniplayer on top of ~~’ 를 켜면 항상 위에 떠있으니 접근성을 더 좋아질듯. (나는 항상위에 떠잇는게 싫다.ㅠㅠ)

앨범보기상태에서 음악을누르면 뷰전체가 바뀌던것을 아래로 다른 앨범들이 밀리면서 트랙리스트가 뜨도록 바뀌었다. 신기한것은 앨범커버 분위기에 맞춰 적당한 색깔로 배경색이 바뀌는 것. 아름답다! 조금더 실제 CD앨범과 비슷한 느낌을 받을 수 있다. 뭐.. 여러모로 불편한 부분도 존재하기는하지만.

아이튠즈11도 나왔고, 오늘은 아이패드 미니 셀룰러도 통신사를 통하여 판매시작한다고하니 아이폰5만 나오면 이제 2012년 애플제품의 기다림은 끝일 듯! 어쨋든, 잘해봐요 iTunes 11.

iOS6의 숨겨진 반가운 기능, Network Link Conditioner.

원래부터 있었던 기능인지는 모르겠지만, iOS6 GM을 올리고 이리저리 설정메뉴를 구경하다 발견한 기능중 하나이다. 네트워크통신을하는 앱을개발하다보면 Activity Indicator를 붙일때가 많은데, 인터넷이 참 빠른 우리나라에서는 ‘깜빡’하고 사라져버리는경우가 많기 때문에 네트워크가 느리거나 Connection Loss 가 일어났을때 처리할 수 있는방법들을 개발하기가 매우 까다롭다.

그래서 애플에서 iOS6에는 NetworkLink Conditioner를 넣어뒀다. 활성화를 위해서는

  • iOS6를 올린다.
  • XCode를 한번이라도 연결을 하여 iOS Device의 Developer Mode를 활성화시킨다.
  • Setting -> Developer -> Network Link Conditioner -> 아래의 profile들을 선택후 상단 Enable선택.

그러면 네트워크속도를 강제로 낮춘다. 애플스타일답게 ‘속도’ 로 표기한게아니라 Edge, 3G, Wifi, 같이 가상의 상황을 디테일하게 적어놓았기 때문에 테스팅하기 더 쉽다고 말할 수 있겠다.

덕분에 현재개발하고있는 앱의 로드하는부분이 올바르게 ㅊ비동기처리되지않았다는 사실도 알게되었다. 고마운기능!

Adobe Edge.

울 회사 Appknot에서 진행하고있는 프로젝트중에 ‘코코아카드’라는 프로젝트가있다. (원래는 ‘카톡카드’로 무료앱순위 10위권에도 들었으나-_ㅠ ㅋ사에서 내용증명오는바람에 이름을 코코아카드로 변경-.-) 타사의 앱과다르게 이미지가 바로 전송되는게아니라 HTML5로 제작된 카드가 링크형태로 전달되어 인터랙티브 효과와 함께 전송되는 카드서비스이다.

여튼간, 카드를 기존에 만들때 HTML5와 jQuery를 사용하여 ‘일일히-_-‘ 애니메이션을 하는 삽질을 하는 했는데… 가만 생각해보니 어도비에서 이런짓을 하고있었던게 생각나서 찾아보니…

아! 이런 신세계가!

키프레임을 찍어주고 오브젝트에 효과주면 깔끔한 HTML5코드로 재탄생되어 필요한 jQuery Plug-in들은 스스로 임포트하여 작성한다.ㅠ_ㅠ 아. 이제 이거쓰자. 애니메이션은 Edge쓰자. 두번쓰자.

이거 왜 나온지 꽤 되었는데도 이제서야 생각나서 사용하게되는걸까(….)

다운로드 : http://labs.adobe.com/technologies/edge/

맥과 아이폰을 키보드하나로. 1Keyboard.

iMessages가 살짝 맛이가서 여자친구와 메시징을 주로 카카오톡으로 옮겨왔는데, 이게 참 컴퓨터를하다가 왔다갔다하기가 불편하더라구요. 그래서 맥을 블투키보드로 연결시킬 수 있는방법이 없을까… 싶어 찾게된 프로그램입니다. (JUC400도 그렇고 요즘 키보드하나로 해결하려는 귀차니즘이 보이는…)

처음에는Type2Text라는 앱을 4.99불을 주고 구매해서 샀었는데, UI도 불편하고 (입력되는 키들이 왜 화면상에 나타나야하는건지;;) 인식도 잘안되는 경우도있는차에.. 친구가 1Keyboard라는 앱이 있다고 소개해주더군요.

1Keyboard

  • 무료
  •  디자인도 깔끔
  •  입력되는 키도 화면상에 나타내지않고
  •  핫키도 됩니다.

맥의 경우 cmd+shit의 조합에 알파벳을붙이면 거의 충돌이 나지않는편이라 저같은경우는 거의 핫키를 cmd+shift로 조합하는편입니다. (cmd+shift+w는 트윗창 띄우기 등…) 맥에 1keyboard를 실행하고, 맥과 블루투스연결을 한뒤 제 핫키인 cmd+shift+e를 누르면 바로 키보드가 아이폰과 연결이되고 1Keyboard가 키보드로 입력되는내용을 전부 인터셉트하여 아이폰으로 보내줍니다. Hooray!

다시 빠져나오기위해서는ESC를 누르면되고, 아이폰뿐만아니라 아예 맥의 프로파일에 키보드 프로파일을 넣는방식을 취하여 다른맥이나, 안드로이드기기에도 연결하여 쓸 수 있습니다 🙂

http://www.eyalw.com/1keyboard/

j5create, JUC-400

어제 클리앙 맥당을 구경하다, 키보드&마우스 하나로 컴퓨터 두대를 왔다갔다 할 수 없을까요? 라는 질문에 당연히, ‘시너지’라는 프로그램을 깔면된다. 라는 답변을 달러 턱을괴고 들어갔다가 예상치못한 지름신을 만났다. 그것은 JUC400이라는 하드웨어 시너지. 시너지에 알게모르게 불만이 많았던 나는 이리저리 이 제품에대해 알아보다가 만족할만한 리뷰가 없어서..그냥 사기로했다.(……..안사고 후회하는것보단…) 볼라벤이 갔다는 소식을 듣고 퀵으로 제품을 하나 주문해 받았다. 가격은 4만원초반대

마치 양쪽에 USB메모리를 달고잇는 케이블의 모양갖기도하고, 넙쩍한 썬더볼트케이블 같기도하다. 여튼. 3가지 모델이있는데 JUC100은 Window to Window만, JUC200은 Window와 Andorid, JUC400은 맥과 맥, 윈도우와 윈도우, 윈도우와 맥, 윈도우와 안드로이드, 심지어 iPad와도 키보드를 공유할수있는 완전체이다. (그래봤자 맥유저들은 가장 높은 JUC400을 사야만 한다 ㅠㅠ) 호스트를 어디로 사용하든 아무 쪽으로나 꽂아 호스트PC에서 설정만하면 되는 시스템이다.

꽂으면 이미지가 자동으로 마운트되며 Wormhole이라는 소프트웨어가 실행된다. (굉장히 마음에드는 방식. 따로 설치할필요없이 계속 꽂혀있는동안 이미지에서 불러오는 방식이다.) 그러면… 설정은 끝이다. 사용자로써는 USB케이블을 양쪽 컴퓨터에 꽂아주는것만으로 설정은 끝이다.

그런데… 몇가지 단점이 보인다.

  1. 호스트PC와 클라이언트PC의 마우스 속도가 다르다. 미세한 끊김이있는데 신경쓸만한 수준은 아니고 미세한 작업도 가능한 수준이다. 나같은경우 항상 마우스속도를 최대로 해놓고 쓰는편인데, 클라이언트PC에서 최대로 해놓고 웜홀로 들어가면 너무빨라서 3정도로 해놓고 쓰고있다. 그러며 얼추 속도가 맞는 편이다. (호스트 PC 감도 10 : 클라이언트 PC 감도 3 정도..-.- 7배가 빨라지는거구나…)
  2. Ctrl+wheel, Alfred Hot Key같은게 클라이언트 PC에서 작동하지 않는다. 나같은경우 Ctrl+wheel을 해서 확대해 문서를 보는 경우가 많은데, 이걸 하면 클라이언트 PC에서 작동하는게 아니고, 호스트PC에서 쭉 확대가 되어버린다. 그래서 이건포기했고, 나는 맥에서 사용하는 런쳐를 알프레드를 사용중인데, 알프레드를 불러오는 핫키를 option을 2번 연달아 누르게 설정을 했다. 이러면 호스트PC와 클라이언트PC양쪽 다뜨는 -_- 현상을보인다.
  3. 마운틴라이언의 마우스 방향이 원래대로 돌아가 버린다. 마운틴라이언부터 마우스 방향을자연스럽게 한다며 휠을 기존방향의 반대로 돌려야 했는데, 어느순간부터 이게 적응이 되어 편한 지경에 이르렀는데… 호스트PC에서 클라이언트PC로 들어가면 이게 다시 원래의 휠대로 돌아가버린다. 굉장히 마음에 안드는 단점… 근데 인간은 적응의 동물이라했던가 ~_~… 제조사에서는 공식적으로 10.8을 지원한다고 써놓고 이런기본적인것도 안되다니!!

JUC 400의 스위칭을 도와주는 Wormhole이 실행된다.

3가지의 치명적인 단점에도 불구하고, 핫키로 넘기고나면 굉장히 쓸만한 퍼포먼스를 보여준다던가.. 피씨사이를 드래그해서 직관적으로 파일을 보낼 수 있다던가, 클립보드가 공유된다던가..하는 등의 기능은 마음에든다.

특히 시너지를 새로셋팅하면 IP나 호스트네임적어주고 네트워크에 항시 연결되어있어야하는등 번거로운 절차없이 양 PC에 USB케이블만 하나씩 꽂아주면 된다는게 굉장히 마음에든다.

마우스를 화면 사이드에 갖다대어 PC를 스위칭하는게아닌 단축키로 스위칭하는것도 가능한데, 나같은경우이게 더편한것같아서 아예 화면사이드에 마우스대서 넘기는 건 꺼버리고, 핫키로만 PC를 전환하는 옵션으로 해두었다. (올드맥 키보드를 사용중이라 사용하지않는 clear키를 핫키로해놓으니 굉장히 편하다.ㅋㅋ)

아쉬운점만큼 편리한점도 많은 액세서리인것같다. ~_~

 

 

XCode 4.4 의 사랑스러운 새 기능(?)…

회사에서 일하다, 자려고 침대에 누워서 아이패드로 뒹굴뒹굴거리다.
며칠전 회사에서 사람들이 애플에서 올린 샘플코드를보면서 “도대체 이게뭐지…”하면서 코드 보고있던게 생각나서 검색해보니 XCode 4.4부터 새롭게 생긴 기능이었다. (정확히말하면 LLVM 컴파일러가 4.0으로 업되면서 생긴기능들) 이리저리 살펴보다, 이제서야 이게 생기는구나..싶은 마음에 잠도 뿌리치고 컴퓨터앞에 앉아 포스팅 중이다.

이제 NSArray, NSDictionary, NSNumber등을 만들때 기존의 전통적인 Objective-C 의 메시지보내는 방식을 쓰지않고, 보다 편하게 만들 수 있다. 마치 NSString을 @”이렇게” 쓰면되는것처럼.

1. NSArray LIterals

기존의 코드였다면 아마도,
array = [NSArray arrayWithObjects:a,b,c,nil]; 
으로 사용했을것이다. XCode 4.4 부터는
array = @[ a , b , c ]; 
로 NSArray를 할당할 수 있다.

접근역시 기존에 [array objectAtIndex:i] 같이 귀찮게 -_- 하던것을 이제는 편하게 array[i]로 접근할 수 있게되었다.

2. NSDictionary Literals

dict = [NSDictionray dictionaryWithObjects:@[obj1, obj2, obj3] forKeys:@[key1,key2,key3]];
를 이제는
dict = @{ key1 : obj1, key2 : obj2 , key3 : obj3};
로 만들 수 있다.

NSDictionary의 접근역시 기존 다른 언어들과 마찬가지로 편리하게, dict[key]로 접근할수 있게되었다.

3. NSNumber Literals 

NSNumber는 이상하게 잘 안쓰게되는… 그냥 int로 써버린다-_-; 아무튼… 기존에
NSNumber *number;
number =  [NSNumber numberWithInt:12345];
를 이제는
number =@12345;
로 사용할 수 있다

LLVM 4.0 만쉐~ㅠ.ㅠ

아래 이미지 참고하면 좋을듯.