dotfiles 만들기

today 2016-05-22 face Posted by appkr turned_in Work & Play forum 0

dotfiles는 개발자들이 사용하는 .bash_profile, .ssh 등 dot(.)으로 시작하는 파일 또는 디렉터리의 모음이다. dotfiles는 콘솔용 바이너리(e.g. gcc), 라이브러리, 애플리케이션의 설치 뿐만아니라, 그들의 설정을 잘 저장해 두었다가 컴퓨터를 빠르게 재구성하기 위한 워크플로우다.

dotfiles를 구성해두면, 예를 들어 gulp, git-flow, sublime-text3, google-chrome 등, 내가 사용하는 애플리케이션 및 개발 도구의 목록과 설정을 저장해 두었다가 다른 컴퓨터 또는 새 운영체제에서 애플리케이션 설치뿐만아니라, 심지어 코드 에디터의 설정까지도 다른/이전 컴퓨터와 똑같이 ‘바로’ 사용할 수 있다.

이번에 맥을 밀고 다시 설치할 일이 있어서, 오랫 동안 미루어 두었던 dotfiles를 시전했다. 필자도 이번 경험을 통해 알게된 사실인데, 운영체제를 다시 설치할 때만 dotfiles를 만들거나 적용할 수 있다고 생각하지만, 사실이 아니다. dotfiles는 운영체제를 다시 설치하지 않더라도 언제든 준비할 수 있다.

유명한 dotfiles들을 검토했는데 정석은 없더라. 쉘 스크립트만 이용한 사람, 주제별로 디렉터리를 분리한 사람, 다른 툴을 이용하는 사람, 운영체제도 제각각이더라. 이 포스트에서는 맥 운영체제 기준으로 dotfiles를 준비하는 방법을 공유한다. 다음 도구들을 이용한다. 앞서 말했듯이 정석은 없으므로 꼭 이렇게 할 필요는 없다.

  1. Homebrew
  2. Homebrew Bundler
  3. Mackup
  4. .osx
  5. Shell Script

시전하는 과정에서 운영체제를 두 번 설치해 봤는데, 이 정도 경험으로는 다른 이의 맥에서도 동작하는 은총알 dotfiles How-to를 쓰기에는 무리다. 어쨌든 진리는 ‘평상시에 dotfiles를 준비해 두면, 불의의 사고에 빠르게 대처할 수 있다’라는 점이다.

서비스 URL의 중요성 및 변경의 비용

today 2016-05-18 face Posted by appkr turned_in Work & Play forum 0

웹 서비스를 하다 보면 마이그레이션을 해야 할 때가 반드시 찾아 온다. 트래픽 양이 변해서 더 큰 또는 작은 서버로 이전한다거나, 다른 프로그래밍 언어 또는 다른 프레임워크로 갈아타야 한다거나..

나에게도 찾아 왔다. 라라벨 온라인 강좌의 라이브 데모 사이트를 AWS(Amazon Web Service)에서 서비스하고 있었는데, 요금이 꽤 나와서 Github Page로 옮겼다. 회원 가입등 서버가 필요한 동적 기능은 버리고, HTML로 강좌만 서비스하는 정적 웹 페이지로 바꾸었다. 이 과정에서 어쩔 수 없이 URL을 변경했다.

변경 전 변경 후
/lessons/01-welcome.md /lessons/01-welcome.html

Jigsaw라고 하는 정적 사이트 빌더를 이용했는데, 로컬 컴퓨터에서 마크다운으로 작성한 강좌를 정적 HTML 파일로 전부 트랜스파일한 다음, Github Page에 올리는 방식이다. Jekyll을 이용한 이 블로그와 빌드 도구만 다를 뿐 똑같은 방식이다.

AWS 라이브 데모를 닫은 지 2주일 정도됐다. 사용자가 구글 검색 엔진을 통해 들어온다면, 기존의 URL은 당연히 열리지 않는 황당한 경험을 하게 된다. 구글로부터 최근에 404 응답이 많아졌다는 메일을 받았지만, 아무 생각없이 그냥 무시했었다. 커뮤니티에서 같이 활동을 하는 김종운님과 어제 대화를 나누기 전까지는 말이다.

URL이 바꼈던데, 그간에 쌓아 놓은 구글 검색 순위가 아깝지 않으세요?

김종운님

Google Search Console로 확인해 보니 다행히 그간에 검색 엔진을 통해 들어온 사용자는 그리 많지 않았고, 순위도 그리 높지 않았을 것이라 생각한다. 그러나, 2 주간 불편을 겪었을, 또 앞으로 불편을 겪을 수도 있는 사용자를 생각하면 고치지 않을 수 없었다.

이 포스트는 다음 내용을 다룬다. SEO(Search Engine Optimization, 검색 엔진 최적화)라는 관점에서 공통점이 있다.

  1. Github Page에서 URL Redirect를 구현한 로그
  2. SEO 관점에서 URL의 중요성 및 일반적인 URL Rewrite 방법

Git Flow

today 2016-05-04 face Posted by appkr turned_in Work & Play forum 0

Git Flow 는 Vincent Driessen이 제안한 깃 브랜칭 전략을 실행할 수 있도록 돕는 Git 확장 프로그램이다. 이 전략은 masterdevelop을 각각 배포 및 개발 브랜치로 사용하면서, feature, release, hotfix 등을 위한 임시 브랜치를 사용한다.

아래 그림은 Git을 소개하는 웹 문서나 서적에서 한번은 본 그림일 것이다. 많은 개발자들이 이 전략을 모범 사례로 인식하고, 따르고 있다는 방증이다.

이 포스트는 Git Flow의 기본적인 사용법을 담고 있다. 사실 여기 수록한 내용이 전부인 듯 하다.

소프트웨어 개발 비용

today 2016-04-27 face Posted by appkr turned_in Learn & Think forum 0

소프트웨어 개발 비용은 ‘돈’ 보다는 ‘시간’의 의미가 더 크다. 개발 비용은 크게 보면 다음 세 가지로 구분할 수 있다.

  1. 도입 비용
  2. 수정 비용
  3. 소유 비용

각 비용을 적절히 배분해야 전체 비용이 줄어든다. 가령, 성공을 확신할 수 없는 새 제품이나 서비스를 개발하는데, 오버 엔지니어링해서 많은 도입 비용을 쓰는 사례를 들 수 있다. 또는 도입 비용을 너무 싸게 예측해서 급히 개발했는데, 시장 반응이 좋은 상황이다. 분명 개발의 훌륭함보다는 아이템의 승리다. 수정해야하는데, 팀의 빨리빨리 문화에 회의를 느낀 초기 개발자는 회사를 떠났고, 스파게티 코드만 남아 누구도 손댈 수 없는 사례도 생각해 볼 수 있다. 내 일천한 경험에 비추어 보면 이런 코드로 램프 업한 사업은 곧 망하더라(대규모 투자를 받아 팀을 리빌드한 경우는 제외).

깃(git)을 꽤 오랫동안 썼지만 잘 모르는 기능 중에 하나가 리베이스(rebase)다. 사실 리베이스를 할 줄 알고 모름에 따라, 초급과 중급으로 구분된다고 해도 과언이 아니다. 리베이스를 꽤 오랫동안 썼지만, 주로 하는 것은 커밋 합치기(fixup, or squash)와 커밋 메시지 바꾸기(reword) 정도였다.

이번에 예전에 커밋한 내용을 수정할 일이 있어서 수정(edit) 기능을 처음 써봤다. 최종 목표는 이렇다.

  1. 이전에 커밋한 내용을 수정하고, 그 뒤에 연속되는 커밋에 변경 내용을 모두 반영한다.
  2. 리베이스하기 전의 전체 커밋 로그를 리베이스 후에도 그대로 유지한다.

말로는 쉬워보이지만, 2번이 정말 어려웠다.

예를 들어, foo -> bar -> baz 커밋 로그가 있다고 하자. 리베이스로 foo 커밋의 내용을 수정했는데 bar에서 충돌이 발생했다. bar 커밋에서 발생한 충돌을 해결하고 나면, bar 커밋은 foo 커밋으로 합쳐지고, bar 커밋 로그는 남지 않는다.

‘최종 커밋만 있으면 되지~’, ‘중간 커밋을 살리는 것이 무슨 의미가…?’라는 의문이 생길 수 있다. 맞다. 최종 커밋만 있으면 된다. 그런데, 나는 이번에 나올 책에서 챕터별로 예제 코드를 커밋했고, 커밋 로그 하나가 사라지면 챕터에 해당하는 소스코드의 이력이 사라지기 때문에 이 문제를 꼭 해결해야만 했다.

이 고생을 한 이유는 책을 쓰는 도중 라라벨 프레임워크의 수버전이(유의적 버전은 주.부.수로 쓴다) 변경되었고, 이번 버전 업에서는 라우트 사용법이 변경되었기 때문이다. 라우트는 웹 서버와 라라벨의 경계에 해당하는 부분이라 아주 아주 아주 중요할뿐더러, 책의 가장 첫 부분이기도 하다. 독자들은 새 버전의 프레임워크로 프로젝트를 시작할테고, 바뀐 사용법을 적용하지 않으면 책의 시작부터 작동하지 않는 소스코드를 만나게 되는 셈이다.

어쨌든… 이 포스트는 이 문제점을 해결한 이력이다.

keyboard_arrow_up