언어와 환경

2주 전부터 미친듯이 진행된 수정요건의 반영으로 인해 개발자들과 평소보다 훨씬 많은 말을 해야 했다.

영어란 참 특이하다.
Native speaker와 같이 있으면 그만큼 수준이 올라가고, 그리 유창하지 못한 사람들과 이야기하면 그만큼 내 수준도 하향평준화 된다.
예를 들어 London에 머무를 때는 소위 ‘버벅거림’이 거의 없이 제법 유창하게 의사소통을 하지만, 같이 있는 스페인인 개발자나 폴란드인 테스터들과 이야기할 때는 종종 막힐 때가 있다.

이런 것이 일반적이라면 비영어권 지역에서 영어를 배우는 것이(예를 들어 한국의 학원에서) 과연 효과가 있을까, 하는 의구심이 든다.
다른 언어도 마찬가지이고.

나만 그런거라면야 뭐, 상관없지만서도.

nGrinder에서 Groovy script 사용시 java.lang.UnsupportedOperationException 발생

nGrinder에서 Groovy Maven Project를 만들어 사용할 때, 특히 IntelliJ를 사용하려면 Import Groovy Maven Project in IntelliJ를 참조하면 된다.

잘 될 것 같았는데 Unit test에서 시작부터 아래와 같은 에러가 발생했다.

한참을 검색해본 결과 Eclipse의 경우 build 설정시 Groovy 라이브러리를 지우는 과정이 있다는 것을 알게 되었다.
혹시나 IntelliJ에서도 같은 문제일까 해서 Groovy libraries를 모두 지웠더니(File > Project Structure) 아무 문제 없이 잘 작동하기 시작했다.

Groovy를 사용하면 종종 예상치 못한 일을 만나게 된다고 하는데 – 예를 들어 “Using Groovy? Prepare for the unexpected!” – 이런 일을 겪을 때면 아무래도 이 언어의 ‘한계’ 같은 것이 느껴진다.

Java 7의 Project Coin 중 몇가지

Java 7 (그리고 8)에 포함된 Project Coin 중 유용하지만 (상대적으로) 자주 언급되지 않은 몇 가지.

Binary Literals

Java 7 이전에는 binary 값으로 무언가 하려 하면 ‘parseX’ 메소드를 써야 했다.
예를 들어 “1100110”을 십진수 102로 변수에 지정하려면 아래와 같았다.

하지만 Java 7 부터는 아래와 같다. (왠지 너무나 당연하다)

또다른 재미있는 것 하나는, 긴 숫자 사이에 ‘_’ (underscore)를 넣어 표현할 수 있다는 것이다. (Ruby에서 아이디어를 가져왔다고 한다)
이 ‘_’는 compiler가 나중에 다 지워버리기 때문에 상관없다.

아래 예를 보면 가독성이 확실히 차이남을 알 수 있다.

TWR(Try-with-resources)

Project Coin 쪽에 본 기능에 대한 제안이 도착했을 때 밝혀진 놀라운 사실 하나는, JDK 내 close()를 사용한 code 60% 이상이 bug를 내포하고 있었다는 것이다. (사실 사용한 resource를 100% 확실하게 close 하는 것이 쉽진 않다)

아래 내용은 TWGJD(The Well-Grounded Java Developer, 2013)에서 가져온 것이다.

코드를 보면 InputStream이나 File (즉 OutputStream) 어느 쪽에서도 뭔 일이 벌어질 수 있고, 특히 이런 식으로 exception이 엉켜있게 되면 문제가 생겼을 때 처리하기 여간 성가신 것이 아니다.

그래서, 아래와 같은 문법이 등장했다.
즉 exception이 발생하게 되면 자동으로 모든 열려있는 resource를 close 해준다.

한가지 주의할 점은, 아래와 같은 code는 ObjectInputStream 생성 중 에러가 발생할 경우 FileInputStream을 close 하지 못할 수 있다.

해결책은, 좀 덜 멋있더라도(?) 분리해놓으면 된다.
아래와 같이.

Windows 10 무료 업그레이드 하지 않기로 했다

이유는,

  • 현재 Windows 7 사용에 아무 문제 없다. 요즈음 대부분 application은 web 용이기 때문에 더더욱.
  • 한국 인터넷뱅킹 환경에서 문제를 일으키는 Edge browser 대신 IE 11을 사용할 수 있다고 하지만, 좀 번거로운 절차들이 필요하다. 하지만 Windows 7에서는 아무 문제 없다.
  • 현재 사용하는 10년 가까이 된 PC를 SSD 장착 후 아무 문제 없이 사용하고 있다. 적어도 Windows 10은 7 보다 시스템 요구사항이 높을 텐데 무리할 필요 없다.
  • Windows 7은 2020년까지 지원을 한다는 것 같으니 그때 가서 새로운 PC를 살 때 같이 구매하는 것이 나을 듯 하다. 노트북을 살 확률이 높고, 그 경우 Windows bundle을 같이 구매하면 될 듯. (아니면 그땐 크롬북을 구매하려나…)
  • 아래 글도 결정에 도움을 주었다.

그러나 윈도우 10 무료 업그레이드는 예전처럼 제품키를 주는 것이 아니라 해당 기기에 대한 디지털 인증을 해주는 방식이라 PC를 교체하거나 업그레이드 할 경우 윈도우 10을 쓰지 못하게 될 수도 있다. MS의 무료 업그레이드 정책이 데스크탑(핵심 부품 교체 가능한) PC가 아닌 노트북이나 태블릿 같은 완제품에 맞춰 책정됐기 때문이다. 그런데 이런 완제품은 어차피 새로 구입할 때 윈도우 10이 설치되어 있을테니 무료 업그레이드에 목을 멜 이유가 없다.

또한 윈도우 7 사용자들이 굳이 윈도우 10으로 넘어가야 할만큼 지금 PC 사용에 불편을 느끼지 않는다는 것도 있다. 윈도우 8/8.1은 처음부터 터치스크린 입력과 태블릿에 초점을 맞춰 억지로 만들었기 때문에 차라리 윈도우 10으로 넘어가는 쪽이 낫지만, 윈도우 7은 키보드와 마우스를 쓰는 전통적인 PC 환경에 완벽히 최적화된 운영체제다. 하드웨어 변경이 필요한 윈도우 10 새 기능은 쓸 수 없는데 괜히 잘 돌아가는 윈도우 7에서 바꿨다가 업그레이드 중에 문제가 생기면 A/S 비용이 나갈 수도 있다.

영화 기법 관련 정보를 찾다가

Vertigo Effect(Dolly Zoom), 몽타주 기법 등에 대해 조금 더 알고 싶어서 루이스 자네티의 ‘영화의 이해’를 다시 펼쳐보았다.

잘 읽히는 책이지만 방대한 양의 정보를 담고 있는 터라 빠르게 읽고 치울 수 있는 책은 아니다.

몇 부분 정독하다가 문득 YouTube에서 관련 컨텐츠를 찾아봐야겠다는 생각이 들어 찾아보았는데 이런, YouTube가 정답이었다.

책과 구글링은 각기 장단점이 있지만, 적어도 단편적인 지식(또는 즉각적인 대답)을 취하는 데에서 책은 더이상 답이 아니다.

로지코믹스

논리학을 좋아하지 않는다 – 라기보다, 논리학이라는 학문을 잘 알지도 못하고, 알려고 시간을 투자하기도 망설이기 때문에 이 책을 읽은 것은 순전히 ‘버트란드 러셀’이란 인물에 대한 호기심 때문이었다.

예전에 읽었던 ‘나는 왜 기독교인이 아닌가’나 ‘러셀의 찻주전자’ 비유 등을 통해 항상 관심을 가졌던 인물인 반면 별로 아는 바가 없었는데, 이 책으로 많은 흥미로운 사실들을 알 수 있었다. 말로만 듣던 19, 20세기의 위대한 사상가들을 일부 경험할 수 있다는 덤도 얻었고.

책의 주인공들은 ‘지도 제작자’로 비유된다.
주인공들은 혼란스러운 실재를 명확한 지도로 환원하려 했다. 즉 실재를 더 단순한 것들로 대체함으로써 논리학이 더 자연스럽게 적용되도록.

그런 면에서 일견 논리학은 매력적인 학문으로 보일지 모르겠으나, 책을 읽고난 후에는 어지간한 광기 없이는 엄두도 못 낼 학문으로 생각이 되었다.
현실은 복잡하기 이를데 없고 모순 덩어리인데 그런 현실에 대해 논리를 기반으로 하는 ‘지도’를 만드려는 과정 자체가 불가능하게 보였기 때문이다.

러셀의 경우 그의 독특한 성격, 불안정성, 신경증이 그를 논리학으로 이끌었으며, 프레게, 러셀, 화이트헤드 역시 훌륭한 학자들이었지만 결국 그들 모두는 실제와 지도를 혼동했는지도 모른다고 작자는 말한다.
예를 들어 교육자로서 비트겐슈타인은 권위와 규칙을 강조한 반면 러셀은 권위에 철저히 반대했다. 하지만 그런 고집으로 그들 둘 다 현실에서 교육자로 성공하지 못했다.
논리학자의 이런 면들은 가족들 역시 불행하게 만들었는데, 러셀의 아들은 정신분열병 진단을 받았고, 손녀는 자살했다. 힐베르트의 아들도 15살때 정신병원으로 보내졌는데 힐베르트는 단 한 번도 아들을 그 후 만나지 않았다고 한다.

결국 나로서는 그런 위대한 논리학자들에게 완전히 공감하기는 어려운 점이 많다.

조만간 ‘행복의 정복’을 읽을 생각인데, 러셀이 어떤 관점에서 저술하였는지 궁금하다.
현실을 배제하고 논리적으로 접근한다면 말 그대로 현실성 없는 공허한 글이 될 것이며, 그렇다고 논리학자로서의 본인의 색깔을 완전히 뺀 채 접근한다면 과연 그 저작이 구닥다리 자기개발서 이상의 것이 될 수 있으려나 싶어서 읽기 주저하게 된다. (그래도 책은 사놓았다)

이 책에는 러셀 말고도 많은 흥미로운 인물들이 등장한다.
가장 인상 깊은 인물은 비트겐슈타인이었지만, 괴델 덕분에 오히려 다음에 읽고 싶은 책은 더글라스 호프스태터의 ‘괴델,에셔,바흐’다. 이번엔 원서로 도전할 생각이다.

모두 다 축구를 좋아하는 것은 아니다

Football Android app을 운영 중, 실시간으로 서비스 되는 경기 내용이 90분 후에는 update가 되지 않는 오류가 있었다.
원인을 찾아보니, 축구 경기는 정확히 90분 후 종료하는 줄 알았던 인도 개발자가 작성한 Backend의 코드가 원인이었다. (크리켓은 좋아한단다)

2년 전 일이고 지금은 꽤나 안정적인데, 오늘 점심을 먹다가 한 스페인 개발자가 오늘 경기(Spain vs. Czech)에 메시가 나오냐고 물어서 먹던 것을 뿜을 뻔 했다.

스페인 사람은 무조건 축구를 좋아한다는 것은 편견이다.
하지만 불안한 맘에 이 친구가 코드 대체 어디를 손 댔는지 확인해야 할 것 같다.

아래는 운영 중인 Football app 소개 동영상.
지금은 Goal+ 란 이름으로 바뀌었다.

Eclipse에 잘 맞는 D2 Coding 글꼴

고정폭 글꼴로 ‘나눔고딕코딩’을 만족스럽게 쓰고 있지만, Eclipse에서만은 예외다.
줄간이 너무 좁아서 가독성이 현저하게 떨어지기 때문.

JetBrains Tool들이나 Sublime Text의 경우 줄간을 자유롭게 조절할 수 있기 때문에 문제가 되지 않지만, Eclipse에서는 줄간을 조절할 방법이 없기 때문에 항상 대체글꼴을 택해야 했다. (순전히 이것때문에 Eclipse 사용을 피해왔었다)

우연히 ‘D2 Coding’을 알게 되어 설치하였는데, 나눔고딕코딩의 분위기를 지키면서 줄간이 적당히 넓어져 너무나 만족스럽다.

http://dev.naver.com/projects/d2coding

이런 정보는 널리 알려야한다.