사진에서 잘은 안보이지만, 340g 짜리 같은 제품.
무려 29불로 가격은 두배.
면세점하면 왠지 가격이 저렴할 것 같아서, 충동구매를 하게 되지만, 사실 싸다는 보장은 전혀 없음.
가격 두배로 받고, 부가세 10% 빼주면 뭐하나…
하나의 블루투스 헤드셋, 그리고 맥과 아이폰, 해결책을 찾다
블루투스 헤드셋과 아이맥을 항상 연결해서 쓰고 있다. 유선이 아니라서, 걸리적 거리는 것이 없어 편하다. 하지만, 문제가 있다. 전화가 오면 불편하다는 점이다. 헤드셋을 벗고 전화를 받는 것도 귀찮은 일이지만, 더 큰 문제는 블루투스 헤드셋을 통해서 전화를 받고 싶다는 점이다. (원래는 그럴려고 산 것이기 때문이다.) 전화를 받을 때, 블루투스 헤드셋을 쓰면 손을 쓰지 않아도 되기 때문에, 맥에서 메모나 검색도 간편하게 할 수 있고, 오랜 통화에도 팔이 아프지 않은 장점이 있다. 하지만, 반대로 그럴려고 블루투스 헤드셋을 아이폰에 연결해 놓고 하루종일 헤드셋을 쓰고 전화가 걸려오기를 기다리는 것도 우스운 일이다.
그래서, 항상 블루투스 헤드셋이 아이폰, 아이맥 둘 다 연결 되기를 원했다. 왜 페어링은 동시에 두개가 안될까? (혹시 되는 방법이 있는지 모르겠으나, 지금까지 시도해 본 바로는 방법을 모르겠다.) 아무튼 결론은 두개를 동시에 연결해서 평소에는 아이맥으로 소리를 듣다가, 전화가 올 때에만 아이폰에 연결되는 것은 불가능하다는 판단을 내렸다.
그리고, 한동안 포기하고 있다가, 재밌는 앱을 발견해다. AirPhones
하지만, 문제는 AirPhones 의 경우 맥의 사운드를 전송 받아서 일반 스피커로 소리를 전송할 때에는 아무 문제가 없었으나, 유독 블루투스 헤드셋을 통해서 소리를 들을 때에는 잡음과 소리 끊김이 심해서, 들을 수 없을 지경이었다. (FAQ에도 친절히 설명이 되어 있었다) 사실 아이폰 스피커로만 들을 거라면, 아이폰 전용 스피커도 없는 나로서는 별로 필요 없는 앱이 되었다.
그리고, 혹시나 하는 맘에 깔아본 Airfoil
원하는 답을 주었다. AirPhones 와 같은 방법이지만, 블루투스 헤드셋으로 들어도 끊김없는 소리를 들려준다.
Airfoil 만세!
PS> Airfoil 은 이거 말고도 훨씬 더 넓은 기능을 제공하는 듯 한데, AppleTV와 연결등 한번쯤 시도해 볼 만한 듯 하다.
PS2> 이 글을 기쁜 맘에 쓰고, 인터넷 결제를 통해서 Airfoil 정품 구매까지 했는데, 소리가 끊기기 시작한다. AirPhones 와 동일한 현상 발생. 아이폰을 껐다가 켜봐도 마찬가지… 또, 그러다가 한참 지나니 정상으로 돌아왔다.
PS3> 가장 큰 약점은 싱크문제인 듯 하다. 음악같은 경우에는 문제가 없으나, 영화는 못본다. 약간의 딜레이가 있어서, 영화는 화면과 소리가 거의 2,3초 정도 차이가 난다.
아… 역시 갈길은 멀다.
뽀모도로 테크닉 발표
뽀모도로 테크닉 발표 from Sooyong Wang on Vimeo.
WordPress for iPad 이거 위험한 물건이다
첫째 글쓰기 화면 왼쪽편에 왜 Posts 목록이 떡하니 버티는 건가? 키보드 타이핑하다 잘못 클릭하면 황당하게도 쓰던글 날리고 그 글 편집모드로 넘어가 버린다. 그걸 모르고 계속 쓰다간 두 글이 섞여 버리고 저장까지 해 버리면 완전한 혼란이 되어버린다. 방금 일어난 일이다.
둘째 처음 사이트 등록도 뭔가 불안하다. 너무 빨리 등록해 버리면 중간에 꼬이는지, 화면에는 보이지는 않지만 등록이 되었다고 나온다. 더구나 다시 등록 하려면 이미 등록된 사이트라 등록이 안된다. 앱을 다시 지우고 설치해야 한다.
세째 저장을 한번 하고 나면 저장 버튼이 사라진다. 다시 편집을 시작하면 버튼이 나오긴 하지만 당혹스럽다.
네째 저장하고나면 아까 편집했던 다른 글로 자꾸 왔다 갔다 한다. 무섭다.
좋긴한데 조금 위험해 보인다
iPhotoFlickrSync
2년 전부터 나는 iPhoto 에 있는 사진을 Flickr 와 연동하길 원했고, 새로 나온 iPhoto 09 에도 기대를 걸어 봤지만, 내가 원하는 것이 될 수 없었다.
내가 가장 원하는 것은
- 나는 사진을 iPhoto 에만 넣는다.
- 그럼 iPhoto와 Flickr 는 자동으로 Sync 된다
였다.
하지만 내가 원하는 것을 찾을 수는 없었다. 그 추정되는 이유로는
- 일반 사용자들이 필요로 하기엔 고급 기능에 가깝고,
- 자동 싱크라는 것이 일반적으로 구현하기엔 너무 복잡한 일에 가깝고,
- 방대한 iPhoto 사진을 백업 목적으로 Flickr 를 사용하는 예는 드물기, (대부분 공유의 목적으로 사용하지 않을까)
때문이 아닐까 싶다.
그래서 2년간의 숙고 끝에 자작 솔루션 제작에 들어갔다. 사실 수작업으로 Flickr 연동을 해 오다, 올해 1월부터는 안하기 시작했다. 가끔 Flickr 에서 사진을 찾아봤으면 했다가도, 이내 2010년이 들어서는 연동한 적이 없다는 것을 알고 실망한 적이 있었다.
언어는 Ruby 를 선택했다. Rails 공부하는 중이기도 하고 해서…
- 첫번째 목표는 iPhoto 에 있는 정보를 Sqlite DB 로 옮기기.
- 두번째 목표는 Flickr 에 있는 정보를 Sqlite DB 로 옮기기.
- 마지막 세번째 목표는 iPhoto 에는 있지만, Flickr 에는 없는 사진들을 Upload 하기. 이 때, KEY 값은 사진이 찍힌 날짜( PHOTO_TAKEN ) 으로 잡았다.
Sequel 과 Flickraw 두개의 gem 의 도움으로 간단히 작성이 가능했다.
현재, 약 4천개 정도 업로드 할 사진이 있음을 파악하고 업로드 중에 있다. 한시간에 대략 170개씩 올라가고 있다.
현재 버젼의 가장 큰 문제점으로는
- PHOTO_TAKEN 정보가 없거나 틀린 것이 꽤 있다. 대표적인 것이 동영상 AVI 파일이다. 이것들은 옮겨진 시간등이 기준으로 삼아진다. 그래서 이것들을 배제하거나, 아니면 다른 방식으로 관리가 필요하다.
- 10시간 정도를 돌려도 1700개 밖에 못올리니깐 DB Record 를 뽑아놓고, 10시간째 돌리고 있으니, TIMEOUT 에러가 나서 중간에 멈춰선 경우가 있다. 다른 방식이 필요하겠다.
사실 하도보니 욕심이 난다.
- 최초에 기대를 했던, Tag, Title, Description 에 대한 Sync 기능. iPhoto 에서 특정 사진에 대해서 정보를 편집하면 그것이 Flickr 에도 반영하기. PHOTO_TAKEN을 KEY로 해서 싱크 구현은 가능 할 듯 한데, 생각보다 복잡할지도…
- iPhoto 내에는 인물 인식에 대한 정보도 있다. 이거 대충 보니, 좌표까지 있어서, Flickr 에 반영도 가능 할 것 같다.
- 역으로, Flickr 에는 있지만, iPhoto 에는 없는 것을 가져오는 기능 구현.
언제 다시 맘먹고 업그레이드 할 지 모르겠지만, 그래도 올해 사진 4천개 파일을 자동으로 올렸다는데 일단 만족한다.
iPad 를 완성하다
먼저 그냥 받침대.
이건 침대 옆 탁자에 놓으려고 샀다. 충전할 때, 널부러져 있는 게 안타까워서 세워줄려고, 그리고, 내심 기대했던 건, 디지털 액자로 쓸까 하는 생각이었다. 하지만, 현실은 자다가 일어나 보면, 역시 널부러져 있다. (이전보다 상처가 더 크다)
밑면에 고무 재질이 맘에 든다. 이거 없었으면 돈값 못한다고 생각했을 텐데…
아이폰, 아이패드용 키보드.
의외로 이거 쓸데가 없다. 들고 다닐 수 없는 모양과 사이즈. 집에서만 쓰란 말인데, 집에서 굳이 아이맥, 맥북 놔두고 아이패드로 글 쓰기를 해야 하는 이유가 뭘까? 역시 결국은 사용용도가 또 다른 충전용 받침대로 귀결된다.
그나마 가장 쓸모가 있을 경우는, 아이폰을 꼽아 놓고, 문자가 왔을 때, 답하는 것이다. 사무실에서 문자가 자주 온다면, 옆에 두고, 문자 답하기에 쓰면 제격일 듯 하지만 overkill 느낌.
키보드가 이동 편리하게 분리가 된다면, 까페에 가져가서 글쓰기 하기엔 딱이겠지만, 생겨먹은건 이동성 고려는 제로.
Camera Kit 에 포함된 USB 연결 어댑터.
아이폰4에 꼽으면 지원되지 않는 기기라고 경고가 뜬다. 하지만, USB 키보드를 붙이면 동작한다. 나름 긴급한 키보드 연결용으로 사용 가능할까?
CameraKit 에 포함된 SD Card Reader.
SD 카드를 삽입하면, iPad 에서 Import 화면이 뜬다. 야외 촬영 나가서, 아이패드랑 이것만 있으면 즉시 즉시 넓은 화면에서 찍은 사진 감상 가능하겠다. 아직은 활동 못해 봄.
나름 기대작. Compass Stand for iPad.
이동용 케이스가 나름 고급 스럽다. 양말처럼 꽉 끼게 들어간다.
빼서 세우면 스탠드가 생긴다. 재질이 티타늄느낌이라 가벼우면서 강한 느낌이 들고, 필요한 부분은 고무 처리 되어 있다. 하지만, 역시 중국산이다 보니 고무 부분이 딱딱 맞아떨어지지는 않는다. (예전 일제 갈은 정교함은 기대 못함)
나름 이동성과 견고함을 갖췄다는 생각이 든다.
뉘여서 쓸 수도 있다. 테이블 위에서 이 각도로 해서 타이핑도 가능하다. 어짜피 iPad 타이핑이 그렇지만, 이 자세에서도 그리 편리하지는 않다.
대망의 가방.
솔직히 아이패드 가방을 동대문 같은데 주문 제작을 의뢰할까 생각할 정도였다. 아이패드가 딱 들어가는 여행용 세면도구 가방을 사용했었는데, 크기는 너무 맘에 들었지만, 문제는 외부에 포켓이 없어서 전화기를 넣어두기에 너무 불편하다는 점이 있었다. 그래서 이 문제만 개선된다면 좋겠는데 생각하고 있었는데, 딱 원하던 제품을 찾아버렸다. 그것도 험하게 쓰기로 유명한 내가 1년이나 써도 끄떡없이 버텼던 booq 에서 나온 제품.
앞쪽에는 지퍼백이 있어서, 지갑 같은 것을 넣어 둘 수 있다.
뒷쪽에는 전화기 2대를 꼽을 수 있고, 볼펜 2개를 꼽을 수 있다. 그리고 그 앞쪽으로 다른 것들을 수납할 공간이 있다. 나는 Egg 를 넣어놓는다.
안쪽에는 한쪽면은 아이패드 다른 한쪽면에는 두군데로 갈라져 있는데, 보통은 케이블이나 보조배터리를 넣어 둔다. 그리고 가운데 공간에 수첩을 넣어둔다.
첨에는 원하는 모든 것을 갖춘 가방이라 너무 기뻤는데, 쓰다보니 느끼는 점이 패딩이 너무 두껍다는 점이다. 아이패드 하나 보호하려고 이렇게까지 할 필요가 있을 정도로 두껍다. 만만치 않은 두께의 가방이지만, 아이패드 하나만 넣으면 빵빵해 진다. 수첩도 하나 넣기가 힘들 정도다. 나같이 아이패드 수첩 지갑 이렇게 3개만 넣으면 둥그런 모양이 될 정도다. 가운데 패딩은 빼고 모서리부분만 적당히 했으면 공간도 확보하고 안전성도 확보하지 않을까 하는 아쉬움이 든다.
아마 곧 해결한 제품이 나오지 않을까 기대한다.
이로써, 아이패드 주변기기 지름을 마친다.
Ruby 에서 plist 를 이용한 plist 파일 변환
Ruby 에서 plist gem 을 이용해서, iPhoto 에서 쓰이는 plist 파일을 가져와서 뿌려봤다.
대략, 6M 정도 크기의 plist 읽어서 뿌리는데, 53초 걸린다. 거의 50초동안 읽어서 내부구조로 바뀌는 데 쓰이고, 출력하는데 3초 정도 걸린다. 배치에서 쓸 경우, 그래도 대략 참을 수 있는 정도?
require 'rubygems'
require 'plist'
require 'yaml'
result = Plist::parse_xml('AlbumData.xml')
puts result.to_yaml
아래 코드를 이용해서 iPhoto 에 바로 연결을 해서, 뿌려보니, 1분35초가 걸린다. 하지만, 위 코드와 다른 점은 바로 시작한다는 점.
require 'rubygems'
require 'time'
require 'osx/cocoa'
include OSX
OSX.require_framework 'ScriptingBridge'
iPhoto = SBApplication.applicationWithBundleIdentifier_("com.apple.iPhoto")
puts iPhoto.photos.count
iPhoto.photos.each do |photo|
puts photo.name
puts photo.date.timeIntervalSince1970.to_i
end
ruby gems
gem install package
로 인스톨 한 다음, rb 파일 내에서 require 로 불러도 찾을 수 없다고 나온다. 이 때에는 반드시,
require 'rubygems' require 'package'
식으로 해 줘야 한다. Gem 도 별도로 path 를 관리하고 있기 때문이란다.
Functional Programming 을 공부해
요즘은 Functional Programming 을 이용해서 하는 경우가 많지 않다.
하지만, 공부를 하면 여러모로 도움이 된다.
특히, Function 단위로 개발하는 습관을 만드는데 큰 도움이 된다.
외부요인에 의존적인 코드보다는 Funciton 단위내에서 독립적으로 코딩하는 습관이 매우 중요하다.
따라서 이런 Functional Programming 을 하면, 강제로 해야 하기 때문에 이런 습관을 키워준다.
이상 Edward Garson 의 의견
요즘은 Functional Programming 을 이용해서 하는 경우가 많지 않다. 하지만, 공부를 하면 여러모로 도움이 된다. 특히, Function 단위로 개발하는 습관을 만드는데 큰 도움이 된다. 외부요인에 의존적인 코드보다는 Funciton 단위내에서 독립적으로 코딩하는 습관이 매우 중요하다.
따라서 이런 Functional Programming 을 하면, 강제로 해야 하기 때문에 이런 습관을 키워준다. Functional Programming 은 OOP 시대에 별난 사람들의 전유물이 아니라, 개발도구의 음과 양이라고 봐야 한다.
이상 Edward Garson 의 의견
고의적 기술 부채
97 Things Every Programmer Should Know 의 eBook 버젼을 사서 열독중인데, 마침 Permission 이 저작자를 밝힌다면, CC 로 해도 좋다고 하여, 블로그에 간단 메모로 기록해 두기로 했다.
1장이, “고의적 기술부채”에 관한 내용이다.
“고의적 기술부채”가 뭐냐면, 개발을 하다보면, 일단은 대충 구현하고 나중에 와서 수정하겠다고 맘먹는 것을 말하는데, 개발자라면 누구나 흔히 하는 일이라 생각한다. 이게 정확히 말하면 “고의적 기술부채”라는 것이다.
비슷하게는 “필연적 기술부채”라는 것도 있는데, 이는 고의가 아니고, 하다보면 어쩔수 없는 종류도 가끔 있다는 것이다.
여기서 주장하는 바는, 이 부채를 남기지 않으면 좋겠지만, 남긴다면 반드시 기록하라는 것이다. 공짜가 아니니깐 말이다. 그래서 그걸 관리하라는 것이다.
행동 지침으로는
– 고의적 기술부채가 있으면 반드시 기록하라.
– 부채는 빨리 갚을 수록 좋다.
– 기록된 부채는 일정 산정이나 이후 계획에서 반드시 반영하라.
간단히 말하면, 빚과 동일한 개념으로 접근하면 되겠다는 것이다.
이상 Seb Rose 의 의견.
97 Things Every Programmer Should Know 의 eBook 버젼을 사서 열독중인데, 마침 Permission 이 저작자를 밝힌다면, CC 로 해도 좋다고 하여, 블로그에 간단 메모로 기록해 두기로 했다.
1장이, “고의적 기술부채“에 관한 내용이다.
“고의적 기술부채”가 뭐냐면, 개발을 하다보면, 일단은 대충 구현하고 나중에 와서 수정하겠다고 맘먹는 것을 말하는데, 개발자라면 누구나 흔히 하는 일이라 생각한다. 이게 정확히 말하면 “고의적 기술부채”라는 것이다.
비슷하게는 “필연적 기술부채”라는 것도 있는데, 이는 고의가 아니고, 하다보면 어쩔수 없는 종류도 가끔 있다는 것이다.
여기서 주장하는 바는, 이 부채를 남기지 않으면 좋겠지만, 남긴다면 반드시 기록하라는 것이다. 공짜가 아니니깐 말이다. 그래서 그걸 관리하라는 것이다.
행동 지침으로는
- 고의적 기술부채가 있으면 반드시 기록하라.
- 부채는 빨리 갚을 수록 좋다.
- 기록된 부채는 일정 산정이나 이후 계획에서 반드시 반영하라.
간단히 말하면, 빚과 동일한 개념으로 접근하면 되겠다는 것이다. 즉, 진짜 친구한테 빌린 돈이라고 생각하면 쉽게 생각이 된다.
이상 Seb Rose 의 의견.