분류 전체보기
-
C++에서 언제 어떻게 struct를 사용하는가?Programmer/Programming 2017. 9. 25. 16:03
C++로 코딩할 때에 class와 struct 중에 무엇을 사용할 지 고민을 할 때가 있다. 내가 C++에서 struct를 선택하는 기준은 다음과 같다. 분해하면 모든 멤버 변수가 scala data type이다. 멤버 변수 중에 union, struct 또는 고정 길이 array를 만나면 재귀적으로 분해한다. 모든 말단이 scala data type으로 이루어졌다면 struct를 사용한다. 즉, 분해하는 과정에서 포인터나 가변 길이 배열, 클래스를 만나면 struct를 사용하지 않는다. 구조체를 이진 데이타로 고스란히 pack/unpack 해야 한다. struct는 메모리 형태 그대로 데이터로 상호 변환 가능함으로 개발하기 편하다. 굳이 별도의 pack/unpack 함수를 작성할 필요가 없다. 단, 데..
-
Lisp 비교 : Emacs의 개발 환경Programmer/Emacs 2017. 7. 11. 03:36
Emacs의 Programming 관련 공통 설정 Lisp 공통 설정 (use-package paredit :ensure t :diminish paredit-mode :init (use-package paredit-everywhere :ensure t)) Common Lisp Common Lisp의 major-mode는 'lisp-mode'이다. 보통 확장자 '*.lisp'나 '*.l'와 연결되어 있다. SLIME이라는 강력한 REPL 도구가 있다. Common Lisp 설정 예: (add-hook 'lisp-mode-hook (lambda () (setq indent-tabs-mode nil) (paredit-mode t) (helm-gtags-mode 1))) (use-package slime :en..
-
진짜는 굳이 의미를 부여할 필요가 없다.Life/Society 2017. 7. 5. 22:50
얼마 전 꿈에서 내가 나한테 진짜는 굳이 의미를 부여할 필요가 없다. 고 말했다. 꿈의 통찰에 완전히 감탄했다. 가짜는 본질의 회피하기 위해서 다양한 의미를 부여해야 한다. 뭔가 설명이 필요하고 더구나 설명이 복잡하면 그건 본질이 아니다. 누군가의 관계에 꼭 의미를 붙여야만 한다면 진정한 만남이 아니다. 자신이 하는 일에 이런 저런 합리화가 필요하다면 분명히 그른 일이다. 나의 감정/느낌/생각에 대한 설명이 길어진다면 거짓을 꾸미고 포장하는 것이다. 진짜는 짧고 단순하고 명쾌하다. 추가되는 내용이 있다면 단지 부연하는 것 뿐이다. 덧붙이지 않아도 아무런 상관이 없다. 가짜는 온갖 부차적인 이유와 설명이 꼭 필요하다. 진실의 가리기 위해서 수많은 부연이 수반된다.
-
사람을 믿는 기준Life/Society 2017. 7. 5. 22:39
도덕과 윤리에서 사람을 믿고 도움을 줘야 한다라고 배웠다. 아무나 어떤 상황에서도 믿어야 할까? 무조껀 신뢰하는 것은 항상 불신하는 것만큼이나 어리석다. 이 글에서 믿음의 기준에 대해서 탐구하고자 한다, 상대방이 반격하더라도 막아낼 수 있다면 웬만하면 믿음을 가져라. 그러나, 나를 지킬 수 없을 것 같으면 자신을 보호하는 것이 우선이다. 이런 이유로 집에 혼자 있는 아이나 여성은 아는 사람이라고 하더라도 함부로 집에 들어오게 하면 안된다. 어린이가 택배 기사의 방문에 대문을 열어주지 않는 것은 그분이 나쁜 사람이라서가 아니라 자신을 지킬 수 없기 때문이다. "나 못 믿어?" "속고만 살았어?" 별의 별 소리를 해도 상대의 공격을 막을 수 없다면 방어적으로 나가야한다. "사람을 믿고 열린 자세로 가져야 합..
-
일단 만들어라. 두 번 만들어라. 그러면 보일 것이다.Programmer/Programming 2017. 6. 29. 06:26
내가 실무에서 배운 최고의 코드 설계 방법은? 일단 만들어라. 두 번 만들어라. 그러면 보일 것이다. 문제를 이해하는 가장 좋은 방법은 만들어보는 것이다. 생각만으로는 알 수 없다. 구현하면서 문제에 대한 이해가 높아진다. (관련 링크: 창의적인 일을 찾지 말고 창의적으로 일을 하라.) 어떻게 하면 효과적으로 문제를 탐색할 수 있을까? 첫번째 구현에서는 문제의 탐색에 초점을 두어야 한다. 머릿속에 떠오르는 이상적인 시나리오를 직선적으로 표현한다. 세세한 예외 처리나 아름다운 코딩 등에 시간을 빼앗기지 말자. 그림에 비유하자면, 머릿속에 떠오른 이미지를 거침없이 스케치를 하는 것과 같다. 화폭에 그리면서 전반적인 이야기와 구도를 잡는 것이 가장 효과적이다. 이 단계에서는 눈가의 잔주름과 같은 세부적인 부분..
-
민주주의 서비스 아키텍쳐Life/Software Engineer 2017. 3. 14. 15:48
민주주의는 그냥 표를 많이 얻는 이가 권력을 가지는 제도이다. 표를 많이 얻은 사람이 훌륭하다는 보장이 없다. 따라서, 민주주의는 훌륭한 사람 능력있는 사람을 뽑는데 적합한 제도가 아니다. 다만, 이상한 사람이 권력을 잡아도 나쁜 짓을 아주 많이 못하게 한다. 민주주의의 핵심은 평화적이고 합법적으로 권력을 교체할 수 있다는 것에 있다. - 차이나는 클래스에서 유시민 비슷한 원리를 서비스 아키텍쳐에 도입하면 어떨까? 이를 "민주주의 서비스 아키텍쳐"라고 이름을 붙이자. 이 아키텍쳐는 최고의 시스템을 만드는 것을 목표로 하고 있지 않다. 문제가 있더라도 극복할 수 있는 탄력적인 시스템을 만드는 것이 핵심이다.
-
문제가 발생하면 근본 원인 찾아라.Programmer/Programming 2017. 3. 6. 22:10
문제가 발생하면 근본 원인 찾아라. 근본 원인을 찾지 않고 성급하게 해결하는 것은 나쁘다.대표적인 사례가 핵(hack)이다. 핵은 원인을 고치지 않고 드러나는 문제만을 처리한다. 근본 원인 파악 없이 방어 코드로 해결한다. [표면적인 문제만 해결하려는 우리들의 모습] 자동차의 시동을 두세번 시도해야 비로서 작동하는 문제가 있다고 가정해보자. 핵를 쓰는 엔지니어는 시동 걸릴 때까지 자동으로 반복해주는 기능을 추가한다. 여러 가능성이 있는 원인을 조사하지 않고 표면적인 문제만을 처리하였다.그러나, 이러한 방식은 문제를 감추었을 뿐 근본이 해결되었는지 알 수 없다. 숨겨진 문제가 언제 드러날지 누구도 알 수 없다. 게다가, 이렇게 원인이 해결 안 된 문제들이 숨겨지면서 누적된다는 것이 더 심각하다. 시동이 잘..
-
기술 허세Life/Software Engineer 2017. 2. 16. 10:34
자신의 지식이나 기술을 보여줄 목적으로 과도한 기술을 언급하거나 도입하여 것을 나는 '기술 허세'라고 부른다. 최신 유행하는 기술을 마구 늘어놓는 것이 전형적인 형태이다. 기술과는 관련이 없지만, 주변에서 '허세'라는 것을 종종 접한다. 뒷동산에 올라가도 너나 할 것 없이 전문 등산 장비를 몸에 두른다. 최소한 수십만원 때때로 그 이상의 가격이 붙은 등반의 명품을 차려입는다. 장비에 비해서 산이 초라하게 느껴질 정도이다. 자전거 동호외에 참여해도 다르지 않다. 가벼운 라이딩을 즐기는 사람이 장비는 프로들의 그것에 견주어 볼 만 하다. 그들은 비록 닭을 잡지만 소잡는 칼이 있음을 자랑하고 싶다. 수단은 목적에 이르게 하는 도구이다. 목적에 맞게 과하지도 부족하지도 않은 것을 택하는 것이 합리적이다. 합리적..