Chef, Ansible

Chef와 Ansible을 비교하는 문서들을 읽으면서, Chef가 (필요 이상으로) 복잡하다고 느끼는 것은 나만이 아닌 듯 하다.

여러 문서 중 Ansible vs Chef의 Infographic은 두 Tool의 비교를 깔끔하게 보여주고 있다.
특히 Chef의 단점 중 하나로 Ruby에 묶여있다는 점을 언급한 것이 맘에 든다.
Ruby가 어렵진 않고 Ruby의 일부만 알아도 사용하기 충분하지만, 요즘 이 바닥에서 알아야 할 것이 지천인데 Ruby까지 새로 익히긴 좀 부담스럽다.

지금에서야 어느 정도 Chef를 사용하는데 익숙해지긴 했지만, 다음에 Continuous Delivery 환경을 구축할 때는 Ansible로 갈 생각.
Chef를 포기한다기보다, Ansible vs. Chef – which is better?에서도 지적하듯이 둘 다 필요한 경우들이 있기 때문이다.

맘에 들지 않는 Visual Studio의 Editor

Visual Studio 새 버젼 출시에 앞서 개인적으로 가장 많이 바랬던 기능은 Editor의 개선이었다.

얼마 전 2017 버젼이 출시되었는데, 사실 C++ 쪽만 쓰고 있어서 개발 결과물에 대해서는 큰 바램이 없다.
그보다 프로그램 구동부터 종료 때까지 거의 대부분 Editor와 Output(Debug 시에는 둘 다)을 바라보는데 이 부분은 근 10년이 넘도록 변화가 없는 듯 하다.

매일 사용하는 JetBrains IDE나 Sublime Text는 그 자체로도 훌륭한 Tool이지만, 가장 맘에 드는 것 중 하나는 Editor/Console 화면이다.
테마 지정은 물론, 폰트와 줄간 크기를 내 입맛대로 조정할 수 있는데 – 예를 들어 PyCharm의 경우 Font 14, Line Space 1.1 – 이것만으로도 완전히 다른 환경에 온 듯한 느낌을 받는다.
CLion을 보면 심지어 Editor용 배경화면도 지정할 수 있는데 이건 좀 오버 같고.

왜 Visual Studio 팀은 이런데 신경을 안 쓰는지 모르겠다.
타 기능 개선에 비해 어려운 일도 아닐 것 같은데.

Perforce, Subversion, Git

Perforce(P4)를 처음 쓰기 시작할 때는 ‘이거 Svn의 유료 버젼 아냐..?’라는 좀 무식한 생각을 했다.
사실 개인적으로는 Git을 쓰고 있고 회사의 메인 프로젝트에서는 Subversion을 쓰던 중 또 다른 프로젝트에서 Perforce를 쓰게 된 터라 내심 여간 귀찮지 않았다.

그런데 계속 쓰다보며 든 생각은, 결국 쓰기 나름이라는 것이다.
즉 잘 쓰면 썩 훌륭한 툴이라는 것. 특히 Performance 측면에서는 여타 VCS 중 제일 좋은 것 같다.

수많은 논의가 이미 온라인 상에 있지만 그 중 아래 글들은 참고할 만 하다.

Perforce의 branching 개념은 Git에 훨씬 익숙한 나로서는 아직도 좀 이상하지만, 전반적으로 P4 + Swarm(Code Review Tool)은 사용하기에 상당한 매력이 있다.
특히 Code base의 덩치가 클 때는 아무래도 P4가 맞는 선택이 아닐까 싶다.

Printing in Sublime Text 3

놀랍게도 Sublime Text에는 Print 기능을 기본적으로 제공하지 않는다.

우선순위가 높지 않아서 개발되지 않았다는데, 사실 몇 년 째 사용하면서 이제서야 알아챘다는 점에서 수긍하지 않을 수 없다. (그래도 어색함)

Forum을 보니 이런 대화도 보인다.

– It’s one of the most basic features in a text editor is printing.
– Nope, Editor is for editing.

Editor 시장 초기도 아닌데 이런 논란이 아직 있다는 것이 새삼 놀랍다.

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 비용이 나갈 수도 있다.

Eclipse에 잘 맞는 D2 Coding 글꼴

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

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

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

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

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

SEO 권장기준에 딱 맞는 WordPress

15 SEO Best Practices for Structuring URLs 참조.

특히 WordPress를 사용할 경우,

  1. URL Structure를 의미있게 하고 – WordPress admin 화면의 Settings > Permalinks 에서 입맛에 맞게 조정
  2. Blog를 너무 깊숙한 곳에 넣지 않으면 – 즉 Domain root 나 /blog 정도. 이 역시 Settings > General 에서 조정 가능하다

로 하면 SEO를 위한 권장사항에 대부분 다 맞는다.

간단해서 좋다.

말 안 통하는 개발자

말 안 통하는 개발자와 논의하는 것도 상당한 고역이다.

아래 포스팅에 언급한 링크에도 나오는 대목인데,

… 리더는 개인으로 기여하는 사람이 아니며, 리더의 의견이 다른 사람들을 앞선다.
소속 팀은 그 ‘질’과 상관없이 리더의 충고를 따르게 된다.

이런 위험성때문에 개발 및 운영작업에 ‘깊게’ 개입할 경우 상당히 조심하는 편이다.

하지만 끊임없이 자기 정당화를 하면서 상대편을 수긍하지 않으려는 대상과 논의하다보면 자연스럽게 부아가 나면서 목소리가 높아지게 된다.
늘 영어를 써야하는 업무 특성 때문에 보통 차분하게 말하는 편인데, 흥분함으로써 뜻대로 의사 전달이 되지 않는 악순환이 벌어지게 되고.

항상 생각하는 것이지만, 사람 관리가 제일 어렵다.
그래서 더욱 진정한 ‘Technical Manager’를 지향하는지도.