Development

대부분의 프로그램은 여러 개로 나누어진 Routine(그것을 함수, Method, 뭐라 부르든)의 집합이며, 동시에 이것들의 반복되는 상호 호출의 결과이다. 따라서 전체 소프트웨어의 실행 시간은 이 단위 Routine이 소모하는 시간의 합이며, 그 중에는 분명히 절대적/상대적으로 “혼자 바쁜” 또는 “혼자 느린” 누군가가 있게 마련이다. 어느 집합이든 통하는 얘기다.

이번 시리즈를 통해서 배운 것이 하나 있다면, 글을 쓰려거든 딱 그 주제 하나에만 집중해야 한다는 점이었다. 시작은 단지, SoftLayer Cloud와 Object Storage를 활용한 시험적인 Application을 소개하는 것이었는데, 시리즈에 담을 내용을 정하는 과정에서 욕심이 과했던 것 같다.

지난번, “CAOS, Cloud Album on Object Storage“라는 제목의 글을 통해서 Cloud Computing 영역의 서비스를 다각도로 활용하여 간단한 “Photo Album” 서비스를 구성해본 경험에 대하여 운을 뗐다. 이 글은 그 “CAOS 시리즈"의 본편 첫 번째 이야기로, 기존에 내가 즐겨 해왔던 방식과는 조금 다르게 Rails App의 골력을 만드는 과정을 기록하려고 한다.

뜻하지 않던 파일 공유도 할 겸, SoftLayer의 Object Storage에 대한 API 시험도 할 겸 간단하게 Web Application을 하나 만들어봤다. 이름하여 CAOS. Cloud Album on Object Storage를 줄여 만든 이름이다.

한 10일 전에 SoftLayer의 Object Storage를 사용하면서 Temp URL을 사용하기 위한 수정을 더한 Custom 버전에 대하여 기록했었다. 그런데 언제나 급하게 간 길은 옳은 길이 아닐 수 있어서 왔던 길을 다시 걸어야 할 때가 있다. 지금이 그 상황이다.

잠깐 짬을 내서, 지난 주말에 SoftLayer의 Object Storage를 활용하는 개발의 시험을 해보려고 했다. 그런데 이 Object Storage 내에 저장된 비공개 자료를 임시 URL을 사용하여 URL을 알려줄 특정인에 한정하여 공유하는 부분에서 딱! 하고 막혀 버렸다. 이번 글은, 이 막힘을 푸는 과정을 두 가지 주제로 기록해 보려고 한다.

일반적인 Web Application이 아닌 API Backend를 위한 Python Web Framework을 선정하기 위하여, 인기있는 Framework 몇 개를 비교해보았다. 이 글은, 이 비교 과정과 결과에 대한 기록이다.

계단 하나 하나를 그냥 뛰어넘지 못하는 성격 탓에, 정작 쓰려던 글을 뒤로 미루고 먼저 써 내려가고 있는 이 글은, Bundler가 Ruby 세계에 제공하는 것과 유사한 기능을 Python 세계에 제공해주는 virtualenv와 pyvenv로 줄여 부르는 Python Virtual Environments에 대한 이야기이다.

이 글에서는, 앞서 작성한 Ember.js 기반의 Console App을 조금 다듬으면서 Console App의 방향을 다시 명확하게 잡고, 이 과정에서 Semantic UI를 적용하여 보다 보기 좋게 만드는 과정을 기록하였다. 또한, 시각적인 데이터 표현에 대하여 고민하여, 내 비용이 주로 어느 자원에 의하여 나가고 있는지 직관적으로 확인할 수 있도록 Billing 자료에 시각화를 적용해 보았다.

SoftLayer API에 대하여 파악하고 그 한계나 사용 가능성 등에 대하여 검증하기 위한 목적으로 작은 프로젝트 하나를 진행해 봤다. 이름하여, Hardened Layer.

이 글은 NVM, Node Version Manager를 사용하여 Ubuntu 15.04 환경에서 Node.js와 npm 환경을 간단하게 구성하는 과정을 정리한 글이며, 궁극적으로 npm을 이용하여 Ember-CLI 환경을 구성하고 Ember.js 프로젝트를 진행할 수 있는 환경을 완성하는 과정의 기록이다.

얼마 전부터 작은 오픈소스 프로젝트를 하나 (업무로써) 진행하고 있는데¹ 공부도 할 겸, 프로젝트의 웹 부분을 Django 프레임웍을 사용하여 작성하고 있다. Django는 뭐랄까… 아쉽게도 ruby on rails를 처음 접했을 때 만큼의 감동은 없는데, 나름대로 단순한 면도 있고 쓸만 하다는 느낌이다. (MVC 관점이 좀 애매하기는 하다.)

시간을 내어 읽어볼 것!

5 Tips for Deploying Background Jobs in Ruby on Rails | Engine Yard Blog

Background Job processing is all the rage lately, with numerous folks speaking and blogging about it—and rightly so. Since response time is a critical factor when scaling a web application, it makes sense to focus on keeping response times low, even when the app has tasks to perform. Moving the heavy lifting out of the request and response cycle is key to scaling a web application with high performance.

[더 읽기]

지금의 업무 환경이 마땅치 않아서 이기고 하고 또 한편으로는 작은 오픈소스 프로젝트를 열어보고자 하는 생각도 있고 하여, 요 얼마간 서브버전을 지원하는 공개 프로젝트 호스팅 서비스를 찾고 있었다. 실은 trac을 지원하는 무료 호스팅 서비스를 원했으나 적당한 것을 찾지 못했다.

한참 전에 글을 시작했다가 덮어두고, 이제야 다시 써본다.

남에게 일을 맡겼다. 언제 검수해야 하는가?

대낮 연구실서 벌어지는 스트립쇼 - 디지털 시대, 디지털 리더 디지털타임스

연구부에서 동료 검토를 도입하기 위해서 2년에 걸친 준비기간을 거쳤다. 교육과 설득 그리고 시범 적용을 거쳐서 전면적 실시를 한지 벌써 3년째다. 3년 전에 동료검토를 시작할 때는, 아주 공개적이고 공식적인 검토회의에서 자신이 만든 소프트웨어를 남들 앞에 낱낱이 들춰서 보이는 것에 대해 익숙하지 못했다.
발표자는 검토 중간에 얼굴이 벌겋게 달아오르고 토의는 언쟁 직전으로 번졌다. 그래서 팀장이 직접 검토회의에 참가하여 중재를 하곤 했다. 이제 우리 연구원들은 스트립쇼 무대에 올라서는 것을 두려워하지 않고 당당하게 춤을 춘다. 그러기 위해선 평소에 품질 좋은 소프트웨어를 만들어야 한다.

[더 읽기]

일하다가 참으로 상황이 깝깝할 때, 가끔씩 꺼내보는 동영상. 이 동영상을 보면, 한 편으로는… IT를 선도하는 그들에게도 이런 일이 일어나고 있구나… 하는 생각도 들고… :-)

코드리뷰에 대한 좋은 글이 있어서 인용한다. 그런데, 한 문장도 빼놓기가 아까운게… 잔뜩 인용해버렸다. :-)

조금 된 패치인데, 기록을 위하여.