콘텐츠로 이동

Log

Upgrade to Hakyll 4.8

[Hakyll][] 이 4.8 버전으로 업그레이드 되면서 달라진 점이 하나 있는데, Metadata field가 YAML 형식으로 바뀌었습니다. 이로 인해, 기존의 Data.Map 타입에서 YAML.Object 가 되면서 기존의 Metadata를 이용한 함수를 대부분 고쳐야 했습니다.

예를 들면 match 함수에서 public 인 것만을 추려내서 html을 만드는 데, 이때 쓰이는 함수가 Hakyll 4.7에서는 아래와 같았습니다.

metadataFieldIs :: String -> String -> Metadata -> Bool
metadataFieldIs key value metadata = case M.lookup key metadata of
    Just v  -> value == v
    Nothing -> False

Data.Map 이기에 M.lookup 함수로 찾아서 public인지 아닌지 검사합니다. 하지만, YAML.Object로 변경되었기 때문에, Aeson 라이브러리를 이용하거나 Data.HashMap 을 이용해야 합니다.

다행스럽게도 Hakyll-4.8 에서 비슷한 역할을 하는 함수를 이미 만들어서 제공하고 있습니다 (Jasper 짱!) 바로 lookupString 인데요. Hakyll.Core.Metadata 에 정의되어 있습니다.

그래서 아래와 같이 코드를 간편하게 변경할 수 있었네요.

metadataFieldIs key value metadata =
    case lookupString key metadata of
        Just v  -> value == v
        Nothing -> False

다른 하나는, 이건 YAML에 관련된 이야기 인데, YAML은 on, yes 등의 값을 무조건 Bool로 인식해서 true로 변경하더군요. 그래서 disqus를 표시하는 metadata field가 on 에서 true로 바뀌는 바람에 disqus가 사라져 버려서 찾느라 고생좀 했습니다.

Getting Rid of Ground Bees

지난 주 Lawn Mower로 뒷마당에 무성한 잡초를 깎았습니다. 이 건조한 환경에서도 얼마나 잡초가 잘 자라는지, 이주 만에 엄청 자랐더군요.

잡초를 깎는 데, 마당 한 가운데 꽤 큰 구멍이 보입니다.

마치 다람쥐가 굴을 파놓은 것 같은 모양입니다. '집 근처에 두더쥐나 다람쥐가 있나..' 하고 그냥 지나쳤다가, 잡초를 다 깎은 후 아이들과 놀다가 다시 한번 보았네요.

삽을 들고 구멍을 메울려고 구멍 주위를 파헤치는 순간, 주변에 벌이 몇마리가 나타납니다. '아차!' 싶어서 곧장 두 아이에게 집으로 들어가라고 다그치고 같이 피신을 합니다. 달려오는 길에 벌이 둘째의 다리를 물어버렸네요. 다행히 쏘인 건 아니고 물린 것 같네요.

땅벌을 없애기 위해 이리 저리 찾아보니 몇가지 방법이 있네요.

  1. Home Depot에서 벌 제거용 스프레이를 산다.
  2. 밤에 구멍에 주방세제를 붓고 물을 뿌린다.
  3. 구멍을 Tarp 나 다른 것으로 막아서 굶겨 죽인다.

일단 밤 사이 긴급 조치로 Tarp로 대충 덮어뒀는데, 이게 오히려 악영향을 끼쳐서 벌이 쉴새없이 날아다니게 되어버렸습니다. 결국, 완전 무장을 하고 스프레이로 벌집을 제거하기로 합니다.

Home Depot에 가면 Spectracide 제품 중 벌을 잡는 스프레이를 살 수 있어요. 이게 Foam으로 분사되고 8미터 정도 멀리서도 분사할 수 있어서 꽤 괜찮은 제품입니다. 이걸 사고, 좀 불안한 마음에 방충망과 벽돌도 좀 사기로 합니다.

완전 무장

집에서 바이크 헬멧, 스노우보드 상하의, 글러브로 완벽 무장을 하니 땀이 비오듯 쏟아집니다.

스크린 비닐을 다 뜯고 벽돌도 근처로 옮겨서 만반의 준비를 갖춘 뒤, 잔디깎기 기계가 반쯤 파먹어버린 타프를 걷어내고 스프레이를 분사합니다.

Spectracide

멀리서 길게 죽죽 뻗어나가며 벌집 구멍에 하얗게 막을 형성하네요. 큰 스프레이 통이라 넉넉히 쏴야지.. 하면서 구멍 주변에 뿌리는데 갑자기 압이 약해집니다. -_- Foam으로 나가서 오래 나갈 줄 알았는데, 너무 금방 떨어지네요. 구입할 때 바로 옆 칸에 2개를 한 세트로 팔고 있었는데, 이유가 있었네요.

급하게 대충 구멍 안에 쏘고 급 마무리 합니다. 스크린으로 덮고 벽돌과 페인트 통으로 꾹꾹 눌러서 벌이 못 날아다니게 막아둡니다.

Home Depot에서 사온 호스 정리하는 Reel을 이용해 마당에 널부러진 호스를 감는데, 이미 호스가 휠대로 휘어서 대책없이 꼬이네요. 싼게 비지떡인가 봅니다.

Garden Hose Reel

쭈그려 앉아서 한참을 꼬인 호스를 풀고 있으니, 땀으로 정신이 혼미해지네요. 숨도 막히고, 어쩔 수 없이 대충 감아재끼고, 이따구 싸구려 호스를 판매한 Home Depot에 가서 환불하기로 맘 먹습니다.

아직 완전한 밤이 되질 않아서 밖에서 활동하던 벌이 집에 못 들어가고 방충망 앞에서 맴도네요. 밤에 활동이 아예 없을 때 작업할 걸 그랬나.. 하는 생각도 듭니다. 한방에 다 죽일걸..

Rent a Single House

어느덧 [아파트 갱신 글][renew-apartment] 을 작성한 지 일년이 되어 두번째 갱신 계약서가 날아왔네요. 작년만큼 10% 상승은 아니였지만 금액으로는 거의 비슷한 금액이 올랐습니다. 결국 3천달러를 주고 아파트에 사느냐 아니면 다른 곳을 찾느냐를 결정해야 하는 순간이 되었네요.

지내고 있는 엘란 아파트는 회사와 가깝기도 하고 주변에 미국으로 갓 넘어온 한국 가족이 많이 있기도 하고, 지내기 괜찮았던 것 같습니다. 다만, 가격이 무척 높아진 것, 학교가 형편없이 안좋은 것 (조사해 본 바로는 꽤...)이 꽤 큰 비중을 차지하네요.

아이가 곧 학교를 입학할 나이가 되어서 이참에 옮기기로 결정하고 이리저리 집을 알아보았습니다. 아파트를 제외하고 타운하우스나, 듀플렉스, 싱글하우스를 찾아보니 높아진 렌트비가 실감이 나네요. 적당한 학군을 찾아보니 듀플렉스조차 3천불이 넘네요. 조금 더 눈을 높이면 싱글하우스가 3천불 후반까지 올라가고, 최상의 학군은 5천불도 보통이라 여겨질 정도입니다.

제가 그리 뛰어난 사람은 아니라 눈 높이를 많이 낮춰야 했네요. 3주동안 열심히 쫓아다니고 지원서를 넣고 떨어지고를 반복하다 듀플렉스가 하나 되었습니다. 계약금을 송금하기 전, 지인 집 근처에 저렴한 집 하나가 나왔는데 꽤 괜찮은 가격대로 나왔더라구요. 그래서 바로 전화하고, 찾아가서 사정하고, 적극적인 의사 표시를 한 덕분에 싱글하우스로 집을 구할 수 있었습니다.

이번 렌트를 구하면서 보니, 신용도와 급여가 가장 중요한 것으로 보이지만, 그 기준을 만족하는 지원자가 참 많았습니다. 그 중에서 되려면 무엇보다도 적극적인 의사 표시가 가장 중요한 것 같습니다. 이 집에 꼭 살고싶다는 의사표현으로 편지가 될 수도 있고, 지원서에 Security Deposit을 같이 내는 방법도 있고 몇가지 방법이 있을 수 있어요. 전 매물이 올라오자마자 얼마 안되서 글을 발견하고, 바로 전화를 걸고 thank you email을 보내면서 제 급한 사정을 같이 이야기 했었네요. 그 이메일 덕분에 에이전트가 그 다음날 집을 보여줄 생각이 들었다고 하네요. 그리고 그 날 제가 바로 개인수표로 Security Deposit을 같이 주고, 그날 크레딧 리포트와 급여자료등을 서면으로 같이 들고가서 줘서 일이 일사천리로 진행될 수 있었던 것 같아요.

비록 생각했던 금액의 상한선으로 구하긴 했지만 주변 시세보다 400~500불 저렴하게 잘 구한 것 같네요. 아이들도 뒷마당에서 놀면서 아주 좋아할 것 같습니다.

한 번 싱글하우스를 가면 아파트로 다시 못 돌아간다던데, 이대로 지내다가 집을 살 수 있는 기회가 오면 좋겠습니다. :)

Hakyll Route for Metadata date Field

블로그 URL을 보면 이전과는 좀 달라졌습니다. 예전엔 url이 blog/YYYY-MM-DD-post.html 방식이었다면, 새로운 URL은 blog/YYYY/MM/DD/post.html 형태로 바뀌었습니다.

변경을 한 이유는, 블로그 글이라면 제목과 연관된 URL이 유지되어야 하는데 그 앞에 항상 년,월,일 이 디렉토리 형태도 아니고 같은 묶음으로 다니는게 조금은 이치에 맞지 않는 것 같았기 때문입니다. 그래서 아카이브 형태로 년,월,일 을 디렉토리로 구분하였습니다. 글을 자주 쓰는 게 아니니 년,월,일 보다 2016, 2015 해서 년만 넣어도 충분하겠지만 일단은 이렇게 가는 걸로 하죠. ㅎㅎ

기존에 블로그에 글을 쓸 때에는 blog/ 디렉토리 밑에 URL과 동일했던 마크다운 파일을 두고 글을 썼습니다. 지금이야 글이 꼴랑 20개 남짓이라 문제가 없지만, 나중에,, 아마 한 5년은 걸리겠지만, 나중에 100개 이상이 되었을 때 한 폴더에 모든 글을 다 보관한다는 건 조금은 번거로운 일이 될 것 같아서 방식을 바꾸기로 했습니다.

새로운 방식은, blog/ 밑에 어느 폴더에 두더라도 blog/YYYY/MM/DD/post.html 형태로 바꾸도록 변경했습니다. Hakyll에서는 URL을 결정하는 Rule을 Route라는 이름으로 만들었습니다. 이 Route에 원하는 규칙을 넣으면 그 규칙대로 대상 URL이 결정됩니다.

아래의 코드는 위의 blog/ 를 위해 만든 규칙입니다.

-- | Route based on metadata field 'date' -------------------------------------
dateRoute :: FilePath -> Routes
dateRoute prefix = metadataRoute (f prefix)
  where
    f p md = customRoute $ pullDateToFilePath p md

-- | Add prefix then compose YYYY/MM/DD/post.html format ----------------------
pullDateToFilePath :: FilePath -> Metadata -> Identifier -> FilePath
pullDateToFilePath p m i = p </> (convertDateToFilePath m i)
  where
    convertDateToFilePath md id' = convertLocalTimetoISO (md M.! "date") (M.lookup "slug" md) $ toFilePath id'
    -- convertLocalTimetoISO :: String -> Maybe String -> FilePath -> FilePath
    convertLocalTimetoISO d (Just s) _ = toISO d </> s <.> ".html"
    convertLocalTimetoISO d Nothing fp = toISO d </> chopDayFromFileName fp
    chopDayFromFileName fp' = replaceAll "[0-9]{4}-[0-9]{2}-[0-9]{2}-" (const "") $ takeFileName fp'
    toISO dateString = formatTime defaultTimeLocale "%Y/%m/%d" $ readTimeFromMetadataString dateString

-- TODO: Make more format
readTimeFromMetadataString :: String -> UTCTime
readTimeFromMetadataString dateString = parseTimeOrError False defaultTimeLocale "%B %e, %Y" dateString

일단 post 내의 메타데이터 date 를 이용하기 위해 metadataRoute 가 사용됩니다. 이 metadataRoute 는 함수 인자를 받는데 Metadata -> Route, 즉 Metadata를 입력으로 받고 결과가 Route인 함수를 인자로 받습니다.

Metadata를 이용해 YYYY/MM/DD 형식으로 변경해야 하므로 customRoute를 사용해서 원하는 형태로 바꿔주도록 합니다. customRoutemetadataRoute와 비슷하게 함수 하나를 인자로 받습니다. 이 함수는 Identifier -> FilePath 타입으로 Identifier를 입력으로 받고 최종 URL인 FilePath를 결과로 내는 함수입니다.

f p md = customRoute $ pullDateToFilePath p md

Higher Order Function을 이용해서 pullDateToFilePath 함수를 Identifier -> FilePath 처럼 인식되게 했습니다. 실제 pullDateToFilePath의 타입은 pullDateToFilePath :: FilePath -> Metadata -> Identifier -> FilePath 이죠. 즉, FilePath, Metadata, Identifier를 입력 받아서 FilePath를 리턴하는 함수입니다.

MetadataData.Map 타입이라 원하는 필드, date, slug 를 검색할 수 있습니다. 이를 검색해서 date는 YYYY/MM/DD 형태로 바꿔주도록 하고 slug가 있다면 사용하고 없다면 파일 이름을 사용하도록 합니다.

그래서 slug를 검색할 때는 M.lookup "slug" md 로 해서 Maybe Monad로 결과를 받고 Just 또는 Nothing으로 처리합니다.

    convertDateToFilePath md id' = convertLocalTimetoISO (md M.! "date") (M.lookup "slug" md) $ toFilePath id'
    -- convertLocalTimetoISO :: String -> Maybe String -> FilePath -> FilePath
    convertLocalTimetoISO d (Just s) _ = toISO d </> s <.> ".html"
    convertLocalTimetoISO d Nothing fp = toISO d </> chopDayFromFileName fp

이 방식을, sky/log/ 에도 적용해서 그 부분도 YYYY/MM/DD 형식으로 저장되도록 했습니다.

이번 수정을 하면서 Haskell의 깔끔한 구현 방식이 논리적으로 생각하는 흐름에 맞게 잘 되어있구나, 라는 생각이 다시 한번 들었습니다. 생각의 흐름 그대로 top down이나 bottom up 구현을 해 나갈 수 있어서 큰 무리 없이 수정이 가능했습니다.

영주권

2년하고 한달, 그리고 9일이 걸렸습니다. 2014년 1월 14일 미국땅을 밟고 이 시간이 지나서 영주권이 승인되었네요. 2년이란 시간이 벌써 흘렀는지도 실감이 나지 않을 정도로 빠르게 지나간 것 같네요. 영주권을 받지 못해서 오랫동안 고생하시는 많은 분의 이야기를 인터넷에서 접하고 귀로 전해 들은터라 내심 걱정이 많이 되었습니다. 영주권을 위해서 다른 회사로 이직할 기회도 거절하고 남아있었는데, 결국 시간이 지나니 나오네요.

중간에 문제가 없었다면 한 3개월 더 빨리 나올 수 있었겠지만, 이제 그 모든 게 지나간 일이 되었네요.

다른 사람들은 영주권 나왔을 때 감흥에 젖는다고 하던데, 별다른 느낌이 들지 않았습니다. 카드를 보고 "이게 영주권이구나.." 하는 것 말고는 별로 모르겠네요. 미국을 나갔다가 다시 오면 공항에서 대기줄이 달라서 느낌이 다르려나요?

아무튼, 무탈히 진행되어 다행입니다. 이제 신분 문제도 해결되었으니, 자기계발에 힘을 써서 몸값을 올리는 데 주력해야 겠네요.

그동안 이리 저리 걱정해 주신 모든 분에게 감사 드립니다.

RISC-V 가 주류로 올라설 수 있을까?

4년전, 예전 직장에서 Berkeley 박사과정 한 분을 초청해서 강연을 들었던 기억이 납니다. 강연의 주제는 RISC-V 라는 이전의 RISC 를 계승한 새로운 open architecture 프로세서 였습니다. Computer Architecture의 교과서 책을 집필하신 두 분 (헤네시 스탠포드 총장, 패터슨 버클리대 교수) 중 버클리대의 랩에서 박사과정을 하시던 분이었는데, RISC-V라는 새로운 마이크로프로세서의 설계를 맡으셨던 분이었습니다.

처음 RISC-V라는 말을 들었을 때, '왠 20년가까이 된 이름을 빌려와서 ARM이 지배하는 마이크로프로세서 시장에 발을 담그는 걸까?' 라는 생각이 먼저 들었던 것 이 사실입니다. 시작부터 비판적인 색안경을 끼고 강의를 들었죠.

그러나 강의를 통해 RISC-V의 개발과정을 듣고 있으니, 이게 정말 한 팀이 해낸 일이 맞는지 의심스러울 정도로 방대한 양을 다루고 있었습니다. ISA(Instruction Set Architecture)를 재 정립하는 것은 뭐 그렇다치지만, verilog의 귀찮은 반복작업들이나 기타 단점을 보완하기 위해 chisel이라는 언어를 만든 것, 컴파일러 디버거를 포팅한 것 뿐만아니라 이미 Linux 운영체제까지 올린 것 부터 해서 여러 일을 진행을 했었다고 발표한 것이 기억이 납니다.

Implementation of RISC-V

정말 대단한 일이죠! 이쪽 업계에 수십년간 몸담아 오셨던 David Patterson 교수님의 지도 아래에 만들어진 프로세서니 충분히 관심을 기울일만한 일이었습니다. 게다가 복잡해져만 가던 ARM 과 대비해서 간결한 ISA는 관심이 갈만한 이야기였습니다.

오늘, 마이크로프로세서를 이용한 Supercomputing을 타겟으로Epiphany SoC나 Parallella Board를 만들었던 Adapteva 의 Andreas Olofsson 이 RISC-V에 관해 쓴 글을 읽었습니다. Andreas는 10가지 근거를 들며 RISC-V를 찬양하는 글을 썼는데요. 조금은 현실과 동떨어진 것 같아서 아쉽습니다.

물론 RISC-V가 나쁘지 않다는 것은 인정하지만, 현재 ARM 이외에 Industry의 요구를 충족하기 위해 나온 여러 마이크로프로세서 (Tensillica, ARC, MIPS 등)가 맥을 추지 못하는 것을 보고 있으니 RISC-V라고 별반 다를 수 있을까.. 하는 생각이 먼저 듭니다.

  1. Industry는 화려한 기능보다는 안정성, 검증된 것을 더 선호합니다.

    SoC를 개발하면서 가장 크게 느낀 것이라면, 기능의 추가보다 90% 동작가능 상태에서 99.9%의 동작 가능 상태로 끌어올리는 것이 수십배 이상의 노력이 들어간다는 점입니다. Computer Architecture의 책에서도 나오는 이야기 이지만, 오류 없는 디자인을 설계할 수 있다는 것과 오류가 있는 디자인은 제품으로 내보낼 수 없다는 것은 잘못된 생각입니다.

    그 말을 RISC-V에 적용해 보자면, RISC-V에는 코어 오류가 없을 수는 없고 (아직 검증이 안된 로직이다보니), 그렇지만 제품으로는 나올 수 있다고 할 수 있겠죠. 다만, 제품으로 나올 때 까지의 각고의 노력을 생각하면, 아직 제대로 검증이 되지 않은 제품을 갑자기 가져다 쓸 간 큰 회사는 별로 없으리라 봅니다. 저렴한 제품에 시험삼아 넣어볼 순 있겠지만, 최신 공정인 28nm나 14nm 공정의 테입아웃 비용을 생각하면 섣불리 해 보기 어렵습니다.

  2. 개발 환경이 아직 갖춰지지 않았습니다.

    ARM의 큰 장점은, 이미 업계에서 검증이 된 코어라는 점입니다. 그리고 그 다음 장점은 훌륭한 개발, 디버깅 툴이 많이 있다는 점입니다. Arm RVDS를 필두로 여러 종류의 IDE 가 있고, T32를 비롯한 강력한 디버깅 도구가 ARM 코어를 기반으로 하고 있습니다. 하지만 RISC-V로는 gcc 크로스 컴파일러가 있고 아직 IDE는 전무합니다. 뭐 개발에 IDE를 쓰는건 아니니 (여전히 SourceInsight의 막강한 기능을 쓰시는 분이 많죠) 그 부분은 넘어갈 수 있지만 디버깅 도구가 GUI로 제대로 된 것이 없다는 게 가장 문제가 크네요.

  3. 코어가 Scala 기반의 Chisel 언어로 되어있습니다.

    1번 문제와 관련이 있는데, 아직 제대로 칩에서 검증이 되지 않은 모듈이라면, 반드시 ECO (Engineering Change Order)를 해야할 상황에 부딫힙니다. 이때 RTL을 어떻게 디자인 해 두었느냐에 따라 ECO를 통한 수정이 쉬울지, 아니면 아예 불가능할 지 결정이 됩니다. 이러한 경험이 기반이 되어 하드웨어 설계시 최대한 수정하기 쉽게 RTL을 기술하곤 합니다.

    그러나 Chisel로 만들어진 코드를 verilog로 변환하면 verilog 로직을 이해하지 않는 이상 수정이 쉽지가 않습니다. 디자이너야 어떻게든 변환되는 부분을 이해하겠지만, 그렇지 못한, 가져다 사용하는 사람에게는 verilog를 충분히 이해하지 않으면 수정할 엄두조차 내지 못하는 상황이 됩니다.

  4. BSD 라이센스입니다.

    이건 장점이자 단점인데요. BSD 라이센스는 공개된 코드를 수정하더라도 다시 공개할 의무가 없습니다. 그 말은 필연적으로 다양한 branch가 만들어질 수 있다는 것을 의미합니다. 게다가 그 branch가 main stream으로 합쳐질 리 없는 수 많은 곁가지, leaf node로 끝나버립니다. 특히나 customizable microprocessor를 표방하면서 수정을 적극 권장하는 RISC-V에게는요.

    이게 RISC-V 가 바뀌지 않고 유지된다면 그다지 문제가 되지 않을 지 모릅니다. 그러나 UC Berkeley 팀에서 새로운 버전의 ISA를 내놓는다면, 각자 회사의 변경점이 반영될 리 만무하고, 각 회사는 다시 새로운 Architecture 위에서 이전의 변경점을 추적해서 반영해야 한다는 걸 의미합니다. (만일 회사가 새 RISC-V를 받아들일 생각이라면요) 이런 이유를 생각할 만한 회사라면 아마 RISC-V를 수정하지 않고 사용할 겁니다.

제가 안 좋은 이야기만 줄줄 쓴 것 같은데, 사실 RISC-V가 나온 소식을 듣고 환영을 했었네요. 그 많지 않은 인원으로 이뤄낸 여러 일을 보면서 대단한 능력자들이 모였구나, 라는 생각도 들고 아직 실력이 부족한 절 돌아보며 한숨을 쉬기도 했었습니다. 아무래도 지금의 절 돌아봐도 그때의 RISC-V 팀 일원이 될만한 능력이 없거든요. 그만큼 그 팀이 땀을 흘려가며 만들어낸 결과물은 이쪽 하드웨어 업계를 떠들썩하게 할만한 뉴스였습니다.

관심밖으로 사라지지 않고 다시 RISC-V 이야기가 들려와서, 한때 프로세서 디자이너를 꿈꿨던 저는 무척이나 반갑습니다. 아직 제게는 해소되지 않는 많은 우려가 있지만, 그 모든 우려를 씻어내고, 나중에 '제가 잘못 생각했었네요' 라고 말할 수 있게 RISC-V가 퍼지길 바랍니다.

Reference

  1. Open Source RISC-V Core Designs, Why Google Cares and Why They Matter
  2. RISC-V in Wikipedia
  3. ZScale: 32bit RISC-V

GTD: Omnigroup의 Omnifocus 2

지금까지 일과 기타 해야만 하는 일을 어떻게 관리할 것인지 많이 고민해보고 이것 저것 써 보았습니다.

예전에 잠깐 Microsoft Project를 사용했었는데요. 정말 기가 질릴정도로 다양한 기능에 압도되어 아무것도 하지 못하는 일이 종종 벌어지곤 했습니다. 너무 세세하게 관리를 해야만 흐트러짐없이 정돈이 되기에 오히려 하나 삐긋하면 포기해버리기 일쑤였습니다.

그 전에는 Trac, Redmine 등 온라인 툴을 썼었네요. 다만 이 도구는 Source code repository 와 연동되어야만 강력한 힘을 발휘하기에 특정 프로젝트에 한정되어 쓸 수 밖에 없는 점이 문제였습니다. 마일스톤을 정한다거나 이슈에 대한 추적은 매우 좋은 기능이었다고 생각합니다.

이 Trac의 상용버전 쯤 되는 것이 JIRA인데 호주의 Atlassian 회사에서 만들고 있는 도구입니다. 개인서버에 Starter Edition을 설치해서 사용하곤 했었는데, 일단 Java 기반이라 성능이 느린 제 서버에서는 정말 느렸었고, Microsoft Project 만큼이나 방대한 점, 프로젝트별로만 관리해야 되는 점 등이 1인 사용을 위한 도구로는 부적합했습니다.

Omnifocus 2

작년 12월 중순부터 사용하기 시작한 도구가 있습니다. Omnifocus 2라는 도구인데요. David Allen의 Get Things Done (이하 GTD) 개념을 도입한 소프트웨어 도구입니다. GTD는 다시 말하면 조금 복잡한 Todo list 라 할수 있는데요. 여기에 책임 영역이나 컨텍스트, Due date, Defer 같은 개념을 도입해서, 너무 간단하지는 않지만 MS Project같이 Overkill 은 되지 않는 한도내에서 적절한 지점을 찾은 것 같습니다.

그 전에 사용하던 Wunderlist는 공유되서 하나의 프로젝트를 여러명이서 관리할 수 있는 점은 매우 좋았으나 세부적인 설정이 거의 없다시피 해서 아쉬웠습니다. Omnifocus는 공유는 없지만, 매주 Review를 하는 부분이라던지 Forecast로 앞으로 할 일에 대한 전체 요약을 할수 있다는 것과 Focus 모드로 해야할 부분 하나에 집중하게 한다는 점이 강점입니다.

트라이얼로 사용해 보다가 새해 새 출발 기념으로 구매 후 본격적으로 사용하려고 Android용 3rd party app인 Focus GTD 도 구매했네요. 지금까지 2주간의 경험은 만족스러웠습니다. 구매를 했으니 조금 더 사용해보고 평가를 내려볼게요.

아참, 모두 새해 복 많이 받으세요~

OS X Other 공간 비우기

Disk Utility

오늘에서야 발견했는데, "Disk Utility"에서 Other 공간이 170GB를 차지하고 있는 것을 보았습니다. 어느 녀석이 이리 잡아먹나 알아보기 위해 OmniDiskSweeper를 설치해서 살펴보았는데 이상한 점이 발견됩니다.

분명히 가용 공간은 겨우 20GB 인데 실제로 검색되는 파일의 총 크기는 125GB 남짓밖에 되지 않았습니다. 뭔가 이상해서 구글링을 해 보니, OmniDiskSweeper 같은 디스크 검사 툴은 root권한으로 실행하는 것이 좋다고 하더군요.

$ sudo /Application/OmniDiskSweeper.app/Contents/MacOSX/OmniDiskSweeper

루트권한으로 실행하니 범인이 드러납니다. /.MobileBackups.trash 디렉토리가 77 GB를 잡아먹고 있었네요.

왜 이렇게 잡아먹나 궁금해서 다시 구글링을 해보니, CrashPlan이 범인이었습니다. CrashPlan을 NAS에서 사용하기위해 Headless로 설치 후 클라이언트만 사용하기에 서비스를 실행 시킬 필요가 없어서 서비스를 중지하고 /.MobileBackups.trash 공간을 확보하기로 합니다.

서비스 동작 중인지 확인:
$ ps aux | grep CrashPlanService
서비스 비활성화 :
$ sudo launchctl unload /Library/LaunchDaemons/com.crashplan.engine.plist
재시작시 다시 동작하는 것을 없애기 위해 서비스 파일 삭제:
$ sudo rm /Library/LaunchDaemons/com.crashplan.engine.plist

지우고 나니 100 GB가 확보되었네요. :)

2015년도 지름 결산

2015년도 거의 끝이 다 되었습니다. 크리스마스가 지나고 일주일이 되면 이제 2016년으로 새롭게 시작하겠네요. 그런 의미에서 1년간 크게 지른 것 위주로 요약 정리(?)해서 지름신이 되어보도록 하겠습니다. 임의 순서, 생각나는대로입니다. :)

  1. Vitamix 5300 Mixer

    \

    이전에 사용하던 믹서기 용기가 깨지는 바람에, 이참에 좋은 것으로 가자! 해서 구입한 믹서기 입니다. 왠만한 것은 죄다 갈아버리고 정말 곱게 갈립니다. 도깨비 방망이나 기존에 사용하던 100불 미만의 Kitchen Aid 와는 다른 발군의 성능을 보여줍니다.

    가격이 흠이므로 4/5점!

  2. Google Nexus 5X + Project Fi

    기존 넥서스5 액정이 깨져서 5X가 출시되기를 수개월 기다린 끝에 Project Fi와 함께 넘어갔습니다. 가장 좋은 점은, 실내에서 Cellular network가 안터졌는데, Wi-fi를 이용해서 전화가 아무 문제 없이 된다는 점입니다. 추가로 한국에 방문 시 로밍 부담이 덜하다는 (Wi-fi 연결 시 미국과 동일한 접속 환경) 점이 좋네요.

    넥서스 5X는 아직 마시멜로가 안정화가 안된 탓인지 리프레시가 좀 보입니다.

    3/5점!

  3. Logitech MX Anywhere2 Wireless Mouse

    \

    회사 노트북과 맥북프로레티나, 그리고 에얼리언웨어 알파를 동시에 편하게 쓸 수 있는 방법을 모색하다 MX Master와 MX Anywhere2 를 보게 되었습니다. 둘 중, 가지고 다니기 편한 MX Anywhere2를 할인해서 사게 되었네요. 3개의 디바이스를 동시에 페어링하고 스위치가 버튼 하나로 간편하게 되서 회사에서 맥북프로와 회사 노트북을 번갈아 가며 쓰기 무척 편해졌습니다.

    다만 아쉬운 점은 스크롤 버튼이 무한휠, 클릭휠 모드 변경이라 다른 버튼을 가운데 버튼으로 지정해야 한다는 점이네요.

    4/5점!

  4. Logitech K480 Bluetooth Keyboard

    \

    블랙프라이데이 할인으로 뒤도 안보고 지른 제품입니다. MX Anywhere2와 마찬가지로 3개까지 페어링 되고 조그다이얼을 돌려서 바로바로 바꿀 수 있습니다.

    다만 키감이 영 적응이 쉽지 않네요. 너무 구분감이 커서 손이 좀 아픕니다.

    2/5점!

  5. Motorola Moto G (3rd Generation)

    아내 스마트폰을 바꾸기 위해 산 제품인데, 내부 용량을 8GB 로 사는 바람에 고생 했습니다. 다만, 동작 자체는 아주 무리없이 깔끔하게 작동하고 에러가 거의 없습니다. 16GB를 샀더라면 아마 계속 사용했을 것 같네요.

    4/5점!

  6. Dell Alienware Alpha (i3 Edition)

    \

    N36L이 영화를 재생하기 어려울 만큼 성능이 버벅대다보니 NAS로만 사용되고, 기타 미디어는 Chromecast가 있으나 NAS를 그대로 재생하기 쉽지 않아 한대 장만하게 되었습니다 (로 쓰고, 사고싶어서 샀다고 읽으시면 됩니다)

    Custom NVIDIA GPU가 들어있는데 성능이 750Ti쯤 나온다고 하네요. 실제로 위쳐3를 중옵에 헤어웍스만 끄고 1920 x 1080 으로 무리없이 돌립니다. 같이 제공되는 Xbox 360 컨트롤러로 위쳐3를 하면 재밌습니다~

    3/5점!

  7. The Witcher 3 : Wild Hunter

    올해의 게임으로 불려도 손색없을만한 게임입니다. 최고의 그래픽, 빠져드는 이야기, 다양한 부가퀘스트 등 무엇하나 빠지는 구석이 없이 잘 만들어진 게임입니다.

    5/5점!

  8. Triumph Wykin Leather Jacket

    \

    눈물을 머금고 트라이엄프 본네빌을 판매하고 나니 남는건 스토어 크레딧뿐이더군요. 어디다 크레딧을 쓸까 하다가 가죽재킷 하나 장만했습니다.

    초반에 나는 가죽 냄새를 잡느라 조금 고생했지만 점점 몸에 맞아가는 느낌이 아주 좋습니다. 캘리포니아 겨울 날씨 생각하면 한 여름 빼고는 언제나 입고 다닐 수 있을 것 같네요.

    4/5점!

  9. Asus RT-AC68U Wireless Router

    지금은 최강의 자리를 AC86 시리즈에게 넘겨주었지만, 구입할 당시만 해도 상대할 공유기가 없을만큼 최고의 성능이었습니다. 다양한 기능은 반의 반도 사용하지 못하지만, 모뎀이 문제 된 적은 있어도 공유기가 말썽을 부린적은 없네요. 신호도 멀리까지 잘 인식되서 집안에서 Wi-fi 사용하는 부담이 매우 줄었습니다.

    5/5점!

  10. Moleskin Notebook (A5 size)

    노트로 사용하기 위해 구입했습니다. 다만 만년필과 같이 사용하기엔 너무 번져서 별로네요.

    값은 비싼데 재질이 별로라 1/5점!

  11. Volkswagen Passat Wolfsburg Edition

    본네빌을 팔고 구입한 자가용입니다. 저렴하게 샀다고 좋아했는데, 폭스바겐 스캔들이 터지면서 중고가가 폭락해서 10년동안 강제로 타고 다니게 생겼습니다. ㅜ.ㅜ

    연비 좋고, 핸들링 깔끔하고, 성능도 170마력으로 무난하고, 트렁크도 넓고, 어느하나 빠지지 않는 중형차인데 미국에서 브랜드가치가 엉망이라 상대적으로 싸게 구입가능합니다.

    폭스바겐 스캔들 때문에 2/5점! 내 중고가 하락분 보상하라!!

  12. Graco Nautilus 3-in-1 Car Seat

    파삿에 장착하기 위해 산 카시트입니다. 베이비 부터 어린이까지 계속 사용할 수 있게 등받이도 뺄 수 있게 되어있습니다. 다만, 둘째 아이가 잠들 때 보니, 이전 카시트보다는 편히 못자더군요. 고개가 계속 떨구어 집니다.

    안전성은 최고이지만 편안함에서 감점으로 3/5점!

  13. VIAIR 85P Portable Air Compressor

    바람을 종종 주입하기위해 샀습니다. 아내가 운전하다 나사가 박혀서 펑크났을 때 요긴히 쓰였네요. (두번이나!) 한국에는 오토코스란 걸출한 에어 컴프레셔가 있지만 여긴 Viair가 최고인듯 합니다.

    4/5점!

  14. WeatherTech Custom Fit Cargo Liners for Odyssey

    오디세이의 1열, 2열을 웨더텍으로 교체한 뒤, 때를 노리다가 3열 접고 웨더텍으로 교체했네요. 기존엔 얼룩덜룩한 카펫이 보기 흉했는데 깔끔한 고무매트로, 흙먼지가 걱정이 없습니다. 다만 살짝 주변부가 들뜹니다. 시간이 지나면 괜찮아질 줄 알았는데 아직도 완전히 맞진 않네요.

    3/5점!

  15. Coleman Instadome 5-person

    \

    캠핑을 시작하기위해 코스트코에서 구입한 텐트입니다. 가격 싸고, 빠르게 펴고 접고, 바람 잘 막아주고, 어느정도 방수는 되고, 어느 하나 깔게 없는 텐트네요. 요세미티 가서도 2박3일동안 매우 잘 썼습니다.

    5/5점!

  16. Coleman Northstar® PerfectFlow(TM) Instastart(TM) Propane Lantern

    \

    캠핑장에서 저녁에 모닥불 피우고 이야기나누는 즐거움은 이루 말할 수 없죠. 그런데 LED 랜턴을 쓴다면 그 밝은 백색등 때문에 눈이 쉽게 피로해 집니다. 그래서 물색한 것이 가솔린 랜턴과 프로판 랜턴입니다.

    그 중 사용하기 편한 프로판 랜턴으로 구입했습니다. 밝지만 주황색의 은은한 랜턴을 보고 있기만 해도 마음이 안식이 됩니다.

    5/5점!

  17. Pentax 65792 XCF 10x50 Binoculars with Case

    \

    별자리를 보기위해 구입했네요. 원래대로라면 돕소니안 망원경을 사야하는데, 집이 생기기 전까지는 일단 참기로 했습니다.

    타호와 요세미티에서 별자리를 보았는데, 확실히 깔끔한 별상을 보여주고 육안으로는 보이지 않는 것까지 잘 보여서 즐겁게 밤하늘을 관찰할 수 있었습니다.

    4/5점!

Cross Compiling Go program

오늘은 뜬금없이 Go 언어에 관해서 글을 써 볼까 합니다. 제가 Synology NAS (정확히는 N36L을 이용한 해놀로지)를 사용하고 있는데, 이 NAS에서 Go로 만들어진 프로그램을 실행해야 할 상황이 되어 몇가지 알아보았습니다.

크로스 컴파일은 일반적인 컴파일러에서 자주 사용되는 기법인데, 개발 PC에서 ARM 용 코드를 ARM 에서 실행될 수 있는 바이너리로 컴파일 하는 것이 가장 많이 접해볼 수 있는 크로스 컴파일 상황일 것 같습니다.

일단 golang을 linux/amd64 용으로 만들어야 합니다. Mac 에서 Homebrew를 사용하고 있으면 Source directory로 가서 아래의 문구를 실행해 봅시다.

$ cd $(brew --prefix go)/libexec/src
$ export GOROOT_BOOTSTRAP=$(brew --prefix go)/libexec
$ GOOS=linux GOARCH=amd64 CGO_ENABLED=0 ./make.bash --no-clean

이 컴파일 과정이 끝나면 linux/amd64용 go 컴파일러가 ../bin/go 에 만들어 집니다. 현재 맥에서 사용하는 go와 구별하기 위해서 이 파일을 카피해서 파일명을 syno.go 로 변경하도록 합시다.

그 후 컴파일 할 프로그램이 있는 곳으로 가서 빌드를 합니다.

GOOS=linux GOARCH=amd64 syno.go build

그러면 해당 디렉토리에 실행파일이 만들어지는데, 실제 실행해 보면 executable이 아니라고 에러가 나면서 실행이 되지 않습니다. 이 파일은 synology에서 실행될 수 있는 파일이므로 synology NAS에 복사 후 실행해 보면 실행이 잘 되는 것을 볼 수 있습니다.