QR 코드의 유용성?

잡담 2012. 1. 30. 17:30 Posted by 알 수 없는 사용자
큐알 코드는 스마트폰이 막 인기를 끌 무렵 함께 많이 등장하더니 요즘은 조용한 듯 합니다. 도저히 알아볼 수 없는 그림인데 폰카를 들이대면 뭔가 인식되기 때문에 왠지 모를 재미가 있었고 그것이 인기의 요인이었다고 생각합니다. 스마트폰을 소수만이 가지고 있을 때는 그들을 특권층으로 만들어주는 몇 가지 기능 중의 하나이기도 했지요.

그래서인지 - 아마도 스마트폰 사용자들에게 하나의 재미를 주기 위함이겠지만 - 상당히 쓸모 없는 곳에 큐알 코드를 그려 넣고 찍어보라고 권유하는 모습을 몇 번 봤습니다. 대표적인 예로는 버스 옆면 광고판이 되겠습니다. 달리는 버스의 광고판은 사실 꽤 쓸만한 광고 영역이지만 그 위에 있는 큐알 코드는 정말 쓸모가 없습니다. 찍어보고 싶다고 하더라도, 폰을 꺼내서 큐알 코드를 인식할 수 있는 앱을 켜고 그걸 찍어볼 시간은 턱없이 부족합니다. 운좋게 정차 시간이 길 수도 있겠습니다만 큐알 코드를 해석해주는 앱은 당연히 카메라를 구동해야 하므로 로딩 시간이 꽤 오래 걸립니다. 제 갤럭시 S를 가지고는 어림없습니다. 하나 덧붙이자면 심지어 제가 본 광고판 중에는 아무런 정보 없이 여기 이 큐알 코드를 찍어보라! 하는 것도 있었습니다. 확신하건데 그 광고주는 돈을 허비했습니다. 그 광고가 도대체 뭔지 아는 사람은 몇 명 없을 것입니다.

http://yfrog.com/mgicpqj 이 링크를 따라가면 볼 수 있는 사진과 멘트는 큐알 코드의 허망함을 잘 표현해주고 있습니다.

큐알 코드의 장점은 디스플레이가 아닌 종이에 인쇄할 수도 있다는 것이고 생각외로 상당히 많은 양의 데이터가 들어갈 수 있다는 점도 있습니다. 오류를 줄이기 위해 데이터 양이 많을 경우 코드의 크기가 커져야 하지만 일정 거리를 두고 촬영을 할 수 있는 환경이라면 큰 문제가 없습니다. 제가 요즘 만들어보고 있는 앱에서도 컴퓨터에서 폰으로 항상 다른 몇 백 바이트의 스트링을 전달할 일이 있는데 이 때 큐알 코드를 선택했습니다. 물론 상당히 편리합니다. 사람이 확인한 정보를 폰에 입력해야 하는 경우, 이 경우가 바로 큐알 코드가 가장 적절히 사용될 수 있는 상황이라고 생각됩니다.

초기의 인기에 비해서는 활용도가 떨어지는 것이 확실해 보입니다. 큐알 코드는 이차원 바코드 중 하나입니다. 결국 바코드가 하던 일, 그 이상을 하기가 어렵습니다. 기존의 일차원 바코드보다 더 많은 데이터를 저장하고 전달할 수 있다는 것이 유일한 장점이 됩니다. 사람들이 항상 소지하는 스마트폰이 그 바코드를 읽게 되었을 뿐인 것이죠. 물론 스마트폰은 일차원 바코드도 읽을 수 있고 큐알 코드가 아닌 다른 이차원 바코드도 잘 읽을 수 있습니다.

이 글은 큐알 코드를 옹호하지도 비난하지도 않는 애매한 글입니다만, 마치 큐알 코드를 찍어보는 기능을 제공해주는 것만으로, "스마트"라는 단어가 유행하는 현 세상에 잘 적응해나가고 있는 것처럼 착각하는 기업들이 너무 웃겨서 생각을 몇 자 적어보았습니다.

'잡담' 카테고리의 다른 글

Optimization  (0) 2011.11.23
IT YELLOW BIRDS 에 첫 글을 남기며...  (0) 2011.10.12

Cloud Computing

Security 2011. 12. 19. 20:38 Posted by 알 수 없는 사용자
Kirsten Ferguson-Boucher, "Cloud Computing: A Records and Information Management Perspective," IEEE COMPUTER, Nov/Dec 2011. 을 읽고 남기는 글입니다. 감상문이라서 그런지 내용에 특별한 주제는 없습니다. 클라우드 서비스에 대한 개인적인 견해로 읽어주시면 좋겠습니다.

"클라우드 컴퓨팅(cloud computing)은 새로운 기술은 아닙니다.  기존에 있던 기술을 바탕으로 컴퓨팅 자원을 전달하는 새로운 방식을 제안하는 것입니다."
라고 글에서는 말하고 있습니다. 여기서 말하는 기존에 있던 기술은 가상화(virtualization)가 가장 적합하겠네요. 예전부터 지금까지, 호스팅 서비스와 같은, 컴퓨팅 자원 제공 서비스는 있어 왔습니다. 하지만 가상화의 발전으로, 이런 서비스를 제공하는 비용이 더욱 낮아졌다는 점이, 더 많은 기업이 데이터를 저렴하게 보관해주겠다 혹은 원격으로 소프트웨어를 제공해주겠다는 세상으로 이끌고 있는 것 같습니다.

웹 검색으로 시작한 구글은 일반 사용자들에게 가장 친숙한 클라우드 서비스 업체라고 생각합니다. 많은 사람들이 개인 이메일을 구글에게 맡기고 있고, 문서를 독스(docs)에 보관하고 일정을 캘린더 서비스에서 관리하고 있습니다. 피카사를 통해 사진을 보관하기도 하지요. 그들의 비지니스 모델까지 여기서 언급할 필요는 없겠습니다만 최근 정식으로 출시된 크롬북만 보아도 그들이 제안하는 - 그리고 이끄는 - 미래를 볼 수 있습니다. 웹 브라우저 하나 달랑 떠 있는 노트북을, 왜 돈을 주고 사는가 싶은 사람이 아직은 많을 것입니다만, 우리가 노트북을 사용하면서 대부분의 시간을 웹 브라우저 상에서 보내고 있다는 것을 깨닫는다면, 그리 이상하지도 않습니다.

이건 오래전부터 제가 생각하고 있는 것인데, 웹 브라우저 상에서 게임이 잘 동작하고 프로그래밍이 가능해지면, 정말 그런 세상이 와도 거부하기 힘들 것 같습니다. 플래시 게임은 이미 많이 있고, WebGL을 통해 더 화려한 게임들도 동작하게 되겠지요. 프로그래밍은 아직 좀 멀어보입니다만 일반 사용자들이 개발할 일이 많지는 않으니 프로그래밍이 주요 걸림돌이 되진 않겠네요. 물론 대세가 될 확률은 아주 낮습니다만, 그래서 크롬북이 뜬금없이 보안을 주 강점으로 내세우고 있긴 합니다만, 약간의 마켓 쉐어를 가져도 이상하진 않을 수준에 현재 도달해 있다고 생각합니다.

VMWare 같은 프로그램을 써보면서 많이 놀랬던 건 그 기술의 발전이었습니다. 너무나도 빠르게 좋아지고 있었거든요. 얼마전에 보니 현재 쓰고 있는 운영체제의 상태를 그대로 가상화할 수 있더군요. 어딘가 출장을 갈 때 이미지를 떠서 디스크에 담고, VMWare 플레이어로 다른 컴퓨터에서 가동시키면 내 작업 환경을 그대로 쓸 수 있을 것입니다. 물론 출장에서 돌아와서 가상화된 이미지를 다시 내 컴퓨터와 동기화 시키는 것은 좀 어려운 작업이 될 수도 있겠습니다만, 출장지에서 많은 작업을 하진 않을테니 그 정도는 수동으로 해도 괜찮겠지요. 이 정도의 기술 발전은 stateless PC라고 부르기도 하는, 이미지에 내 컴퓨터를 담고, 어떤 PC든 가서 부팅하여 사용하는 그런 식의 세상을 만들 수도 있겠다는 생각이 듭니다. 좋은 하드웨어를 저렴한 가격으로 사용할 수 있게 하는 기업이 수 많은 stateless PC를 여러 곳이 넓게 제공하기만 한다면 말이죠.

사실 가상화는 앞서도 언급했듯이 서버 쪽에서 훨씬 이득이 많습니다. 컴퓨팅 자원이 정해진 하드웨어 상에서 상황에 맞게 아주 효율적으로 가상화 이미지들이 옯겨 다닐 수가 있게 되고, 덕분에 하드웨어를 백퍼센트 활용할 수 있다는 점에서 말이죠. 가상화의 발전으로 서비스 제공자는 싼 가격에 사용자를 끌어들이고 사용자도 자신이 직접 하드웨어와 네트워크를 구입하여 서비스를 설정하는 것보다 클라우드 서비스를 이용하는 것이 훨씬 저렴한 시대가 되었습니다. 구글 어플리케이션의 경우, 도메인만 가지고 있으면 50인까지 무료로 제공해주고 있지 않습니까? 작은 사업체에서는 메일 서버, 문서 공유 서버, 홈페이지 서버를 둘 필요도 없는 것이지요.

갑자기 내 회사가 잘 되어 사용자가 폭주하고 사원이 늘어나도 일은 쉬워집니다. 서버를 증축하고 네트워크 대역폭을 늘리고 할 필요가 없이 클라우드 서비스에 돈을 좀 더 납부해주면 알아서 해주니까요.

데이터를 잃어버릴 일도 별로 없습니다. 클라우드 서비스 업체들은 백업에 열중할테니까요. 만약 데이터를 분실하는 사건이 발생하고 이것이 알려지면 사람들은 그 업체를 떠날 것이기 때문에 업체들은 최선을 다할 것입니다. 그리고 그들은 전문가를 뽑아서 관리할 것이기 때문에 데이터 자체의 안전성(integrity) 뿐만 아니라 보안(security)에서도 유리할 가능성이 높습니다.

물론 안 좋은 점도 많겠지요. 우선 클라우드 서비스 업체가 항상 서비스를 잘 제공해준다는 보장(availability)이 없습니다. 가끔 지메일이 열리지 않아 답답함을 느끼는 사용자들이 계실 것입니다. 많은 클라우드 서비스 제공자들이 광고를 할 때 99% 또는 99.99%의 가용성(availability)을 제공한다고 하지만 그건 모를 일이지요.

클라우드 서비스 업체를 믿을 수 있을 것인가 하는 문제도 있습니다. 그들이 마음만 먹으면 우리 회사의 기밀 문서를 열어볼 수 있을 것이고, 내 메일을 읽을 수도 있을 것입니다. 이런 점에서 Free Software Foundation의 리차드 스톨만 씨는 클라우드 서비스에 대한 큰 반감을 표현하기도 했지요. 개인적으로는 저 역시 이 문제가 클라우드 서비스를 좋게 보기 힘든, 클라우드 서비스가 가지는 가장 큰 단점으로 보고 있습니다.

제가 보안 전공이라 그럴 수도 있겠습니다. 이걸 해결하기 위해서는 모든 것을 개인이 관리하고 네트워크를 이용할 때는 항상 암호화/복호화 작업을 스스로 수행해야 하는데 그렇게 할 사람이 많을지는 모르겠습니다. 예를 들어, 내 카카오톡 메시지를 누가 보면 안 되기 때문에, 메시지를 보낼 때마다 내 폰이 암호화하고 메시지를 받을 때마다 복호화한다면 속도도 느리고 배터리도 더 빨리 닳게 되는 것이지요. 그런 서비스가 성공할 가능성이 높아 보이진 않습니다. 사용자 참여의 문제 외에도 사업자 측에서의 비지니스 모델 상 이런 서비스가 나오긴 힘들긴 합니다. 여기에 대한 이유까지 이야기하기엔 글이 너무 길어졌네요.


'Security' 카테고리의 다른 글

NFC의 장단점?  (0) 2011.10.14
NFC 어플리케이션  (0) 2011.10.14
물건 분실을 파악하는 좋은 방법?  (0) 2011.10.14
RFID Tag Coupling  (0) 2011.10.14
가장 비싼 1바이트의 실수  (0) 2011.10.14

[EFL 소식] EFL 1.1/1.5 베타 배포 (2011.11.28)

EFL, Enlightenment 2011. 11. 30. 08:44 Posted by 알 수 없는 사용자
[ EFL 게시물 목차 : http://yellowbirds.tistory.com/1 ]

안녕하세요? 천재태지 서주영입니다.
EFL 1.1/1.5 알파가 배포된지 2주가 채 안돼서 베타 버전이 배포되었습니다.
심각한 버그 수정 등을 거쳐 곧 정식 1.1/1.5 버전이 나올 것 같군요 :)

EFL 1.1/1.5 베타 배포

2011년 11월 28일 오전 10시

칼슨 하이츨러- 2011년 11월 28일 오전 10시

여러 Enlightenment 컴포넌트의 베타 버전을 배포합니다.

  • Eina 1.1.0 - [GZ] [BZ2]
  • Eet 1.5.0 - [GZ] [BZ2]
  • Evas 1.1.0 - [GZ] [BZ2]
  • Ecore 1.1.0 - [GZ] [BZ2]
  • Embryo 1.1.0 - [GZ] [BZ2]
  • Edje 1.1.0 - [GZ] [BZ2]
  • Efreet 1.1.0 - [GZ] [BZ2]
  • E_dbus 1.1.0 - [GZ] [BZ2]
  • Eeze 1.1.0 - [GZ] [BZ2]
  • Expedite 1.1.0 - [GZ] [BZ2]
  • Evas Generic Loaders 1.1.0 - [GZ] [BZ2]
아래는 원문입니다.
출처 : http://www.enlightenment.org/p.php?p=news/show&l=en&news_id=36

New EFL release cycle 1.1/1.5 BETA

Nov 28, 2011 at 10:00 AM

Carsten Haitzler - Nov 28, 2011 at 10:00 AM

We'd like to announce a new release cycle beta release of several Enlightenment components

  • Eina 1.1.0 - [GZ] [BZ2]
  • Eet 1.5.0 - [GZ] [BZ2]
  • Evas 1.1.0 - [GZ] [BZ2]
  • Ecore 1.1.0 - [GZ] [BZ2]
  • Embryo 1.1.0 - [GZ] [BZ2]
  • Edje 1.1.0 - [GZ] [BZ2]
  • Efreet 1.1.0 - [GZ] [BZ2]
  • E_dbus 1.1.0 - [GZ] [BZ2]
  • Eeze 1.1.0 - [GZ] [BZ2]
  • Expedite 1.1.0 - [GZ] [BZ2]
  • Evas Generic Loaders 1.1.0 - [GZ] [BZ2]

[ EFL 게시물 목차 : http://yellowbirds.tistory.com/1 ]

[EFL 소식] EFL 1.1/1.5 알파 배포 (2011.11.16)

EFL, Enlightenment 2011. 11. 26. 01:41 Posted by 알 수 없는 사용자
[ EFL 게시물 목차 : http://yellowbirds.tistory.com/1 ]

안녕하세요? 천재태지 서주영입니다.
오랜만에 EFL 배포 소식을 전합니다. 지난 1월 29일 1.0 배포 및 5월 25일 1.0.1 배포 이후 첫 배포 버전입니다.
라이브러리 대부분은 그동안 변경량이 많았기 때문에 1.0.2 가 아닌 1.1 로 버전이 뛰었습니다.
eet 는 1.4.1 에서 1.5.0 으로 버전업되었습니다.
그리고 지난 1.0.1 버전에 없던 expedite 과 evas generic loaders 가 추가되었습니다.

참... 지금 이 글을 작성하는 시점엔 이미 1.1/1.5 베타가 나왔군요 :)
한 줄 밖에 안되지만, Enlightenment.org 공식 웹사이트에 올라온 글을 간단히 번역해봤습니다.

새로운 EFL 릴리스 주기 1.1/1.5 알파

2011년 11월 16일 오전 10시

칼슨 하이츨러- 2011년 11월 16일 오전 10시

여러 Enlightenment 컴포넌트의 새로운 알파 릴리스 주기를 시작합니다.

  • Eina 1.1.0 - [GZ] [BZ2]
  • Eet 1.5.0 - [GZ] [BZ2]
  • Evas 1.1.0 - [GZ] [BZ2]
  • Ecore 1.1.0 - [GZ] [BZ2]
  • Embryo 1.1.0 - [GZ] [BZ2]
  • Edje 1.1.0 - [GZ] [BZ2]
  • Efreet 1.1.0 - [GZ] [BZ2]
  • E_dbus 1.1.0 - [GZ] [BZ2]
  • Eeze 1.1.0 - [GZ] [BZ2]
  • Expedite 1.1.0 - [GZ] [BZ2]
  • Evas Generic Loaders 1.1.0 - [GZ] [BZ2]
아래는 원문 내용입니다.
출처 : http://www.enlightenment.org/p.php?p=news/show&l=en&news_id=35

New EFL release cycle 1.1/1.5 ALPHA

Nov 16, 2011 at 10:00 AM

Carsten Haitzler - Nov 16, 2011 at 10:00 AM

We'd like to announce a new release cycle alpha release of several Enlightenment components

  • Eina 1.1.0 - [GZ] [BZ2]
  • Eet 1.5.0 - [GZ] [BZ2]
  • Evas 1.1.0 - [GZ] [BZ2]
  • Ecore 1.1.0 - [GZ] [BZ2]
  • Embryo 1.1.0 - [GZ] [BZ2]
  • Edje 1.1.0 - [GZ] [BZ2]
  • Efreet 1.1.0 - [GZ] [BZ2]
  • E_dbus 1.1.0 - [GZ] [BZ2]
  • Eeze 1.1.0 - [GZ] [BZ2]
  • Expedite 1.1.0 - [GZ] [BZ2]
  • Evas Generic Loaders 1.1.0 - [GZ] [BZ2]

[ EFL 게시물 목차 : http://yellowbirds.tistory.com/1 ]

Optimization

잡담 2011. 11. 23. 14:28 Posted by 알 수 없는 사용자
논문을 읽다 optimization에 대한 좋은 정의로 생각되는 문구가 있어 기록합니다.

Roger Needham이라는 분의 정의입니다.
Optimization is the process of taking something that works and replacing it with something that almost works, but costs less.
당연한 소리 아닌가? 할 수 있지만 이렇게 간결하게 표현하기는 쉽지 않을 것 같네요.

'잡담' 카테고리의 다른 글

QR 코드의 유용성?  (1) 2012.01.30
IT YELLOW BIRDS 에 첫 글을 남기며...  (0) 2011.10.12

추천 크롬 확장 프로그램 - Turn Off the Light

Web/Web Browser 2011. 11. 15. 17:57 Posted by 알 수 없는 사용자
구글 크롬 확장 프로그램 하나 소개합니다. 확장 프로그램의 이름은 이 글의 제목과 같고, 링크는 http://goo.gl/yK5xX 입니다.

이 확장 프로그램은 구글 크롬이 처음 제작되어 배포되기 시작했을 때 크롬에 대한 소개 영상에도 포함되어 있는 아주 오래된 확장 프로그램입니다. 유투브와 같이 영상을 플레이할 때 이 프로그램을 사용할 수 있으며, 사용 가능할 때는 주소창의 오른쪽에 전구 표시가 뜹니다. 유투브의 경우에는 프로그램 옵션 설정에 따라 자동으로 실행되기도 합니다. 그외의 경우에는 전구 아이콘을 눌러 실행할 수 있습니다.

이 확장 프로그램이 하는 일은 영상이 플레이되는 영역을 제외하고 나머지를 어둡게 만드는 것입니다. 의외로 이렇게 하면 영상에 집중할 수 있게 됩니다. 유투브의 경우 전체 화면 버튼을 누르면 480p 이상으로 다시 버퍼링을 시작하는 경우도 많고, 유투브를 비롯한 많은 동영상들이 전체화면으로 보기에는 화질이 그리 좋지 못한 경우도 많습니다. 이런 이유로 전체화면보다는 그냥 동영상을 보시는 분에게 좋겠지요. 시선이 분산되는 것을 상당히 막아줍니다. 아, 항상 전체화면으로 보시는 분에게는 별로 필요가 없겠네요.

백문이 불여일견입니다. 위 링크를 따라가시면 소개 동영상을 보실 수 있습니다.

[ EFL 게시물 목차 : http://yellowbirds.tistory.com/1 ]
안녕하세요? 천재태지 서주영입니다.

ecore_timer 는 EFL 에서 사용하는 타이머입니다.
타이머에 원하는 주기와 콜백을 설정해놓으면 매 주기마다 콜백이 불리게 됩니다. 타이머는 어플리케이션 제작 시에 흔히 사용하기 때문에 EFL 에서도 타이머를 제공합니다.

timer 를 생성하는 함수는 아래와 같습니다.
EAPI Ecore_Timer *                 
ecore_timer_add(double        in,  
                              Ecore_Task_Cb func,
                              const void   *data)
첫번째 인자로 double 형으로 주기를 입력 받습니다. 두번째 인자로 주기마다 불릴 콜백 함수를 입력받고, 마지막에는 콜백함수에 넘겨줄 사용자 데이터를 입력받습니다.

[유의사항 1 - 타이머의 주기]
기본적으로는 정해놓은 주기마다 콜백이 불리지만, 한가지 유의해야할 점은, 정확하게 해당 주기 마다 타이머가 불리는 것이 아니라
해당 주기의 시간이 초과했을 때 콜백이 불린다는 겁니다. 즉, 주기를 1.0 초로 설정해놓으면 최초 시간의 1.01 혹은 1.02 초 뒤에 콜백이 불릴 수 있다는 것입니다. 이 점을 잘 고려해서 사용해야 합니다.

[유의사항 2 - 타이머 종료]
타이머를 종료하는 방법은 두 가지가 있습니다.
첫번째는 ecore_timer_del() 을 이용하는 방법이고 두번째는 타이머에 걸어둔 콜백에서 ECORE_CALLBACK_CANCEL 을 리턴하는 방법입니다.  
ecore_timer_del() 은 원하는 시점에 타이머를 종료하는 방법인데, 이 함수의 원형은 아래와 같습니다.
EAPI void *                         
ecore_timer_del(Ecore_Timer *timer) 
ecore_timer_add() 를 사용할 때 리턴받은 포인터를 ecore_timer_del() 에 인자로 넣어주면 됩니다.

그리고
타이머 콜백에서 ECORE_CALLBACK_CANCEL 을 리턴하는 경우 타이머를 더이상 사용하지 않고 폐기시키겠다는 의미입니다. 만약 타이머를 계속 돌리고 싶다면, ECORE_CALLBACK_RENEW 를 리턴하시면 됩니다.

이 두가지 용법을 알고 상황에 맞게 적절하게 사용하셔야 합니다. 

유의사항 3 -  타이머 변수 처리)
이번 유의사항이 가장 중요한 겁니다. 타이머에 대한 포인터를 변수에 저장해놓을 때,
타이머를 삭제한 경우 타이머 포인터를 NULL 로 초기화해줘야 합니다.
예를 들어, 아래와 같은 코드가 있다고 했을 때
Ecore_Timer *my_timer = ecore_timer_add(1.0, _my_timer_cb, NULL);
...
...
if (my_timer)
   ecore_timer_del(my_timer);
ecore_timer_del() 을 실행하는 순간 타이머가 종료됩니다.
그런데 만약 ecore_timer_del() 을 한 뒤에 다시 my_timer 를 체크하고 ecore_timer_del() 을 실행하면 어떻게 될까요?
 Ecore_Timer *my_timer = ecore_timer_add(1.0, _my_timer_cb, NULL);
...
...
if (my_timer)
   ecore_timer_del(my_timer); ---> (1)
...
...
if (my_timer) ---> (2)
   ecore_timer_del(my_timer);
얼핏 생각하면 이미 타이머가 종료되었기 때문에 ecore_timer_del() 은 아무것도 하지 않을 것 같지만, 실제로는 아래와 같은 에러 메시지를 출력합니다.
ERR<6750>:ecore ecore.c:441 _ecore_magic_fail() 
*** ECORE ERROR: Ecore Magic Check Failed!!!
*** IN FUNCTION: ecore_timer_del()
ERR<6750>:ecore ecore.c:451 _ecore_magic_fail()   Input handle is wrong type
    Expected: f7d713f4 - Ecore_Timer (Timer)
    Supplied: 008c2dc1 - <UNKNOWN>
ERR<6750>:ecore ecore.c:454 _ecore_magic_fail() *** NAUGHTY PROGRAMMER!!!
*** SPANK SPANK SPANK!!!
*** Now go fix your code. Tut tut tut!
아주 자극적인 메시지 입니다. EFL 의 창시자인 Rasterman 의 말에 따르면 '자극을 받아서 어플리케이션을 고치도록 이런 메시지를 만들었다!'라고 합니다. 이 메시지를 보면 기분이 언짢아지겠죠...? 일반적인 개발자라면 메시지를 보고 원인을 찾아보고 문제를 해결하려고 하지만, 신기하게도 대부분 이런 경고를 무시합니다.

이 문제가 발생한 원인은, 위 코드에서 (1) 번 과정에서
my_timer 가 가리키는 타이머 자체는 종료시켰지만, 어플리케이션에서 로컬에 저장하고 있는 my_timer 라는 포인터 변수의 값은 그대로 있기 때문입니다. 즉, 타이머를 종료시킨 후에는 my_timer 가 쓸데없는 곳을 가리키게 됩니다. 참고로 이를 dangling pointer 라고 합니다.
그렇기 때문에 (2) 번 과정에서 my_timer 에 쓸데없는 값일지라도 값이 있기 때문에 조건문 안으로 들어가서 ecore_timer_del() 을 수행하게 됩니다. 그런데 my_timer 가 가리키는 곳에는 타이머가 없기 때문에 위와 같은 에러 메시지를 출력합니다.

그러므로 타이머를 종료할 때는 타이머를 가리키는 변수를 항상 NULL 로 초기화해야 합니다.
Ecore_Timer *my_timer = ecore_timer_add();
...
...
if (my_timer)
  {
     ecore_timer_del(my_timer);
     my_timer = NULL;
  }
그리고 ecore_timer_del() 이 아니라 콜백의 리턴값을 이용하여 타이머를 종료할 때도 타이머를 가리키는 변수를 항상 NULL 로 초기화해야 합니다.
Eina_Bool
_my_timer_cb(void *data)
{
   my_timer = NULL;
   return ECORE_CALLBACK_CANCEL;
}
이는 비단 EFL 의 문제가 아니라 C 언어를 사용하는 프로그램에서 발생하는 근본적인 문제입니다. 그러므로 앞으로는 이런 종류의 상황에 접했을 때 변수를 적절하게 초기화하는 센스를 발휘하기 바랍니다.

감사합니다. 
[ EFL 게시물 목차 : http://yellowbirds.tistory.com/1 ]

[GIT] 출력물에 색 입히기

Version Control System/GIT 2011. 10. 15. 10:33 Posted by 알 수 없는 사용자
안녕하세요? 천재태지 서주영입니다.

git 을 이용해서 status, diff 등을 했을 때 밋밋한 텍스트가 출력됩니다.
하지만, 아래 설정을 적용하면 status, diff, branch 등을 했을 때 빨간색, 녹색 등의 색이 사용되면서 보기 편해집니다.
그냥 커맨드 창에서 아래 명령어들을 실행하면 됩니다.

$ git config --global color.branch auto
$ git config --global color.diff auto
$ git config --global color.interactive auto
$ git config --global color.status auto

내용을 복사하실 분은 아래 부분을 드래그해서 복사하세요.

git config --global color.branch auto
git config --global color.diff auto
git config --global color.interactive auto
git config --global color.status auto

아래는 git 에 색을 입히기 전 화면입니다.
텍스트가 빽빽해서 내용을 알아보기가 어렵습니다.


< 기본 git 색상 설정 >

아래는 git 에 색을 입힌 화면입니다.
색상때문에 알아보기가 훨씬 수월해졌습니다.


< git 에 색을 입힌 결과 >


만약 색을 설정했다가 다시 없애고 싶으면 위에 설명한 명령어에서 auto 부분을 false 로 하면 됩니다.

'Version Control System > GIT' 카테고리의 다른 글

[GIT] 분산 버전 관리 시스템 GIT  (0) 2011.10.15

[GIT] 분산 버전 관리 시스템 GIT

Version Control System/GIT 2011. 10. 15. 10:30 Posted by 알 수 없는 사용자
안녕하세요? 천재태지 서주영입니다.
GIT 관련 첫 포스팅입니다.



GIT 은 분산 버전 관리 시스템(Distributed Version Control System)중 하나입니다. 아마 다른 사람과 협업을 하기 위해 CVS 나 SVN(SubVersioN)을 사용해보신 분이 계실겁니다.

여러 사람이 공동 작업할 자료를 회사에 모아놓고 그 자료를 각자 수정하고 수정 내역을 공용으로 사용하는 화이트 보드에 기록합니다. 서로 다른 사람이 작업한 내역을 볼 수 있으며 다른 사람이 수정한 자료를 가지고 또 다른 작업을 할 수 있습니다. 이렇게 공동 작업을 할 때 자료를 모아놓고 수정 내역을 정리할 수 있게 해주는 시스템을 '버전 관리 시스템'이라고 합니다.

그런데 다같이 화이트 보드 하나를 가지고 작업을 해야 하기 때문에 불편합니다.
이제 사람들이 자료를 복사해서 각자 자기 집에 가져가서 업무를 하고, 집에 있는 화이트보드에 수정 내역을 기록해둡니다. 나중에 집에 있는 화이트 보드와 자료를 가지고 회사에 가서 자료를 집어넣고 공용 화이트보드에 내 작업 내역을 기록하게 됩니다. 이런 것을 '분산 버전 관리 시스템'이라고 합니다.
각자가 자기만의 작업본과 작업 장소, 화이트 보드를 가지고 있는 겁니다.

한 10년쯤 전에 버전 관리 시스템으로 SVN 을 썼던 기억이 있습니다. 그 당시에는 그럭저럭 문제없이 잘 썼습니다.
그런데 최근 GIT 을 접하고나니 세상이 바뀌었습니다. GIT 은 상상하는 모든 것을 할 수 있습니다. (물론 과장을 많이 섞어서 ㅎ)
즉, GIT 을 가지고 일을 하다가 발생하는 문제들을 어떻게든 풀 수 있다는 말입니다.
GIT 에 대해서 하나하나 알면서 GIT 의 광팬이 되었습니다.
GIT 은 2005년에 Linus Torvalds 가 운을 띄워서 만들어졌으며 SVN 은 2000년에 만들어졌습니다.

이제 GIT 에 대한 블로깅을 시작해볼까합니다. (잊지 않기 위해서 -_-)
GIT 에 대한 정보는 아래 웹사이트에서 얻으실 수 있습니다.

'Version Control System > GIT' 카테고리의 다른 글

[GIT] 출력물에 색 입히기  (0) 2011.10.15

성당과 시장

Open Source / Free Software 2011. 10. 14. 13:27 Posted by 알 수 없는 사용자
Eric Raymond가 쓴 글로 open source에 대한 자신의 생각을 쓴 좋은 글이다. 대학교 3학년 때쯤 읽었으니 거의 10년만에 다시 한 번 읽게 됐다. 다시 읽으면서 역시 좋은 글이라는 것을 또 한 번 느꼈고 일부 맘에 와닿는 내용을 정리했다. 번역된 글이 있으니 읽어보는 것도 좋겠다.

쌍따옴표로 묶인 것은 원문의 표현을 거의 그대로 가져온 것이고, 나머지는 내 생각대로 적은 것이다.

- "좋은 소프트웨어는 개인의 가려운 곳을 긁는 것으로 시작한다."
필요한 것을 만들게 되면 남도 그것을 필요로 하는 경우가 있다. 그게 상당히 일반적인 성질의 것이라면 프로그램은 인기를 얻을 수 있다. 이건 상업용 프로그램(혹은 성당 스타일의 프로그램)과 크게 차별성을 가지지는 않는다고 생각한다. 상업용 프로그램도 모두 다른 사람이 필요로 하고 있다고 파악하고 제작하는 것이니까.

- "좋은 프로그래머는 어떤 프로그램을 만들어야 할 지 알고, 훌륭한 프로그래머는 어떤 프로그램을 다시 만들어야 할 지 안다."
기존 프로그램을 재사용 할 줄 알아야 한다는 이야기다. 모든 것을 혼자 다 다시 만드는 것은 바보같은 짓이 아닌가.

- "개발자들에 대한 빠른 피드백, 그 방법은 잦은 발표(release)"
개발자들이 성취감을 느낄 수 있도록 해준다. 자주 발표될 때마다 내가 기여한 코드가 mainstream에 반영되면 기쁨을 느낄 수 있을 것이다. 어딘가 기여했다는 느낌. 그 프로젝트에 소속되었다는 느낌. 또한 빨리 수정하고 빨리 발표하면 그만큼 디버깅에 중복이 발생하지 않는다. 남이 고친 것을 내가 고칠 필요는 없으니까.

- "누군가에게는 간단할 것이다."
내게는 어려운 문제라도 다른 어떤 사람에게는 간단한 문제일 수 있다. 문제 해결의 속도가 상당히 빨라질 수 있다는 거다. 훈수가 좋은 비유가 될 듯.

- 리누스 토발즈 왈, "문제를 발견하는 사람과 이해하는 사람이 동일할 필요가 없다."
문제(버그)를 발견하는 것이 더 중요하다고 토발즈는 말했다. 하지만 사실 둘 다 중요하다고 본다.
여튼 여기서 말하고자 하는 것은 발견을 잘 하는 사람이 해결을 잘 할 필요는 없다는 것. <좋은 테스터 = 좋은 개발자>일 필요가 없다는 것이다. 오픈 소스 정책을 취하게 되면 수많은 테스터와 수많은 개발자를 내편으로 만들 수 있다. 베타 테스터를 품는 것이 중요하다. 정말로 열정적으로 헌신해 주는 사람들이 있다. 적극적으로 베타 테스터와 소통하고, 리스트에 사람들을 포함시키고 릴리즈가 있을 때마다 발표하고 의견을 듣고 버그 리포트도 받고 소스에 대한 수정본을 보내주는 사람이 있으면 적극적으로 검토하고 취하자. 이렇게 하다보면 베타 테스터 리스트에서 점점 사람들이 빠져나가는 현상이 발생한다고 하는데, 그 이유는 '잘 동작하니 더 이상 듣고 싶지 않다'란다. 이 때쯤 되면 "베타"딱지를 뗄 수 있는 것이 아닐까.

- 사회학에서의 델파이 효과: "비슷하게 전문적인 (혹은 비슷하게 무지한) 관찰자들로 이루어진 대중의 평균적인 의견이 그 관찰자 중 무작위로 뽑은 한 명의 의견보다 더 신뢰할 만하다."
전체의 의견이 그리 바보같지는 않다는 것. 집단 지성이 그리 나쁜 결과로 이어지지는 않는다는 것. 리눅스와 위키피디아를 통해 증명되었다고 생각한다.

- "널리 사용되는 프로그램의 유지, 보수에 들어가는 비용은 40퍼센트 혹은 그 이상이다. 놀랍게도 사용자 수에 큰 영향을 받는다. 사용자가 많을 수록 유지 보수에 더 많은 비용이 들어간다는 것."
왜? 더 많은 사용자가 더 많은 버그를 찾아내기 때문이다. 더 많이 사용되는 윈도우에서 더 많은 취약점이 발견되고 더 많은 악성코드가 제작된다. 윈도우 자체의 보안 결함은 논외로 하자. 더 많은 보안 이슈가 발생하는 건 그만큼 많은 사용자가 있어서 그렇다는 것을 다들 인정할 거다.

- 많은 사용자가 있고 그들과 소통하면  좋은 아이디어를 얻게 되는 경우도 있다. 때로는 그것이 천금같은 것일 수도 있다.
일반 사용자와 오픈 소스에서의 참여자는 다르다. 참여하는 사람들은 그 프로젝트에 소속감을 가지고 있다. 좋은 아이디어가 떠오르면 제공할 의사가 더 많다는 의미도 된다.

- 생택쥐베리 왈: "(설계에 있어서) 완벽함이란 더 이상 추가할 것이 없을 때 이루어지는 것이 아니라 더 이상 버릴 것이 없을 때 이루어진다. (Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away)"
그냥 멋진 말.

- open source project의 leader는 사회성이 좋아야 된다.
어쩔 수 없는 것이다. 어디서든 리더가 되려면 그럴 수밖에. 유시민님의 강연에서 이런 말을 들은 적이 있다. 리더는 두 가지 중 하나를 갖춰야 한다. 엄청 똑똑하거나, 인간적으로 존경스럽거나. 각각 너무 똑똑하니 배신하면 걸리겠지, 이렇게 좋은 분을 내가 배신할 수는 없어라고 생각해서 그렇단다. 재밌는 이야기다. 사실 대규모 open source project의 leader가 되려면 둘 다 갖춰야 할 것 같다. 아무나 못하는 것은 확실하다.